Turn-Based Collaboration
Most AI agent frameworks solve collaboration the same way: a central orchestrator delegates tasks to sub-agents, collects their outputs, and declares the work done. It is fast. It is scalable. And it produces exactly the kind of shallow, stitched-together output you would expect from workers who never see each other’s work.
Turn-Based Collaboration (TBC) is a different model. One agent. Multiple personas. Sequential turns. A finite state machine governing who acts, when, and what triggers the next transition. No orchestrator. No hierarchy. Every persona operates at the same level of agency, reading the same shared state, making real judgments about direction and quality.
The result is slower. It costs more tokens. And it produces work that holds up under scrutiny, because every contributor had full context and real authority to push back.
How It Works
TBC runs a single AI agent through a sequence of personas, each with a defined role, scope, and set of domain files. A Writer drafts. An Editor reviews. A Publisher finalizes. A Researcher gathers supporting material and seeds future work. Each persona acts one turn at a time, reads the full shared state, does its work, and writes its output back into that state for the next persona to evaluate.
The workflow is governed by a finite state machine. States define what kind of work happens (researching, drafting, reviewing, publishing). Transitions define when the work moves forward. Triggers are conditions evaluated against the actual state of the files, not declarations by a privileged controller. A draft does not advance to publishing because someone says it’s ready. It advances because the Editor has marked it approved with no outstanding feedback.
This is not a pipeline. Pipelines move forward. TBC can move backward. If the Editor finds problems, the draft returns to the Writer. If the Publisher flags issues after editorial approval, the work goes back to review. The state machine enforces this structurally, not as an exception but as a designed capability.
Why Not Orchestrators?
The orchestrator pattern is the default in AI tooling for good reason. It is fast, parallelizable, and simple to reason about. A controller breaks a task into subtasks, hands each to a specialized agent, and assembles the results.
The problem is what gets lost. Sub-agents are typically stateless, scoped to narrow tasks, and unaware of each other’s work. The orchestrator sees everything, but the workers see only their slice. When the orchestrator declares “done,” that judgment lives in one place. No other agent has the context to disagree.
TBC inverts this. Every persona can observe the full shared state. Every persona can judge direction against its own criteria. Every persona can act on that judgment and persist it for others to see. The Editor does not just receive a draft and check boxes. The Editor reads the goal, the research notes, the prior feedback, and the draft itself, then evaluates whether the work meets the standard. If it doesn’t, the Editor says so, and the state machine routes the work back.
This is peer-level agency. “Done” is not declared by one agent. It emerges when all personas have signed off through the transition triggers.
Structural OOO and CBC
If you have followed the Outcomes Over Optics framework, TBC will look familiar. OOO demands that results survive scrutiny, not just pass a status check. In TBC, the reviewing state enforces this structurally: Editor and Writer alternate turns in round-robin until the Editor approves. No rubber-stamping. No unilateral sign-off. Consensus-driven quality where “done” means the work actually passed real evaluation.
Collaborate by Contract shows up in the shared state itself. The goal file defines the objective, deliverables, and current status. Each persona’s instructions define its scope and responsibilities. The transition triggers define completion criteria. No work begins without a clear agreement. Every handoff is documented in the turn log. Accountability is explicit and auditable, exactly the way CBC demands.
The Trade-Off
TBC isn’t free. Sequential turns are slower than parallel execution. Full context per turn costs more tokens than narrow, scoped sub-agent calls. A four-persona pipeline producing a single article will take more time and money than an orchestrator that delegates research, writing, and editing simultaneously.
The payoff is depth. Full context sharing means each persona genuinely evaluates and course-corrects, not just executes a narrow task in isolation. The orchestrator pattern optimizes for speed. TBC optimizes for the quality of collaboration. Both are valid. The question is what you are optimizing for.
