Multi-agent patterns
Build teams of agents from two-party threads, and what is built and what is not.
AWP’s threads have exactly two sides: one asker, one doer. That is deliberate (see why). Any size of team can still be built from those reliable pairs.
Patterns that work today
Coordinator
One agent opens a connection to each worker and one thread per unit of work.
awp send worker-1 --subject "Port package auth" "..."
awp send worker-2 --subject "Port package billing" "..."
awp send worker-3 --subject "Port package search" "..."
awp threads --openThe coordinator waits on each thread, answers questions, and merges results. Every thread has a clear owner and state.
Hierarchy
A worker can itself delegate. Each supervisor answers for its subtree. This works today. awp web shows the threads, but not the tree of who delegated what.
Pipeline
Each agent’s output feeds the next: spec, then code, then test, then review. Each handoff is a thread. The agent in the middle is the doer on one thread and the asker on the next.
Ensemble
Send the same question to several agents, ideally on different models, then compare, vote or have a judge pick. This is fan-out threads plus a merge step, run by the coordinator.
Debate
One agent proposes, another attacks. Two threads with assigned roles, and the coordinator (or a third agent) decides. A diff review between two agents is a light version.
Observer
Watch without taking part. This is built: presence, awp web and conversation sharing.
Introductions
A coordinator can connect two workers directly, so they talk without relaying through it:
awp introduce worker-1 worker-2worker-1 gets worker-2’s key and address, and can then message it by name. The coordinator must be connected to worker-1, or pass --thread to queue the introduction.
To give worker-1 capabilities on worker-2, list them: awp introduce worker-1 worker-2 fs:read. worker-2 honors them only if it granted the coordinator introduce. See Permissions.
Models of collaboration
Issue #17 surveys the models of agent collaboration and how each could map onto AWP. Where each stands today:
| # | Model | What it is | Good for | In AWP today |
|---|---|---|---|---|
| 1 | Asker and doer | One agent asks, one does, with clear states | Delegation | Built: threads |
| 2 | Publish and subscribe | Post to a topic; anyone subscribed reads it | Sharing context, announcements, status | Not built |
| 3 | Work queue | Tasks posted to a queue; an agent claims one with a lease | Spreading similar work over a pool | Not built |
| 4 | Market | An asker announces a task; agents bid; the asker awards it | Matching work to the right agent or model | Not built |
| 5 | Blackboard | Specialists watch a shared workspace and contribute | Open-ended research and debugging | Not built |
| 6 | Pipeline | Each agent’s output feeds the next | Repeatable multi-step processes | A pattern: chained threads |
| 7 | Hierarchy | Doers delegate further; supervisors answer for subtrees | Large, decomposable projects | A pattern; the delegation tree is not shown |
| 8 | Ensemble | Several agents answer independently; answers are compared | High-stakes answers | A pattern: fan-out threads plus a merge step |
| 9 | Debate | One proposes, another attacks | Design and security review | A pattern: two threads with assigned roles |
| 10 | Pairing | Two agents work on one thing in real time | Tight collaboration | Not built; needs a streaming channel |
| 11 | Observer | Watch without taking part | Oversight, debugging | Built: presence, awp web, sharing |
What is built and what is not
- Built: two-party threads, introductions, presence,
awp weband conversation sharing. Every pattern above marked “a pattern” runs on these today, driven by the agents. - Not built: multi-party rooms, topics, and any shared board. There is no
post,get,replyorsubscribecommand. Every message goes to one named peer.
Proposals for a shared board, a work queue and a market are discussed on the Roadmap.