Your coding agent ran for an hour and left a trail of suggestions embedded in its output — tech debt it noticed, edge cases it deferred, follow-up tasks it flagged to stay in scope. Maybe a dozen in total, a few of them genuinely worth doing. Now what?
You grab the most obvious one. The rest are in the chat window that you'll close when you start the next task. By tomorrow, the window is gone and so is everything in it.
This is a distinct problem from getting the agent to produce output. Agents are good at flagging. What they're less good at — and what most tooling doesn't address — is keeping track of what they flagged between sessions. The suggestions live in the conversation history, distributed across however many tasks ran this week, and the moment the window closes, they become noise.
The core tension
There are two defensible positions on what to do with agent suggestions, and most experienced developers have tried both:
Capture everything. The flags are the most valuable thing the agent produces — a live map of what the codebase actually needs, generated while the context is highest. Losing them is throwing away calibrated signal.
Capture nothing deliberately. Most suggestions are noise. Capturing them builds a graveyard of TODOs you'll never touch. Aggressive in-session decisions are better than a stale backlog you've stopped trusting.
Neither is wrong. What they agree on is that something has to happen at the point of suggestion, before the window closes. The patterns below are the different ways developers resolve that decision.
Five patterns in practice
Structured context files (Obsidian, Notion, or markdown docs)
Keep one living document per concern — architecture decisions, product direction, infrastructure, security posture. When the agent surfaces a suggestion, it either belongs in one of those documents and gets written there immediately, or it gets dropped. The filter is "does this belong somewhere maintained?" rather than "is this good?" If yes, the document is the backlog. If no, nothing is.
This pattern handles suggestions that have a natural home well. It's weaker for one-off items that don't map to an existing category — they tend to fall through.
Formal issue trackers (Linear, GitHub Issues)
Suggestions that survive the end of a session get filed as issues. The act of filing is the filter: if it's not worth 30 seconds to create a ticket, it wasn't worth keeping. Teams running multiple agents in parallel tend toward this because the issue tracker becomes the coordination layer — the queue has a single home that agents, reviewers, and the next session can all see.
The cost is friction. For solo developers, creating issues for suggestions raised during a one-hour task can cost more overhead than the suggestion is worth. It scales better than it starts.
A running backlog file with priority tags
One file in the repo, sorted by priority, updated after each session. You write to it — the agent doesn't. Priority tags (P1/P2/P3, or a simple "agent-ready" marker) let you feed the best items back into the next task without reviewing the full list. The backlog lives in git, it's visible to everyone, and it has no external dependency.
This is the pattern that generalizes most cleanly across team sizes. The failure mode is drift: the file grows faster than it's pruned, and a backlog nobody trusts is worse than no backlog.
A triage label system (needs-triage → ready-for-agent)
Two states. Everything flagged by the agent goes into needs-triage. After each session — or daily — you promote items to ready-for-agent or drop them. The agent only ever receives ready-for-agent items; the triage step absorbs the noise before it becomes a task.
This pattern inverts the usual flow: rather than generating tasks from scratch each session, the agent executes tasks that a human has already reviewed. Lower throughput, but higher confidence in what gets executed.
The ten-item cap (aggressive filtering at capture time)
Keep the backlog under ten items. When the agent flags something, decide immediately: fix it now, file it — displacing something else if needed — or drop it. The cap forces prioritization at the moment of capture, when context is highest, rather than deferring to a review session that may not happen.
The hardest part is the drop. Accepting that most of what the agent flags is noise is uncomfortable the first time. It gets easier when you observe that the codebase is fine without the items you dropped — the suggestions were suggestions, not requirements.
The common thread across all five: there is a human review step between what the agent flags and what becomes a task. The variability is in when that review happens — immediately, in batch, or on a fixed cadence — and where the surviving items live. None of these patterns let agent output go directly into the execution queue unreviewed.
That is the right constraint. Agents are good at surfacing. They are not good at triaging — they don't know what you've already decided, what has been tried before, or what matters relative to everything else in flight.
Where the suggestions actually get lost
The patterns above all assume that you are transcribing suggestions from the agent session into wherever they live. That step — reading the output, deciding what to keep, writing it somewhere — is where most suggestions actually disappear, not because they weren't worth keeping but because there was no defined moment when the transcription was supposed to happen.
The end of an agent session is one of the worst moments for this. You're context-switching to the next task, the window is about to close, and "copy the flagged items into the backlog file" is exactly the kind of friction that slips. The irony is that the context for evaluating the suggestion is highest right now and lowest an hour from now.
Running multiple agents in parallel makes this worse: each session generates its own stream of suggestions, and the aggregate noise grows with agent count. We wrote about the attention cost of scaling agent count in the cognitive load of running parallel Claude Code agents — the backlog problem is a specific instance of that broader issue.
Moving the capture into the session
One approach to the transcription problem is to have the agent write to the backlog during the task rather than after. Not autonomously — you still review and decide — but the flag and the capture happen in the same moment, while the session is open, rather than requiring a separate step once it's closed.
This is what defract does with its backlog capture: during a task, the agent can write flagged items directly to a structured queue. The queue is yours, the agent can't act on it without your review, and nothing gets added without you seeing it. What changes is that the gap between "agent flags something" and "that flag has a durable home" closes from "maybe later, if I remember" to "right now, in session." We covered the mechanics in detail in when the AI agent proposes the next task.
The triage step — what gets kept, what gets dropped, what runs next — still belongs to you. What the in-session capture removes is the transcription burden, which is where the attrition happens. The pattern isn't new: it's the triage-label approach above, with the initial capture moved one step earlier. The difference is that "later" no longer means "after the window closes."
defract is in open beta
structured task capture, gated lifecycle, and shared memory for your parallel Claude Code agents. free, no caps, no signup.