jkchang.uk
Article · 4 Aug 2026Agentic systems · Context engineering9 min read

Less role play, more boundaries: governing attention in multi-agent AI

Calling a model a Research Agent does not make it good at research. What separates one agent from another is what each is allowed to notice, remember, touch and trust.

Most multi-agent demos come with the same diagram. There is a box for a researcher, one for a writer, one for a reviewer, one for a planner and one for an executor, joined by arrows that run from left to right, and the whole thing looks like a small, well-run team. I understand why it persuades. We have all read org charts, and an AI system drawn in that shape borrows the trust we already give to teams, where someone checks the facts, someone checks the writing and someone signs off before anything goes out.

That familiarity is also the trap. The hard problem in multi-agent AI, as I see it now, is governing attention: deciding what each part of the system can notice, remember and act on at a given moment. Dividing the work between roles is the easy part, and it is the only part the diagram shows.

A name is not a capability

A model does not become good at research because its system prompt calls it a Research Agent. The label changes something, usually the tone and the shape of the answer, but research is a set of conditions rather than a manner of speaking. An agent is useful at research only when it can reach the right sources, has some way to judge how strong a piece of evidence is, keeps track of what is still uncertain, and is able to say that the evidence isn't good enough to answer the question. Take those away and you are left with a model that writes in the voice of a researcher, which may be worse than one that doesn't, because the voice is persuasive.

The label also seems to do less than we assume. In 2024 Mingqian Zheng and colleagues tested a large set of persona prompts across several families of open models on factual questions, and found that adding a role to the system prompt did not reliably improve accuracy; which persona helped on which question looked largely random. A role, on that evidence, is closer to a costume than a skill.

So the first thing a role should mean is a set of conditions: the sources an agent can reach, the checks it can run and the uncertainty it is asked to keep. The name on the box is the least of them.

A reviewer that sees only the draft reviews the surface

Review is where the gap between label and capability is widest, because a Review Agent sounds like the responsible part of the system. Look at what it actually receives. In the simplest version of the diagram the reviewer gets the final output and a prompt asking it to check the work. It doesn't see the original request, so it can't tell whether the draft answered the question that was asked or a nearby, easier one. It doesn't see the sources, so it can't tell whether a claim is supported. It doesn't see the search trail, the assumptions made along the way or the edit history, so it has no way of knowing that an earlier step dropped a weak result, or quietly lost a constraint the user gave at the start.

A reviewer in that position can still do useful work. It can improve the tone, catch a contradiction between two paragraphs, and notice when a figure in the summary doesn't match the figure in the table. What it can't do is tell whether the work underneath is sound, because the evidence for that was never passed to it. It is reviewing the surface.

Safety engineering has a picture for this. In James Reason's Swiss cheese model of accidents, each layer of defence is a slice with holes in it, and an accident gets through when the holes in several slices line up. Adding a slice helps only if its holes are in different places. A reviewer that reads the same text as the writer, with the same model and much the same prompt, has its holes in the same places, so it adds a layer of confidence without adding a layer of defence. I wrote about one version of this, a verifier that checks a summary when it should check the source, in From loops to graphs, and the fix is the same here: give the check a different view of the work, ideally the evidence itself.

Boundaries are what make agents different

Roles alone don't create capability. Boundaries do: what each agent can see, which tools it can call, what state it can write to, and which environment it runs and fails in. If several agents see roughly the same context, use the same tools, write to the same state and fail inside the same environment, the system is not meaningfully multi-agent. It is one intelligence wearing several hats, and the hats are mostly for the people watching.

Several hats on one intelligence, and agents separated by boundariesLeft: five role-labelled agents (plan, research, write, review, execute) sit inside one shared region of context, tools and state, and the last one acts on the environment. Right: four agents, each inside its own boundary. Research reads the sources and is read-only; writing sees cited evidence and can change only the draft; review sees the draft with its history and rereads the sources, and can send work back; execution runs in a sandbox with scoped permissions and is the only agent that touches the environment. acts on reads evidence draft + history rereads sends back approves acts Plan Research Write Review Execute Environment Sources Research Write Review Execute Environment ONE INTELLIGENCE, SEVERAL HATS AGENTS DEFINED BY BOUNDARIES SAME CONTEXT · SAME TOOLS · SAME STATE five labels, one view of the work READ-ONLY DRAFT ONLY SEES SOURCES + TRAIL SANDBOX · SCOPED AGENT CHECK SOURCES
Fig. 1 Left, five labels on one view of the work. Right, each agent is defined by what it can read and change: research is read-only, review rereads the sources and can send work back, and only execution touches the environment, from inside a sandbox.

