when your AI coding agent proposes the next task

You assign a task. Your agent starts on it. Somewhere in implementation, it finds something adjacent — a helper function that should be extracted, a test case that's missing, an API surface the new feature will break. The code for the fix is obvious. The context for why it matters is right there.

What happens next depends entirely on the tool you're using.

The executor model

Most AI coding tools are executors: you give them a task, they complete it, they stop. Adjacent observations get folded into a comment, a TODO, a note at the bottom of a commit message. You're expected to notice, extract, and add it to your backlog manually.

This isn't a design flaw. An agent that starts chasing tangential work on its own is unpredictable and expensive. The executor model trades off backlog coverage for task focus. It's a reasonable trade.

But the cost is real. A typical implementation task produces several "by the way, this also needs..." signals. Those signals get buried in diffs, forgotten in chat logs, or turned into informal reminders that never get scheduled. Across multiple parallel agents — all running simultaneously on different tasks — the backlog drift compounds. Each agent knows what it found; nothing coordinates what gets prioritized next.

Why adjacent work gets lost

The traditional response is a scratchpad: a shared doc, a Notion backlog, a GitHub issue opened manually after the agent finishes. This works. It also adds a step that carries friction, and that friction is highest when you're in motion — reviewing an agent's output, approving a design, managing three or four parallel workstreams at once.

There's a subtler problem. The context for why adjacent work matters is richest at the moment the agent surfaces it. The connection between "this extraction is needed" and the specific code path that reveals the need — that context decays fast. By the time you're manually writing a ticket two hours later, you're reconstructing it from memory. The ticket becomes thinner, the rationale gets compressed, and the task that ends up scheduled bears less resemblance to the one the agent actually observed.

At small scale this is annoying. At the scale of multiple parallel agents running through a real feature backlog, it becomes a structural gap between what the agents saw and what gets scheduled.

What a co-developer model looks like

The alternative to a pure executor isn't an autonomous agent that rewrites its own instructions. It's an agent that can raise a hand: "I noticed this. Here's why it matters. Approve or ignore."

This framing — agent as co-developer rather than code executor — changes what the backlog is. Instead of a list you maintain separately, it becomes a shared artifact that agents and humans contribute to together. Agents build it from what they observe; humans decide what enters. The gate is always human. The observation is always agent.

Two concrete mechanics make this work in practice.

Structured decomposition from a conversation

Before any task starts, a chat agent can take a rough project description and break it into phases, ordered tasks, and dependencies. Not a flat list — a structured decomposition that preserves the logic of why task B must follow task A, and which tasks can safely run in parallel. You review the proposed structure before any agent touches code. You edit, reorder, or discard tasks before committing.

This is distinct from just prompting an agent to "make a plan." The output is machine-readable: phases, explicit dependencies, estimated complexity — structured to feed directly into a pipeline that other agents can execute. The human review step is a real gate, not a checkbox.

If you're already running Claude Code on a structured project, this kind of decomposition session is worth doing once at the start. It makes implicit ordering explicit and catches dependency issues before they become mid-task surprises. See a structured pipeline for Claude Code for more on why stage ordering matters for coherent output.

Mid-task backlog capture via MCP

The second mechanic is more important for ongoing work. While a stage agent is running — architect, implementer, reviewer — it can call a tool that submits a backlog item for human approval. The item arrives with context: what triggered it, which code path revealed the need, why the agent flagged it. You approve or discard. Approved items enter the backlog; discarded items are gone. The agent continues its current task without deviation.

The tool is delivered via MCP, which matters for a few reasons. The agent isn't writing a TODO comment that might or might not be read. It isn't appending to a shared doc or firing a notification. It's making a structured proposal through a defined channel with a binary human decision on the other end. The proposal is timestamped, contextualized, and linked to the work that generated it. If you discard it, it's cleanly discarded. If you approve it, the context travels with it into the backlog.

Why this changes the parallel-agent picture

When you're running multiple Claude Code agents in parallel, the backlog problem multiplies. Each agent is executing a task. Each task generates adjacent observations. Without a capture mechanism, those observations scatter across commit diffs, chat logs, and your own working memory.

With mid-task capture, each agent becomes a contributor to a shared backlog. The backlog grows from what agents observe, not from what you can manually synthesize after the fact. Your review work becomes curation — approving, discarding, reprioritizing — rather than reconstruction from first principles.

This also connects to the broader context-across-agents problem. Adjacent work that gets captured and approved carries the context that generated it. The agent that eventually picks it up can see not just what needs doing, but why — the specific code path or decision that surfaced it. That's a meaningful difference from a ticket written from memory two hours later.

The backlog as a system property

A backlog that agents contribute to but can't modify unilaterally has a different quality than one built entirely by hand. It's more complete — agents observe things humans miss during review. It's more contextualized — capture happens at the moment of observation, not hours later. And it's more reliable — the human approval gate means nothing enters the pipeline without explicit intent.

The tradeoff is tooling. This kind of mechanic requires an MCP server the agents can call, a structured backlog that accepts proposals, and a review interface that surfaces them at the right moment. None of this is trivially assembled from raw Claude Code.

defract builds both mechanics into the lifecycle. The structured decomposition and mid-task capture are part of the pipeline, operating within stage boundaries rather than around them. If you're running Claude Code agents and maintaining a backlog by hand, it's worth seeing how the two are meant to connect.