Designing Multi-Role AI Collaboration Workflows

Most AI collaboration advice treats every conversation as a fresh start. This one treats the AI as a staffed organization.

The default posture when working with an LLM on a complex project is a single ongoing chat — one context, one role, one accumulating conversation that handles research, implementation, review, and ideation interchangeably. This works well for simple tasks. For long-lived projects, it quietly produces a specific class of failure: the same context that generated a finding also evaluates it; the same instance that wrote the code also decides whether to commit it; the same conversation that explored a half-formed idea also treats it as resolved.

This is the closed-loop problem applied to workflow design. When one instance of an AI does all the work — generating outputs, reviewing them, and authorizing them — there is no external pressure on any of those judgments. The validator is not independent of the work it is validating. Elegant outputs look valid to the same context that produced them, because the context that produced them has already decided they are adequate.

The architecture described here addresses this problem by decomposing AI-assisted work into four distinct roles, each with its own mandate, file load order, conduct rules, output responsibilities, and a defined list of things it explicitly cannot do. The roles do not share a context. Each one begins fresh, loaded with only what is appropriate for its function. The human operator is always in the handoff path. And a single meta layer — separate from all research and implementation work — is the only role authorized to commit anything to the project files.

The Four Roles

The architecture is organized around functional separation, not convenience. Each role exists because there is a category of work that produces better outputs — and better governance — when it is done by a context with no knowledge of the other categories of work happening in parallel.

Three of the four roles have generic, descriptive names: Session Chat, Implementation Chat, Exploration Chat. The fourth has a proper name — Ankyra — and the asymmetry is deliberate. Ἄγκυρα is the Greek word for anchor. It is the only role whose function is not defined by what it produces but by what it holds in place: the single fixed point in the architecture that everything else is tethered to. Session chats generate findings. Implementation chats build. Exploration chats speculate. Ankyra does none of those things. Its job is to stay still while everything else moves — to be the context that has not participated in any output it is asked to evaluate, and the only gate through which any output can pass into the permanent project record. Naming it distinguishes it from the others not as a matter of style but as a reminder of its structural role: the anchor does not drift.

The cannot lists are as important as the role definitions. Role separation only functions as a governance mechanism if each context genuinely cannot perform the other roles' work — not merely that it is instructed not to. The file load orders enforce this structurally: an implementation chat loads the implementation log and learning notes, not the research log. It cannot inadvertently do research it has not been loaded to do.

The Authorization Gate

The most important design decision in the architecture is the placement of Ankyra as the single commit-authorized role. This is not an administrative convenience. It is the mechanism that breaks closed-loop validation.

When a session chat produces a finding, that finding was generated by a context that is, by definition, already invested in the question it was investigating. That context's evaluation of its own output has inherent limits — not because of bad faith, but because the framing that produced the finding is still present in the context that would evaluate it. This is the same closed-loop problem that makes self-review unreliable in any knowledge work.

Ankyra loads fresh. It has no memory of the session chat that produced the output. It encounters the candidate finding the way a careful external reviewer would — as text to evaluate against the project's established standards, not as the conclusion of a reasoning process it participated in. The session chat cannot predict whether Ankyra will approve the finding, reframe it, flag it as requiring further verification, or return it as insufficiently supported. That unpredictability is the point.

Handoff Discipline

The architecture defines three output pathways, each with different authorization requirements and different destinations. The human operator appears in every pathway — there is no route by which an output moves from one layer to another without explicit human awareness and action.

The NOTE-READY pathway deserves particular attention because it deliberately bypasses Ankyra. Learning notes capture explanations and working understanding that the developer generates during implementation — how a pattern works, why an approach was chosen, what a failure revealed. These are personal reference captures, not governance-sensitive claims. Routing them through Ankyra would add bureaucratic weight without adding integrity value. The architecture distinguishes what needs governance from what merely needs recording.

The HANDOFF-READY pathway from the exploration layer is the most structurally interesting because it is the most constrained. An exploration chat is explicitly forbidden from deciding that a half-formed idea has become a finding. It can only flag that a threshold has been crossed — that a conversation has organically developed into something that bears on a named open question, would change how a resolved question is understood, or warrants a new question that does not yet exist. The human decides whether to elevate. The exploration chat cannot push toward that decision.

