Unsupported claims caught out of 80 and total tokens
used.
Wrapping up
When do you split an agent?
Look for this
The agent drops requirements as its task grows,
has more work than fits in its context, or does
more than you can keep track of.
Tradeoffs
Costs can rise when the split adds work, but
narrower tasks can run on cheaper models.
Complexity moves from the agent into the system,
which is easier to control but still needs
design and monitoring.
Wrapping up
Try it out
Look for a place in your projects where your agent is
doing too much, and try to integrate something you
learned today.
Wrapping up
Next session
Publish deadline is October 27.
Today we're going to cover scaling beyond one agent to a whole
bunch of agents, including when and why you would want to do
that in the first place.
Last week we gave the newspaper research via MCP and an
interactive editor built with MCP Apps. The agent searches and
reads sources, writes stories, and lays them out on the page.
We also added a second kind of model to the application: Jev, a
decision model. It answers narrow questions in a fixed format
rather than writing prose. The fact-check bar on each story is
one of those answers, Jev's estimate of whether the story needs
more verification.
Handing that question to Jev was already a form of delegation,
because a separate model answers it instead of the main agent.
Today we extend that pattern to agentic work. Some tasks benefit
from being distributed across independent agents, and to find
them we first need to know where a single agent tends to perform
poorly.
Back to the restaurant. Lalima is our chef, the model. Harry is
the restaurant manager, our harness. Tim, our general worker, is
a tool. Bob stands for any outside service.
Lalima is overloaded. She prioritizes orders, starts the parts
of recipes that take a long time, and plates every dish, among
many other jobs. Bringing in subagents means bringing more chefs
into the kitchen: a sous chef, a grill chef and whatever other
staff the work needs.
Jev is already one of these staff members: someone very good at
quickly picking a course of action from a few options. Lalima
can stay head chef with a team sharing her work, and Harry keeps
running the operation as the staff grows.
Bringing that back to agents: when is an agent overloaded, and
what does that mean exactly? It is overloaded when the task is
more complex than the model can manage without cutting corners,
or when it keeps reaching the context limit within a single
task. As a rule of thumb, changes have also become brittle when
you cannot add a capability without making the agent worse at
what it already does.
Any of these is a reason to consider splitting the work up. The
exact limits vary a lot between models, so when an agent behaves
strangely, read its execution log to see where you have hit
them.
Anthropic, Building Effective AI Agents: Architecture Patterns
and Implementation Frameworks. Its account of context that grows
too complex for one agent supports the second sign.
Here is the first limit in action: a task complex enough that a
single agent cuts corners. The agent fact-checks a long story
about a county library system, using search and read tools over
an archive of the system's documents. Some of the story's claims
are wrong, and a few are wrong in ways that only a newer
document reveals.
Demo steps. In the demo app, open the editor's ••• menu and
choose Load demo story, which places the library-system story on
an empty page. Set the header's Arrangement menu to Single
agent, select the story and choose Fact-check with the single
agent. While it runs, open Execution: a single agent, in a
single context, searches and reads for one claim after another,
and its context grows with every document it reads.
When the run finishes, open Fact-check details and look through
the verdicts for a claim marked supported that should not be.
Open that verdict in Execution: it cites the document and quote
that settled it. The usual pattern is an older document that
matched the search first, such as a notice that was later
superseded, while the newer document that contradicts it was
never read.
The exact misses change from run to run, so pick whichever one
the run produces. If a run happens to miss nothing, use the
recorded runs instead: in each of them the agent missed between
seven and ten of the forty unsupported claims.
The agent had the right tools and the right documents. It ran
out of attention, not information. Next we fix this by arranging
agents so each one has a task narrow enough to do thoroughly.
Open the floor for questions before continuing.
Recorded run, October 21, 2026, GPT-6 Luna through the workshop
broker, on the 160-claim story with 80 unsupported claims: the
single agent caught 33 and wrongly flagged 5 true claims.
Once we decide to use more than one agent, we have to decide how
the work is distributed across them. That choice is the
orchestration pattern, or agent topology, and topologies fall
broadly into three categories.
A structured topology fits when there is a well-understood
process for how data flows through the agents, so we can model
that process directly. Graphs and hooks are the examples here.
An unstructured topology fits when we know what knowledge or
specializations the agents need, and may even need several
agents of the same kind, but which agent does what depends on
the request. Swarms are the example here. Semi-structured
topologies are a catch-all for newer, more advanced approaches
in which an agent creates the agents and their topology
dynamically.
Anthropic's patterns report uses different names: its
centralized architectures correspond roughly to structured
topologies, its decentralized architectures to unstructured
ones, and its dynamic agent generation to semi-structured ones.
Each category contains a variety of patterns, and the next
slides go through some of them.
Anthropic, Building Effective AI Agents: Architecture Patterns
and Implementation Frameworks. Zhang, Kraska and Khattab,
Recursive Language Models, arXiv:2512.24601.
Among the structured approaches, the pattern we focus on, and
the one you are most likely to see in practice, is the agent
graph. A graph is a good option when a single agent already
follows a predefined process and you want to give some of its
steps to more specialized agents.
Graphs usually support conditions and loops. A process that
accepts a document draft and refines it until it meets some
criteria can be modeled as a graph of two agents in a loop, an
editor and a reviewer, with the reviewer's approval as the
graph's completion condition.
If someone asks whether Jev could be the reviewer: Jev can
return approve or reject, but in this loop the editor needs the
reviewer's specific feedback on what to change, which a decision
model does not write.
A graph can also run steps of a process in parallel. When steps
do not depend on each other, as in the fact-checker, each can go
to its own agent, and the agents can run at the same time to
finish the work faster.
The newspaper's story makes a whole set of claims, and each
needs to be judged as well supported or not. As a graph, the
fact-check takes the full set of claims as input and starts a
separate agent for each claim. None of these agents depends on
another, so all of them run concurrently.
This is the demo from before, now running as a graph. The single
agent responsible for the whole story missed between seven and
ten of the unsupported claims in each run, including the Juniper
manager claim in two of the three runs. The graph, with a
separate agent for each claim, caught and corrected all but two.
The graph works here for two reasons. Each agent's task is
simpler than the single agent's, and every claim is guaranteed
dedicated attention, because code starts an agent for it rather
than leaving the single agent to decide how much effort each
claim gets.
Open the floor for questions before continuing.
Recorded runs, October 21, 2026, GPT-6 Luna through the workshop
broker, on the 160-claim story with 80 unsupported claims: one
single-agent run, and one graph run with an agent for each
claim. These are the runs demo mode replays.
The other structured pattern to show is the hook. As we use the
term here, a hook covers cases where a specific action requires
a dedicated agent to run in response to it.
In the restaurant, Harry has set a policy that a dedicated
member of the kitchen checks every dish before it is served.
That staff member is the agent. The chef does not choose when to
follow this process: it is a kitchen policy, built into how the
restaurant operates. In an application, that means building the
hook into the agent harness itself.
Coding agents such as Claude Code and Codex use this pattern,
and Codex makes a good example to learn from. Codex is OpenAI's
coding agent. As part of its normal work it lets a model run
arbitrary operations on your computer. By default, a human
approves or rejects each action, but Codex also supports a mode
in which approvals are decided automatically. That mode, called
Guardian, is the hook pattern in practice.
Whenever the main agent requests an action that would need
approval, a second agent, the approver, starts in the
background. It runs with read-only tools, can see most of the
main agent's session transcript, and is given a long policy
document that describes how to decide whether an action is safe.
The approver uses its read-only tools to learn why the action is
being performed and what consequences it could have, then
returns a verdict that the action should be allowed or blocked.
A decision model like Jev could make the same call, and Codex is
experimenting with that for speed. Doing so removes the
approver's ability to gather context with read tools, and it
removes the written justification for each verdict. Whether that
tradeoff suits your own project depends on how you balance
speed, observability and output quality.
Open the floor for questions before continuing.
Codex Guardian, openai/codex at commit 12cca49c, read from
source on October 13, 2026.
The unstructured pattern we look at today is the agent swarm. A
swarm is a good option when you know what kinds of agents you
need, but the right way for them to accomplish a task varies a
lot from case to case. Each member of the swarm does what it is
best at and then hands the work to a suitable peer.
In the restaurant, picture a kitchen full of specialized chefs
where the order of work does not follow any single recipe. A
chef sees that a dish needs a piece of prep they are responsible
for, does that prep, and hands the result to another chef who
knows how to continue. Each chef attends only to their own part
and to what needs to happen next, instead of waiting for Lalima
or Harry to assign every task.
A real-world case is a system with several areas of
responsibility of equal importance. A monitoring agent detects
an anomaly and hands off to a separate agent that controls the
affected system, which may in turn hand the work to another
agent.
Strands Agents documentation, "Multi-agent patterns: when to use
a swarm,"
strandsagents.com/docs/user-guide/sdk/multi-agent/multi-agent-patterns,
retrieved October 18, 2026.
The third category is semi-structured topologies. We will not
spend long here, since these approaches are newer and more
advanced, but they are worth recognizing. Some topologies do not
fit neatly into the structured or unstructured categories.
One approach, popularized by projects such as the Prime Agent
coding harness, lets an orchestrator agent define specialized
subagents dynamically and use code to construct the topology
through which those subagents accomplish a task. In this
architecture and others like it, the design decisions center on
teaching the orchestrator to build the right topology on demand.
This is very powerful, but it can be costly and hard to monitor
and debug, so we stop at recognizing the pattern when you see it
in the wild.
Open the floor for questions before continuing.
Prime Intellect, Prime Agent: A Self-Improving RLM Harness,
arXiv:2608.23552. Zhang, Kraska and Khattab, Recursive Language
Models, arXiv:2512.24601.
Separately from the topology, we also choose how agents
communicate with each other. The main ways are shared workspaces
and message channels. Either one can be made to work with any of
the topologies we have covered.
OpenAI published this post about an incident during its internal
cybersecurity evaluations. Its models communicated through
unauthorized channels and exploited vulnerabilities in shared
infrastructure, then gained internet access and reached Hugging
Face's systems.
Anything agents share becomes a way for them to coordinate,
whether or not anyone designed it for that. Keep that in mind as
we look at shared workspaces.
OpenAI, "The Hugging Face incident and the road ahead,"
openai.com/index/hugging-face-incident-and-the-road-ahead,
retrieved October 22, 2026.
A shared workspace is what you get when every agent has the same
scratchpad. The animation shows three claim agents and one
shared table. One after another, each agent writes its verdict
into its own row, and every written row stays on the table. No
agent sends anything to another agent. Each one reads what is
already there and adds its part, which is why the last beat
shows all of them reading the finished table.
In the restaurant, this is a ticket rail that all of the chefs
manage together. When a chef has nothing immediate to do, they
read a ticket, do their part of the dish, mark it complete and
put it back. The next chef picks up where they left off, if the
next thing the ticket needs is their specialty.
Shared workspaces are most common in swarms, but a graph can use
one too. In the fact-checker, the claim agents in the graph
could each write their verdict into a shared table, instead of
the graph passing each verdict to the next step.
In contrast with shared workspaces, message channels let agents
find each other and send a message to one specific agent. The
animation shows three peer agents and a lead. One agent sends a
message straight to another agent along a direct channel and
waits, and that agent replies along the same channel. A
different agent then messages the lead the same way and gets a
reply, so you can see the channels are addressed and point to
point, not broadcast. The other agents keep working the whole
time. The message and the reply are the coordination, and they
go to one named agent rather than onto a shared record.
Message channels are also common in swarms. In a sense,
messaging is how an unstructured topology recovers some
structure, since an agent can ask a particular colleague for
exactly what it needs. Graphs use them too, for example when a
subagent pauses the graph to ask an orchestrator agent for more
information.
In the restaurant, the grill chef notices that a steak needs its
sauce and gets hold of the sauce chef directly to get it done.
Claude Code uses both of these patterns together in its agent
teams feature. Agent teams run a separate Claude Code session
for each agent, with one session as the team lead and the rest
as teammates.
The shared workspace is a task list. The lead adds tasks, and
each task is pending, in progress or completed. A task can
depend on other tasks, and it cannot be claimed until those are
complete. The lead can assign a task to a teammate, or a
teammate that finishes its work claims the next unassigned task
whose dependencies are done.
For message channels, each agent gets its own mailbox. Teammates
send messages directly to each other by name, and a teammate
notifies the lead when it completes its work.
Each of these is useful on its own, and each has a different
purpose. The task list carries communication at the level of the
team: the work the team as a whole needs to complete. The
mailboxes carry communication at the level of a single agent: a
question, or work that matters only to the agent receiving it.
Not every use case benefits from using both together like this.
Claude Code is a useful example because software development is
complex enough for the two patterns to complement each other.
If anyone asks how two teammates are kept from claiming the same
task at once: claiming a task uses file locking.
Open the floor for questions before continuing.
Claude Code documentation, "Orchestrate teams of Claude Code
sessions," code.claude.com/docs/en/agent-teams, sections "Assign
and claim tasks," "Architecture" and "Messages between agents,"
retrieved October 19, 2026. Agent teams are an experimental
feature, off by default.
The patterns you choose for your task matter. Coming back to the
newspaper fact-checker, we ran it with a single agent, a graph
and a swarm, on the same story.
The single agent hit a complexity ceiling: past a certain number
of claims, it missed some unsupported claims on every run.
This problem suits a graph well. It is a known process in which
the story's claims can be checked independently, and the graph
gives that checking to separate agents. With the graph, a larger
share of the unsupported claims were caught: 78 of 80, against
33 for the single agent.
Swarms are good at managing many specialists that decide the
process as they go and hand work to each other. Checking
independent claims never calls for that, so here the swarm added
overhead and reached its limit on handoffs before catching any
unsupported claims.
Task fit also affects cost. Each agent in the graph did far less
work than the single agent, so the graph used fewer tokens and
cost less overall. A topology that matches the task can be
cheaper than one agent doing everything, and one that does not
match can cost more and produce worse results.
Recorded runs, October 21, 2026, GPT-6 Luna through the workshop
broker, on the 160-claim story with 80 unsupported claims; demo
mode replays these runs. Token counts on the slide are input
plus output. Graph: 476 calls, six claims at a time, 293,877
input and 38,078 output tokens (331,955 total), about 25
minutes, $0.053, no true claims flagged. Single agent: 29 calls,
430,848 input and 17,652 output tokens (448,500 total), about
4.5 minutes, $0.063, 5 true claims flagged. Swarm: 12 handoffs,
40 of 160 claims given a verdict, 55,492 tokens, $0.006.
Back to the question we started with: when and how to split an
agent. We have spent most of the session on how, so to finish,
here is when.
Splitting an agent is worth considering when the agent drops
requirements because its task has become too complex, when it is
doing more work than fits in its context, or when it is doing so
much that you can no longer keep track of it.
Splitting comes with tradeoffs. Dividing work between agents can
increase costs when it results in much more work being done
overall, though better-scoped work also means the narrower
agents can run on cheaper models.
Splitting does not necessarily reduce the complexity of the
system as a whole. The work becomes much easier to control and
reason about, but the complexity moves out of a single agent and
into the system that contains the agents, which you still need
to design, monitor and debug.
As you work on your own projects, look for a place where an
agent is doing too much: dropping requirements, running out of
context, or becoming hard to follow. Think about which topology
would fit that work, and how its agents would communicate.
Experiment with different patterns and see what works and what
does not.
That is everything for today. As a reminder, the publishing
deadline for demos is October 27. Adi takes it from here.