The other side deserves a fair hearing, because there is a serious argument that the hats are the better design. In June 2025 Walden Yan of Cognition published a post called "Don't Build Multi-Agents", arguing that when a task is split across agents that don't share their full context, each one makes implicit decisions the others can't see, and the pieces come back in conflict. A single agent with one continuous history, the argument goes, is usually more reliable. Around the same time Anthropic described the research system behind Claude's Research feature, in which a lead agent sends subagents off in parallel, each with its own context window, and reported that it did better than a single agent on broad research questions, at a much higher cost in tokens.

Read side by side, the two posts look like opposite advice, but they agree on more than it seems. Cognition's warning is about agents that need the same context and don't get it. Anthropic's design works because its subagents are given deliberately different slices of the problem, and each returns a condensed finding rather than its whole history. Neither post is really about how many agents there should be. Both are about what each agent gets to see.

That is where I land too. If every agent in a design would need the same context, one agent with a good harness is often the honest choice, and the extra boxes add latency and little else. Separation earns its cost when it buys a different view: a reviewer that reads the sources instead of the summary, a researcher whose context isn't crowded by the draft, an executor that can touch the environment while the planner can't.

The better question is about attention

The question I find more useful than "which agent does what?" is "what should the system be paying attention to at this moment?"

Attention is the right word here, and not only as a metaphor. Herbert Simon described the economics of it in 1971, when he wrote that "a wealth of information creates a poverty of attention". A model with a long context window doesn't escape that. Everything placed in front of it competes for the same limited attention, and the instruction that mattered can lose to forty pages of retrieved material beside it; Nelson Liu and colleagues showed in 2023 that models use information at the start and end of a long context far better than information buried in the middle. Inside a transformer, attention is learned. Between the steps of an agent system, it has to be designed.

Organisations worked this out before agents did. In 1997 William Ocasio proposed an attention-based view of the firm, in which what a company does depends on what its decision-makers attend to, and that in turn depends on the company's structure, its rules and the channels through which information reaches people. Read that way, the org-chart metaphor was never really about titles, even for people. A review team works because the reviewers have the file, the authority to send it back, and a reason to look for problems rather than polish. The title on the door is the least of it.

Each stage of a piece of work needs its own attention profile. For research, attention should be governed around evidence, source quality, gaps and uncertainty. For writing, it should sit on structure, clarity, pacing and the reader. For review, it should go to failure modes, overclaiming, missing counterevidence and hidden risk. For execution, it should cover permissions, side effects, changes to the environment, tool responses and recovery.

Attention profiles for four stages of workA grid with one row per stage. Research pays attention to evidence, source quality, gaps and uncertainty; it sees the question, the sources and search tools; it changes only its notes and citations. Writing pays attention to structure, clarity, pacing and the reader; it sees the brief, cited findings and who the reader is; it changes the draft. Review pays attention to failure modes, overclaiming, missing counterevidence and hidden risk; it sees the request, the sources, the search trail, the assumptions and the edit history; it records findings and can send work back. Execution pays attention to permissions, side effects, environment changes, tool responses and recovery; it sees the approved plan, tool schemas and the state of the environment; it changes the environment, inside a sandbox, with rollback. STAGE PAYS ATTENTION TO SEES CAN CHANGE Research evidence, source quality, gaps, uncertainty the question, the sources, search tools its notes and citations; nothing outside Writing structure, clarity, pacing, the reader the brief, cited findings, who the reader is the draft Review failure modes, overclaiming, missing counterevidence, hidden risk the request, sources, search trail, assumptions, edit history findings; can send the work back Execution permissions, side effects, environment changes, tool responses, recovery the approved plan, tool schemas, environment state the environment, inside a sandbox, with rollback the shaded columns are designed, not prompted
Fig. 2 One attention profile per stage. The prompt can say what to pay attention to; what a stage sees and what it can change are set by the system around it.

