The map: agent feedback loops, tools, and approaches

TeamRetro is interested in every continuous-improvement cycle teams run; AI-assisted work is a new area we’re thinking through via our retrospective lens. This page is the reference companion to this guide: the whole space laid out systematically. If you’d rather start with the story, begin at the guide’s opener and come back.

What this page is

Three things, in order: the lifecycle a single piece of friction travels from occurring to being fixed; the named loops the field has built to run that lifecycle, sorted by the level each operates at; and the classification schemes in use for naming what went wrong. Read it top-down to locate your team: which stages your tools already cover, which loop you’re already running under another name, and which vocabulary you’d label findings in. Everything here stands on its own: none of it requires adopting our practice, our labels, or our product.

The lifecycle: seven stages from friction to fix

When an agent doing real work hits friction (a missing doc, an ambiguous instruction, a flaky tool), that signal is ephemeral: the agent works around it, the session ends, and the next session hits the same wall. Rahul Garg’s friction patterns frame the first-order cost (the Frustration Loop of generate → review → doesn’t-fit → regenerate); the lifecycle below maps the second-order problem: what has to happen for friction to become a fix at the right level. The gap is measurable: ~90% of teams instrument agent traces, but only ~37–52% systematically evaluate them (LangChain, Jun 2026) — most teams can watch friction; far fewer turn it into fixes.

Stage	The question it answers	Options	Practitioner term
0 · Hosting	Where does the agent run?	local CLI · web · IDE · CI/headless · scheduled	—
1 · Detection	How is friction noticed?	self-notice · secondary-agent review · human correction · telemetry	trace review, error analysis
2 · Instrumentation	How does the agent know to track it?	skill · hook · convention · command	—
3 · Recording	How is it captured, and where?	memory · MCP store · logs/traces · tickets · tagged commits	open coding, episodic memory
4 · Harvesting	How do you gather beyond one session?	trace-mining vs artifact-aggregation · sweep vs event · dedup	—
5 · Synthesis & targeting	Raw records → patterns → what level of fix?	cluster + score, then route by altitude	axial coding, failure taxonomy
6 · Close the loop	Did the fix reduce future friction?	measure the trend	Feedback Flywheel, compounding engineering

Stage 0: Hosting

Everything downstream depends on where the agent runs. A local CLI agent leaves a transcript on disk and can write memory files; a CI or headless agent may be ephemeral, its only trace whatever it logged before the container died; a web or IDE agent keeps server-side history you can query but not grep; a scheduled agent runs with no human watching. Hosting sets the menu for every later stage: what’s observable, where state can persist, and who (or what) can review it. The trade-off: richer local observability versus the reproducibility and central storage of hosted runs.

Stage 1: Detection

Four channels, rarely exclusive. Self-notice (the agent recognizes its own retries and backtracking) is cheapest but most biased: the agent doesn’t know what it doesn’t know. Secondary-agent review, where a fresh agent reads the transcript afterward, is more objective but costs a second pass. Human correction is the highest-quality signal, and still the dominant one: an eight-week production study found ~70% of silent failures were first caught by a human noticing something felt off (arXiv 2606.14589). Telemetry (tool-error rates, permission denials, loop counts) is automatic but shallow — it knows that, not why. The strongest setups triangulate: telemetry flags where to look, a review pass explains why.

Stage 2: Instrumentation

An agent won’t record friction unless something makes it. The options, by how much they lean on the model remembering: a skill (an explicit, portable procedure invoked at a stopping point: clear, but must actually fire), a hook (fires automatically on session start or stop: reliable, but blunt), a convention (a context-file instruction: zero infrastructure, honors-system), or a command (human-triggered: deliberate, but human-gated). This is the stage most often skipped, and it’s why so much friction goes unrecorded: nobody told the agent to look.

Stage 3: Recording

