Multi-Agent Collaboration Patterns: Chat, Issue-Driven, SOP, and Hybrid Workflows

Once you start running several AI agents at the same time, one question shows up quickly: how should they actually collaborate?

Spinning up more agents is easy. The hard part is deciding who receives the request, who breaks it down, who executes, who reviews, where state lives, how permissions are controlled, and how the system recovers when something goes wrong.

Across my work with Slock/Raft , Multica , and an enterprise SOP-agent system, the biggest difference has not been the model. It has been the organizational pattern around the model.

I find it useful to split the patterns into three broad types:

• Chatroom pattern: high freedom, good for ad-hoc work and exploration.
• Office pattern: tasks live in issues, which fits project-oriented collaboration.
• SOP pattern: lower freedom, better for process-driven or high-risk work.

Real systems often combine all three.

Why multi-agent systems become messy

A single agent is easy to reason about. You give it a task, it plans, executes, and adjusts.

Put several agents together and the failure modes become very concrete:

• Agent A changes the code, Agent B does not know and changes it again.
• Agent C commits before you have approved the plan.
• Agent D calls a tool it should not be using.
• Agent E forgets the goal from a few turns earlier.
• Agent F does the right thing at the wrong stage.

These are often not model-capability problems. They are problems of unmanaged freedom, permissions, and state.

More agent freedom makes more complex work possible, but the coordination cost rises with that freedom. A collaboration pattern is really a way to decide how much freedom the agents get and how much structure the surrounding system provides for each type of work.

Chatroom pattern: good for ad-hoc work

The chatroom pattern feels like assigning work in a group chat. You mention different agents in one channel, they execute, and their results come back into the conversation. You can interrupt, redirect, or hand the work to someone else at any time.

It works well for:

• exploratory tasks where the end state is still unclear;
• one-off requests that do not need durable project state;
• fast iteration where a human is watching in real time;
• several agents researching, drafting, or inspecting logs in parallel.

The advantage is speed. The drawbacks are just as obvious: state gets scattered across the conversation, token usage can grow quickly, and retrospective review becomes harder.

If you use this pattern, I would at least keep three rules:

1. Separate supervision from execution. Use a stronger model to understand the request and split the work. Execution agents should receive narrower subtasks.
2. Review before execution. For high-risk changes, require a plan first and do not allow file changes until that plan is accepted.
3. Control the pace. Stop at the end of each stage and wait for confirmation instead of letting agents continue until the work is too large to take back over.

Slock, now renamed to Raft, fits this pattern well. Its strength is immediate dispatch and live coordination.

Office pattern: better for project work

The office pattern moves the durable part of collaboration out of chat and into issues.

Each task gets background, a goal, boundaries, an owner, a deliverable, and a way to verify completion.

This pattern works well when:

• the project has a concrete deliverable;
• several agents or humans work asynchronously;
• you need to know who did what and how far the task has progressed;
• review and retrospective analysis matter.

The issue is the important part.

A useful issue should at least specify:

• Background: why the task exists and where the relevant project or files are.
• Goal: what should be true when the task is complete.
• Boundaries: what must not change and whether installing dependencies is allowed.
• Deliverable: code, a report, screenshots, an HTML page, or perhaps another issue.
• Acceptance: what command to run, what page to inspect, and who performs the review.

Roles can then follow the task flow:

• Planning agent: turns an ambiguous request into a plan and executable issues.
• Execution agent: works against the issue.
• Review agent: reads the diff, runs tests, and checks the delivery report.
• Coordinator agent: chooses the right worker for each type of task.

Discussion can still happen in chat, but commitments should live in issues. The next agent should rely on the issue, not on something someone casually said five messages earlier.

Multica is much closer to this pattern. It turns agent work from “call someone in for a task” into a trackable workflow.

SOP pattern: better for process-driven business workflows

The SOP pattern fits customer reception, order handling, after-sales follow-up, and complaint routing.

These tasks are not open-ended research. The main difficulty is not getting enough information; it is keeping the process from drifting.

