When everyone can work at once

Picture a developer handing a small feature to three agents.

The feature is an export button. One agent will build the interface, one will handle the service behind it, and one will write the documentation. The work seems easy to separate. While they run, the developer turns to another task.

The first result looks good. There is a button where a user would expect it, a loading state, and an error message. The second agent has built a service that checks permissions and produces a file. The third has written a short explanation of how to download your data.

Then they try it together.

The button is available to every member. The service allows administrators. The documentation says the download contains only the requesting person's records. The service produces an organization-wide export.

This is a fictional example, but it gives us a useful place to stop. Each agent has made a plausible version of an underspecified feature. The developer now has three finished-looking outputs and a product decision to make.

The conversation arrives after the work

Suppose the developer explains that the feature is for administrators exporting organization data. The interface agent changes the button's visibility. The documentation agent rewrites its explanation. The service agent confirms that its behavior already matches.

For a moment, everything is aligned.

Then the interface agent asks what should happen if an administrator loses that role while an export is running. The service agent has assumed permission is checked when the request begins. The documentation agent has described access as if the permission must still exist when the download happens.

The developer has to come back again.

Some of this conversation is valuable. The agents have exposed a question the original request left open. The difficulty is that the first answers were already taking shape in code and prose before anyone recognized the question as shared.

Try another approach. Give every agent the whole discussion. Now they all receive the original request, the revised requirement, the abandoned personal-export idea, and the unresolved question about a role changing mid-operation.

They have more information. They also have to work out which parts govern the next action. If the developer changes the answer in one conversation, the other conversations still need to catch up.

The promise of parallel work remains attractive. There are pieces each agent could finish independently. The team is spending effort discovering where that independence ends.

What belongs to the whole team?

Restart the same hypothetical feature with a different division of responsibility.

Before implementation, someone owns the small group of decisions around access: which person can request an export, what records it contains, and when permission is checked. Another owns the delivery contract: how a request is tracked, how completion is reported, and what happens on failure.

The interface agent can choose how to present progress within that contract. It does not need to rediscover the access model. The documentation agent can explain the same accepted behavior without reconstructing it from the service implementation.

Call these decision groups if that term is useful. The important thing in this example is what they contain. Decisions that force several tasks to change together have a shared place and an accountable owner. Choices whose effects stay local can remain with the agent doing the work.

This arrangement introduces a little work before implementation. Someone has to separate what is known from what is still open. It may also reveal that a task cannot yet be delegated cleanly. That is useful information to have before three agents complete different interpretations of it.

The record need not become a miniature specification for everything. For the export feature, a few precise sentences about scope and access would settle much of the disagreement. Recording why the rule exists gives an agent something to examine when a new requirement challenges it.

The question about losing administrator access can then return to the decision owner as a specific exception. Once resolved, it updates the shared account of how the feature works. The implementation tasks have one answer to consume.

Other teams have met versions of this problem

Cursor describes planners independently deciding the same question in its agent swarms, along with agents repeatedly changing work based on conflicting designs. Its reported responses included shared decision documents, clearer decision responsibility, references checked against those documents, and neutral handling of conflicts. It also experimented with a short guide provided to newly started agents. Those changes are described in its engineering account.

Anthropic reports a related delegation problem in its multi-agent research system: vague assignments led agents to duplicate work. Clearer objectives, expected outputs, and boundaries helped define what each agent should do. The account also discusses the cost of coordination and the difficulty of tasks with many dependencies.

These examples give a small team useful questions to ask about its own setup. Where are two agents free to decide the same thing? Which answer will the next agent inherit? What happens when a sensible local change affects someone else's task?

Mana can support part of that arrangement by keeping decisions and their evidence available across agent sessions. Its keyed records can be corrected with history retained, and its standing context can give new sessions shared working guidance. The team still needs to decide who owns a question and how a conflict reaches them. Who can read a decision is a separate boundary. Storing a decision does not prove that every task followed it.

Leave room for the agent that finds the flaw

There is a temptation to take the export story as an argument for settling everything before work begins. Follow that approach too far and the developer becomes responsible for anticipating every detail. The agents spend their time waiting for answers the work itself could have revealed.

Return to the question about a role changing during an export. That was a useful discovery. A system organized only to reduce messages could suppress it and appear efficient while keeping a defect.

The distinction I would watch is between reopening an answer because it was lost and reopening it because new evidence changes the problem. Shared memory can help with the first. A capable team should make space for the second.

I would also resist claiming that decision groups saved time merely because the conversations became shorter. The comparison needs the finished result, the corrections it required, and the cost of getting each session ready to work. This remains a design to examine until those outcomes are measured.

At the end of the hypothetical export task, the developer reviews a button, a service, and an explanation that refer to the same behavior. One unexpected question has changed the design. The rest of the work has proceeded without requiring the developer to retell the feature in three conversations.

That seems a more interesting ambition for an agent team than keeping every agent busy. Give each enough shared understanding to work alone, and a clear way to bring back something the team has not understood yet.