On Agent Teams as State MachinesMulti-Agent Teams Are Not Group Chats · They Are State Machines

Once, I wanted several models to work together on a big job. To save myself some trouble, I simply launched a few agents in parallel in the background and let each run on its own. At the time, I thought this was no different from “putting a team together.” They were doing the work either way. What happened was that every agent did part of it, but none knew how far the others had got. After the task was wrapped up, I checked the processes and found those underlying claude processes still sitting there, like extras who had never been dismissed. No one owned the task. No one knew the overall state. I had to check them by hand, one at a time, to find out which were zombies and which I should leave alone.

After that, one thing became clear to me: treating “launching a few agents in parallel” as “putting a team together” was a mistake. It is more like putting a group of people in a chat and leaving them to shout to one another. It sounds lively, but it soon becomes a context swamp. Every agent knows a little and misses a little; everyone can speak, but there is no clearly defined state.

The conclusion I eventually came to was this: a multi-agent team is not a chat system. It is a state machine.

Roles Define Capability Boundaries, Not Personalities

Claude, Codex, and any local LLM I might connect later are more than just “three smart people.” They have different tools, different amounts of room for context, and different strengths and weaknesses.

Claude is suited to large jobs that can run in parallel: complex planning, broad research, tasks that need several copies of itself making progress at once. Codex is suited to taking a detached view and finding faults, actually running code locally to verify it, and detailed work that calls for careful steps through both the terminal and the browser. A local LLM will probably be suited to frequent, low-risk tasks where a mistake would not be disastrous: organizing materials, updating documentation, small fixes within a single file, and preliminary screening offline.

This is not about giving them personality labels. It is about drawing boundaries around their capabilities. Once those boundaries are clear, tasks can be routed to the right place. When they blur, everyone tries to do everything. And the worst problem for a team is not that no one knows how to do the work, but that everyone thinks they are doing the right part.

State Must Be Written Back into the World

Collaboration through group chat has a fatal flaw: the results stay in the conversation.

One agent says, “I verified it.” Another says, “I have taken over.” A third says, “There is a risk here.” If these statements exist only in the chat history, there is almost no way to recover them in the next session. Close the conversation window, and those “facts” disappear with it. That accounts for about half of what went wrong in the opening story: who had done what was all in their separate heads, never recorded in a shared place.

Collaboration through a state machine has one firm requirement: every critical piece of state must be written back into the world, rather than left as something someone said:

Who owns the task now → Record it in shared state, rather than leaving one agent to remember it
Completed work        → Put it into code and version history
What must be handed off → Write a standalone handoff document
Pitfalls encountered  → Record them in an incident and lessons log
User preferences      → Put them in a shared area everyone can read
An individual agent’s habits → Keep them in its private records; do not let them spill into everyone else’s

Once this is done, the conversation is no longer the source of truth. Files and version history are. The chat window is just a console, and there is no reason to mind closing it, because the important things are elsewhere.

Divide the Work into Stages Before Deciding Who Does It

One of the most useful things I have learned from working with Claude and Codex is this: divide the work by “what stage are we at?” rather than “who is stronger?”

A big job can be broken into stages: taking it on and clarifying what needs to be done, opening up the research, drawing up a plan, arguing against that plan yourself, implementing it, asking someone to review it with a detached eye, deploying it, and finally recording the lessons. Each stage calls for different abilities. Research needs breadth and parallel work; planning needs organization and reasoning through what follows; self-critique needs a willingness to be hard on your own work; implementation needs patience and care not to break the piece you are working on; a detached review needs an independent perspective that has not been drawn into the earlier line of thinking; deployment needs discipline; recording lessons means turning specific events into rules that can be used next time.

There was one job whose workload was clearly more than a single session could hold. I did not try to push through. That would have meant running out of context in the second half and rushing the finish. I divided it into stages: finish the research and plan in one session, record the results, and write a handoff; bring in an independent perspective to check whether that work was right and whether it had gone off course, but only to check, not to redo it; then open a new session, carrying the earlier outputs and the review findings forward into implementation; finally, have that independent reviewer check the complete result once more.