A user enters and the system needs to identify the request. Once the user shows interest, it may need to confirm key details. Near a transaction, it may need to handle objections. When the user becomes dissatisfied, the system should switch to de-escalation or human escalation.

A completely free agent can look intelligent in a demo but behave poorly in production: advancing too early, repeating questions, calling the wrong tool at the wrong stage, or continuing a sales flow while the user is already unhappy.

The SOP pattern instead gives the agent a controlled environment: what stage it is in, what the current objective is, which tools are allowed, what permits a transition, and when it must stop.

A few design rules matter most:

1. Externalize state. Do not make the LLM remember the business process. Load the current state from a database and give it to the agent.
2. Use one agent with SOP routing where possible. The same agent can receive different prompts, tools, and goals at different stages.
3. Use tool allowlists. If a tool should not be used at the current stage, do not expose it to the model.
4. Let rules decide whether; let the model decide how to say it. Escalation, outreach, and stage transitions should be governed by rules. The model generates the wording.
5. Keep a complete trace. State, intent, tool calls, tool results, output, and quality checks should all be inspectable.

This kind of workflow does not necessarily need multiple agents. The real-time path should be stable; background analysis can be more complex.

Hybrid patterns are more common in practice

Real systems rarely use only one pattern.

A more realistic setup looks like this:

• Conversation layer: chatroom pattern. Generate ideas, discuss direction, dispatch short-lived work.
• Task layer: office pattern. Turn committed work into issues and assign execution and review.
• Execution layer: SOP pattern. Constrain high-risk, process-driven, or user-visible actions with state and permissions.

The same system might run open-ended research in parallel with several agents, track product development through issues, and route live customer conversations through an SOP.

Three questions are usually enough to choose the pattern:

• How open-ended is the task? Use more freedom when the path is uncertain and less freedom when the path is stable.
• How risky is the task? Read-only work can be looser. Writes should be tighter. High-risk actions should require approval.
• Does the work need durable tracking? If review and acceptance matter, do not leave the task only in chat.

Four non-negotiables

Whatever collaboration pattern you choose, the underlying requirements stay similar.

Controllable. Agents need clear boundaries: what they may do, what they may not do, and when they must stop. High-risk tools should not rely on prompt instructions alone.

Traceable. Each run should preserve state, intent, tool calls, tool results, state transitions, and final output.

Recoverable. Agents will make mistakes. The surrounding system needs to detect abnormal behavior, stop propagation, and return to a safe state.

Iterative. Do not tune agent behavior only by intuition. Keep evaluations, versions, staged rollouts, and rollback paths.

These controls are less exciting than “autonomous multi-agent collaboration,” but they are what determine whether a system can run reliably over time.

How I choose a pattern

A rough decision rule looks like this:

Open-ended research, broad information coverage, parallel exploration
→ Chatroom pattern + multiple agents

Project development, concrete deliverables, asynchronous collaboration
→ Office pattern + issue-driven work

Process-driven business workflow, high risk, long-lived state
→ SOP pattern + state machine

Different stages need different behavior
→ Layered hybrid

A few common mistakes are worth avoiding:

• More agents are not automatically better than one. If there is no real parallelism or role separation, a single agent is often more reliable.
• More freedom does not mean more intelligence. In enterprise mainline workflows, “does not do the wrong thing” often matters more.
• A prompt is not a replacement for permissions, state, and workflow control.
• The collaboration pattern will evolve. An early system may start as a chatroom, later become issue-driven, and only need formal SOP controls once the workflow matures.

Multi-agent collaboration is not solved by putting several models in one system.

The real problem is how they divide work, hand work off, avoid rereading and burning the same context, stay within permissions, and return control to a human when something goes wrong.

Choosing the model matters. Choosing the collaboration pattern matters more.

Related reading:

• Slock/Raft guide : the chatroom pattern in practice
• Multica guide : the office pattern in practice
• Enterprise SOP agent architecture : the SOP pattern in practice