The left-hand column of that grid can be written into a prompt. The other two can't, because they are properties of the system: the context you assemble for each step, the tools you expose to it and the state you let it write. That is why I think of this as context engineering applied between agents rather than inside one. What you leave out matters as much as what you put in. A writing step that is handed the raw search results is being invited to research again, and a review step that is handed only the polished draft is being invited to admire it.

When agents leave the chat

All of this matters more once agents move beyond conversation. An agent that can edit code, call APIs, send emails, submit forms, delete files or write to a database is no longer producing text for a person to read and judge. It is changing things, and some of those changes can't be taken back. At that point the problem is no longer the quality of the output. It is operational risk, and operational risk is not solved by better labels, because a prompt that tells an agent to be careful is not a control.

Computer security settled the principle half a century ago. In 1975 Jerome Saltzer and Michael Schroeder set out design principles for protecting information in computer systems, and one of them was least privilege: every program and every user should run with the smallest set of privileges the job needs. An executor agent is a program, and the principle applies to it unchanged. Its context can be talked into things, by an ambiguous instruction, a misleading tool response or text injected into a page it reads, but its permissions can't be talked out of what they allow.

The architecture that handles this is not exotic, and none of it is about roles. Sandboxing limits where a mistake can land, and scoped permissions limit what a mistake can do. Logs record what each agent saw and did, so a failure can be traced to the step that caused it instead of guessed at. Rollback makes some irreversible actions reversible, and human checkpoints put a person in front of the ones that stay irreversible. Isolated state stops one agent's bad write from becoming every other agent's premise. Verifiable feedback loops close the circle by checking the result of an action against the environment itself, not against the agent's account of what it did.

A governed execution graphA request goes to a read-only research step that cites sources, then to drafting, then to review, which rereads the sources and can send the draft back. Review flags risky actions to a person, who approves them. Execution runs in a sandbox with scoped permissions: it saves a snapshot, acts on the environment, and checks the result against the environment itself; the snapshot allows a rollback. Every step writes to a shared log of what it saw and did. asks cites evidence draft + trail rereads sends back flags risk approves saves state acts checks result rolls back Request Research Sources Draft Review Sign-off Execute Snapshot Environment GOVERNED EXECUTION GRAPH SANDBOX · SCOPED PERMISSIONS LOG · EVERY STEP RECORDS WHAT IT SAW, DECIDED AND DID AGENT CHECK PERSON DATA
Fig. 3 A governed execution graph. Review rereads the sources and can send the draft back; a person approves risky actions; execution saves a snapshot, acts inside a sandbox and checks the result against the environment. Every step writes to the log.

In the agent systems I build for legal work, people are part of this architecture by design. Lawyers sit at the checkpoints that matter, and guardrails decide what each agent is allowed to see and do.

Execution graphs, not little companies

So I suspect the best agent systems won't look like little AI companies. They will look more like carefully governed execution graphs, in which each node is defined less by its job title than by its boundary: the context it is given, the tools it can call, the state it can write, the checks that stand between it and the world, and the person who can stop it.

I usually put the single-agent version of this as agent = model + harness. The multi-agent version is the same formula with the harness doing more of the work, because the harness is where attention is governed: what goes into each context, what stays out, and what each agent is trusted to do with what it sees.

A role is a prompt. A boundary is architecture.

What I don't have a good answer to yet is how to test attention directly. It is straightforward to check whether a system's answer was right, and much harder to check whether its reviewer looked at the right things on the way, or only happened to agree with an answer that was right for other reasons.

There is a simple test that can be applied to any multi-agent diagram in the meantime, including the five boxes this piece started with. Delete the role names. If nothing is left to tell the boxes apart, no difference in what they can see, remember, touch or trust, then the system is one agent and the names were doing work the architecture should have done. If the boxes are still easy to tell apart, the names hardly matter, and you could call them anything.

Jiakang Chang · Principal Software EngineerAll articles