The key is that this is not “I cannot keep going, so I will dump it on someone else to finish.” The main implementer stays the same from beginning to end. The role in between is responsible only for review and verification. Changing stages does not mean changing who carries the work. It means moving the work to the right node for that stage. Once I divided it this way, collaboration among agents suddenly became more stable, because no one was arguing over “whose job is this?” Everyone was moving into a clearly defined state.

A Handoff Is a State Transition Function

Following this line of thought, a handoff becomes more than a document saying “I am done; you carry on.” It is a state transition function: it compresses the large mass of context in one agent’s head into external state that another agent can pick up and act on. That includes the background, what is done, what remains, where things are stuck, where the evidence is, how to reconstruct the working environment, and what to type first.

A poor handoff reads like a letter: “I am more or less done. Take it from here.” Whoever receives it still has to sort through the earlier work all over again, which makes the handoff pointless. A good handoff is like a save point that can be replayed: “Start from this version and run these commands first. If the result is A, take this path. If it is B, stop before doing anything else.”

I eventually settled on a few mandatory fields for a handoff. If even one is missing, it does not count: why the work is being handed off; how far it has got, with evidence that can be checked, not “more or less”; what remains, down to specific files and locations; what is blocking progress; the commands to reconstruct the working environment; and what to type first when taking over. There is also a rule about what not to do: whoever takes over must not repeat research and planning that have already been completed. That wastes work we have already paid for.

This is the fundamental difference between a state machine and a group chat. Group chat depends on “you need to understand what I just said.” A state machine depends on “you can resume from the save point even if you were not there.”

Do Not Let Agents Summon One Another

A multi-agent system has another hidden risk: agents calling one another in.

If any agent can casually pull another one in, tasks soon multiply. A asks B to take a look, B asks C to fill something in, and C turns back to A for another check. It looks very busy, but the state never settles. Responsibility spreads endlessly among the agents, and in the end no one is accountable for the result.

So I would rather have state transitions triggered by a person or by an explicit protocol. Who can change stages, who can change “who owns the task,” who can add an entry to the incident log, and who can finally mark something as “verified” should all be fixed rules, not an agent casually saying, “Come over here for a moment.” Agents can work together, but they cannot keep assigning work to one another without limit.

What Is Missing Is a Dashboard, Not More Context

When collaboration among agents goes wrong, the explanation afterward is usually “not enough context.” I think that is only half right.

Context is limited, of course. But what is really missing is a dashboard: who owns the task now? What stage has it reached? Which pieces of evidence have been confirmed? Which findings remain unresolved? Which files have been changed in this round? Which memories are shared, and which can only be read, not written to?

If these questions can only be answered from someone’s memory, even a larger context window will become a mess. The problem is not capacity; it is the lack of one place where the whole picture is visible at a glance. Conversely, once all of this is recorded as explicit state, it can be recovered even with a smaller context window.

This is also how I think about connecting a local LLM in the future: do not start by trying to make it “as smart as Claude.” First, bring it into the same state machine. It must be able to read “who owns the task,” read the handoff, write its own results back, and respect the boundaries around memories it must not touch. If it can do those things, it can join the team and work, even if it is not that smart.

A Team Is a Set of Verifiable Transitions

The maturity of an AI team is not measured by how many models it contains or how powerful each one is. It is measured by whether a task can move cleanly from one state to the next, with every transition verifiable, recoverable, and traceable to whoever made it.

This is what I keep seeing in the records of Claude and Codex working together: real collaboration comes from clearer boundaries, not livelier conversations. Once the boundaries are clear, people no longer have to carry all the context in their heads. People make architectural judgments, agents carry out the work within their own bounds, and the state machine saves the world’s state.

Back to that first occasion. In the end, I checked those agents running in parallel in the background one by one, and shut them down one by one, by hand. It was not that they were not smart enough. They had never entered the same state machine in the first place. No one owned the task, and no one knew whether it was time to leave. A team has never been about one more model. It is about losing a little less along the way.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:43–17:46 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 491,424 tokens (449,408 of them from cache) and wrote 9,088 (2,439 of them reasoning).