The Scope Confirmation Requirement

One failure mode that the role architecture alone does not prevent is scope drift within a session — not the project drifting, but a specific task being executed against the wrong scope because the scope was assumed rather than confirmed. This is subtle and surprisingly common. A context with extensive project knowledge can almost always derive a plausible scope for any given task. Derivability is not confirmation.

This rule was not designed in advance. It was added after two confirmed failures in which the correct scope was entirely derivable from context — and was still wrong. In the first instance, a literature review was scoped to a subsection of the project when the correct scope was the project hypothesis as a whole. In the second, an audit screening pass was run against the wrong research question. Both failures were invisible until their outputs were reviewed, because in both cases the derived scope produced coherent, well-formed outputs. Coherent outputs from the wrong scope look like correct outputs until they are checked against something external.

What This Architecture Prevents

The value of the architecture is most visible in the failure modes it structurally rules out — not just discourages, but makes mechanically difficult by design.

• ✕
  Closed-loop self-validation of research findings

  A session chat cannot authorize its own outputs. Ankyra's independent review — from a context with no memory of the session that generated the finding — provides pressure that the generating context cannot provide for itself.

  Addressed by: the authorization gate (Ankyra), which loads fresh for every review.
• ✕
  Research questions pursued inline during implementation

  An implementation chat encountering an interesting research question mid-build cannot investigate it — only surface it as a named thread with an explicit routing destination and trigger condition. Implementation context stays implementation context.

  Addressed by: the THREAD entry discipline and the implementation chat's explicit cannot list.
• ✕
  Unauthorized changes to project files

  No role except Ankyra generates commit blocks. No commit block executes without explicit human authorization. The project files cannot be modified through inertia, automation, or a session chat deciding its own output is ready.

  Addressed by: Ankyra as the single commit-authorized role, with explicit human authorization required per commit.
• ✕
  Exploration outputs silently promoted to findings

  The exploration chat has no commit pathway at all. An interesting idea developed in an exploration conversation cannot become a project commitment without passing through the human, then Ankyra, then an explicit authorization step. The path from "interesting" to "committed" is long by design.

  Addressed by: the HANDOFF-READY protocol, which flags emergence without elevating it autonomously.
• ✕
  Context contamination between research and implementation

  An implementation chat loaded with the implementation log and learning notes has no access to the research log's evolving findings. An open research question cannot silently influence implementation decisions made in a context that is not supposed to be doing research.

  Addressed by: role-specific file load orders that restrict what each context knows.

The Broader Principle

The architectural insight generalizes beyond research programs. Any long-lived project in which an LLM is doing iterative labor across multiple functional categories — investigation, construction, review, exploration — will produce better governance outcomes if those categories are handled by contexts with different mandates, different knowledge loads, and different authorization levels, rather than by a single do-everything context that accumulates all of them.

This is, in essence, the principle of separation of concerns applied to AI collaboration. Software architects do not give every component read-write access to every other component's state. They define interfaces, restrict access, and route changes through explicit handoff points. The same logic applies here — not because AI contexts are untrustworthy in the same way that untested code is, but because contexts without role constraints will do whatever the immediate task seems to require, and a research context doing implementation work, or an implementation context reviewing its own findings, or an exploration context committing its own speculations, produces the same class of failure in each case: outputs authorized by the context that generated them, evaluated against the standards of the task that produced them, without independent pressure from outside.

The four-role architecture does not solve every governance problem. It does not prevent a session chat from generating findings that are individually plausible but collectively incoherent. It does not prevent an implementation chat from making locally sensible decisions that accumulate into a poor architecture. These are problems that require the full governance framework — the defect register, the convergence layer, the Frozen Anchor — to address.

What the architecture does provide is a structural foundation on which that governance can actually operate: defined roles, explicit handoffs, an independent authorization gate, and a human operator who is always in the path between output and commitment. Without that foundation, the rest of the governance stack is applied to outputs that were already authorized by the contexts that produced them. With it, every output has passed through at least one context that had no stake in its production.