Two questions: what a good record contains, and where it lives. A useful record is evidence-cited (what happened, what it cost), carries one label from a fixed vocabulary so records are comparable later, and ends with a proposed next step. Where it lives, each with a real trade-off: memory files (durable and low-friction, but private and loosely structured), an MCP store (shared and queryable, but needs a server), logs/traces (automatic and complete, but the signal is buried in noise), tickets (actionable and team-visible, but heavyweight per item), or tagged commits and PRs, e.g. a work-material-friction label tying friction to the exact change, though only where work lands in version control. None of this is code-specific: a media team’s account log or a support queue’s annotated history are recording substrates too. One caution that applies to any substrate agents later rely on: agent-written memory is a named attack-and-drift surface (OWASP Agentic Top 10, ASI06), an argument for evidence-cited, reviewed writes.

Stage 4: Harvesting

One session’s friction is noise; the same friction across eight sessions is a process problem. The strategic choice is trace-mining (re-read raw transcripts: complete, but expensive and privacy-heavy) versus artifact-aggregation (sweep the records deliberately written: cheap, but only as good as Stage 3’s discipline); real pipelines mix both. Then cadence (a scheduled sweep versus harvest-on-session-end) and the unglamorous work of dedup: the same friction phrased five ways by five people has to collapse into one pattern with an honest count. Harvesting is where value appears, because aggregation is what reweights priorities: a five-minute annoyance nobody would fix individually is a top team cost in aggregate.

Stage 5: Synthesis & targeting

Two moves. Cluster and score: group findings into patterns, ranked by frequency × cost; this is what the classification schemes below exist for. Target the altitude: route each pattern to the right level of fix, from ephemeral to structural (memory → skill/prompt → environment & config → docs → the work material itself → process → upstream tool or vendor). Under-target (a private memory note for what’s really a missing team doc) and the friction recurs for everyone else; over-target (a new skill for a one-off) and you bloat an artifact until it stops being read. The field converged on the same gradient independently: demote ephemeral memory, promote durable learning to version control — Windsurf/Devin’s docs say to promote recurring lessons to rules or AGENTS.md (the standing instruction file agents read) rather than rely on auto-memories, OpenAI’s Codex guidance says the same-mistake-twice case earns an AGENTS.md update, and Copilot memory expires in 28 days by design: unpromoted memory should die. One synthesis judgment is easy to miss: not all friction is waste. Some of it is the control surface, “friction is what’s necessary… to steer” (a recap of Ronacher’s AIE Europe talk), so triage includes keep-or-kill, not just fix.

Stage 6: Close the loop

The honest test of the whole lifecycle: does friction of that type trend down over subsequent sessions? A fix that’s filed but never lands, or lands but changes nothing, is theatre. This is Garg’s Feedback Flywheel condition and the premise of compounding engineering: each fix makes the next unit of work easier, if the loop actually closes.

The named loops, by operating level

The field has converged on this lifecycle under at least half a dozen names. All of them are good; nothing on this page replaces any of them. The one sort this table applies is the level each loop operates at — and the thing to notice once it’s sorted:

Loop	Runs at	Closes the loop by
Loop Engineering / Compound Engineering	one practitioner	personal rules, prompts, playbooks
agent-retro	one session	per-session skill/config edits from the transcript
Harness-engineering sensors (Thoughtworks)	one codebase’s harness (the scaffolding around the model)	wiring native feedback instruments (tests, linters, CI) into the agent’s loop
Dreaming (Anthropic, OpenAI)	one platform’s memory	idle-time mining of session history into gated memory diffs, fleet-wide
LangSmith Engine / Braintrust Topics	one observability stack	clustering production failures into issues, drafting PRs and evals
Factory Signals	one agent platform	detecting session friction patterns and auto-filing tickets
gh-aw session insights (GitHub)	one platform’s sessions	automated session-analysis reports across agentic-workflow runs (50-session example)
Feedback Flywheel (Garg)	one team’s artifacts	harvesting learnings into priming docs, commands, playbooks, guardrails

