As soon as there is more than one task, the question is not about the agent's speed but about your attention. The agents window brings several sessions, several workspaces, worktrees and a shared change review together in one place. Two attention-management tools live next to it: a side chat for a short question that should not inflate the main context, and search across past conversations. Together they turn a pile of chats into a manageable structure where every branch has a purpose rather than merely a tab of its own.
The naive practice is to run everything in one chat. It grows, mixing the task, exploration, stray questions and decisions, and an hour later nobody remembers which assumptions were rejected and which were accepted. The model too: a long history gets compacted, and what goes into the compaction is exactly what seemed obvious and was therefore never repeated. One endless conversation is not an economy but a way to lose both the context and the trail of decisions: you will have to reconstruct them from the diff, that is, from a result that does not show the reasons.
The right model is simpler. The main chat carries one coherent task. The side chat holds an exploratory question off to the side so the line is not knocked off course. A new agent is a separate area of work with its own state. The message queue is the next step of the same task, not a parallel branch. Conversation search is a way back to a previous explanation, not a guarantee that old facts still hold. All five mechanisms differ on one trait: whether the result outlives the closing of a tab, and whether it needs the same context as the current work.
It helps to lay these mechanisms out in a table with a do-not-use-as column once. Below is that map. The right column is the most useful part: it names the typical substitutions that stop a mechanism from working - an endless log instead of a task chat, an important decision left in a side conversation, the expectation that a new agent will somehow learn a neighbor's conclusions.
| Mechanism | Use it for | Do not use it as |
|---|---|---|
| The main chat | Solving one coherent task | An endless project log |
| A side chat | A short investigation or clarification |
| A home for an important decision with no carry-over |
| Conversation search | Returning to a previous explanation | A guarantee that old facts still hold |
|---|
| A queued message | The next step of the same task | A parallel independent branch |
|---|
| A new agent | A separate scope and separate state | Automatic synchronization of conclusions between agents |
|---|
The choice between the queue and a new agent comes down to one question worth asking out loud. The agent is editing the authentication module, and you notice a typo on a neighboring screen. If the fix relies on the same context - the same files, the same decisions already taken - it is the next step of the same task and belongs in the queue. If it stands on its own, it needs a separate agent with its own state; otherwise you dilute the context of the current work with something foreign and get two half-finished jobs instead of one finished one.
Side chats have a subtlety that decides everything. They are full, durable conversations, and that is their virtue: exploration does not clutter the main line. But if the result of that exploration influenced the implementation, it has to be carried over - into the main conversation, into the plan, into a tracker issue or into the repository's documentation. Otherwise the decision stays in a thread that will be closed and archived, and a week later nobody will remember why it was done this way. What is worth carrying over is not a retelling but the conclusion together with its grounds: what was checked, what was found, why this option was chosen.
Conversation search is useful exactly as an archive, not as a source of truth. It finds where you already discussed this and saves repeated investigation. But the explanation it finds refers to the state of the repository and the product at that time. Checking it against the current code is a mandatory step, otherwise you bring into today's task a conclusion that was true three releases ago. Explanations of how the system works are especially treacherous here: they sound like domain knowledge while describing one concrete implementation that may well have been rewritten since.
Parallelism has a price, and a human pays it. Throughput is limited not by the number of agents but by your capacity to read their results: every branch demands a look at the diff, a check and a decision about merging. The sign that you have crossed that line is easy to recognize - finished changes pile up unreviewed, and diffs are accepted on their size and the confident tone of the report rather than on their content. From that moment parallelism does not speed the work up but defers it, and the cure is fewer simultaneous branches, not a faster model.
The engineering conclusion about parallel attention is simple: the more windows there are, the more important it is to agree what lives in each. One task - one main chat; exploration off to the side; independent work in a separate agent with its own state; conclusions out into a place that outlives the session. That discipline costs a couple of minutes and saves hours of restoring context.
The typical failures are predictable. Growing one chat until everything is mixed inside it. Leaving an important decision in a side conversation and losing it along with the context. Treating an explanation found by search as current without checking it against the code. Opening more branches than you can review. And expecting parallel agents to synchronize each other's conclusions on their own.