Read the middle column again: one practitioner, one session, one platform, one stack. Nearly every loop in the field runs solo or fleet-level: a person and their agent, or a vendor and its whole install base. Only Garg’s flywheel reaches for the team, and his cadence list names the venue (an agenda item in the existing sprint retrospective) without operationalizing it. That’s our reading of the sort, and it’s the one place this guide’s own angle shows: the team level is the open layer — many people, many agents, more than one tool, with the fix-owners in the same conversation. If you run any loop above, keep running it; the team layer consumes their output, it doesn’t compete with them.

The classification schemes

To cluster friction you need categories, and the field’s schemes classify different things; they’re less rivals than instruments pointed at different questions:

Scheme	What it classifies	Shape	Reliability / origin
MAST	how multi-agent systems fail	14 modes / 3 categories	150 expert-examined traces, validated on 1600+; inter-annotator κ = 0.88
Error-analysis school (Husain/Shankar)	whatever your own traces show	open-ended; categories emerge from your data	methodology, not a fixed set; reading your traces is “the most important activity in evals”
Four-Layer (Greyling)	which layer of the stack failed	4 layers	synthesis of field failure reports; ~9.9% of failures attributed to model reasoning
TraceProbe	error-handling actions in traces	9 actions	automated trace analysis
Factory Signals	which friction symptom a session shows	7 signal types	production coding-agent sessions
Our root-cause vocabulary	why the collaboration friction happened	10 labels / 5 groups; group encodes the fix altitude	working sessions, dev and non-dev; inter-rater reliability not yet measured: the experiment is underway, and the vocabulary is versioned and revisable

Two reading notes. First, the axes genuinely differ: symptom schemes (Factory’s signals) tell you a session went wrong; layer schemes (Four-Layer) tell you where in the stack; a cause vocabulary tells you why, which is what lets a label half-route its own fix (a work-material-friction finding points at the material itself — tech debt in code, or a tangled account, board, or template outside it; a briefing label points at process). Second, the universal-versus-emergent tension is real: fixed taxonomies buy comparability and measurable labeling reliability (MAST’s κ = 0.88 is the bar), emergent categories fit your actual failure distribution. A workable middle keeps a small fixed vocabulary for aggregation with open-coded evidence notes beneath each label. And a caution the whole field has earned: agent-error-style labels should be the residual, not the default. The harness-engineering school explicitly rejects that reflex, where the engineer blames the model and files it under “wait for the next version”; fix the harness instead (Osmani, Agent Harness Engineering). The Four-Layer analysis attributes only ~9.9% of failures to model reasoning.

Locate yourself

A short diagnostic. Walk the stages and mark what you already have:

• You have traces or session logs (observability tooling, JSONL on disk, server-side history) → Detection and Recording are covered. The LangChain numbers suggest this is where most teams stop.
• Something reminds the agent to log friction (a skill, a stop-hook, a context-file convention) → Instrumentation is covered; if nothing does, that’s usually the cheapest first fix.
• You update AGENTS.md / CLAUDE.md when something recurs → you’re doing Synthesis at solo level, the Codex same-mistake-twice pattern.
• Your platform curates memory for you (Dreaming-style consolidation, Copilot memory) → fleet-level Harvesting and Synthesis, within that platform.
• Your observability stack clusters failures and drafts fixes (Engine, Topics, Signals) → stack-level Synthesis, for the traffic that stack sees.
• Someone periodically reads across sessions, people, and tools, and the fix-owners decide together → team-level Harvesting and Synthesis. This is the row most teams leave blank.

The common gap, in our observation, is that last row: the aggregate view across tools and people, and the judgment calls it feeds: keep or kill, which altitude, whose priority. Note the review scope question that comes with it: which work belongs in one bucket for one discussion? The repo, the product, the ads account, the support inbox, the client engagement? Scope by where fixes would land, and the non-code cases route as naturally as the code ones.

The rest of this guide takes the layers one at a time: the opener tells the story narratively; later chapters cover capturing friction in the moment, harvesting across sessions, the altitude decision, and what a team-level venue looks like in practice. Start wherever your blank row is.

Next chapter: What a good friction record looks like — capture in the moment, the root-cause labels, and the never-log rules.