Frameworks · Working document
Multi-agent design patterns
How to build a multi-agent system that actually satisfies the Octopus Protocol's criteria. Five structural patterns — one per governance property that must survive automation.
How to build a multi-agent system that actually satisfies the Octopus Protocol's criteria. Five structural patterns — one per governance property that must survive automation.
The Octopus Protocol states what a governable multi-agent system must guarantee. These patterns describe how a system is structured to deliver each guarantee. They are architectural, not vendor-specific: any stack that implements the structure satisfies the corresponding principle.
Implements Principles 1 & 2: humans own goals; no orphan autonomy.
Goals flow one way. Every agent carries a named human owner (coral) assigned before deployment — a person, not a committee.
The structure enforces the ends/means boundary physically: the orchestrator can decompose and route work but has no channel through which to redefine an objective. The ownership registry is part of the deployment artifact — an agent without a registered owner does not deploy. When an output is later questioned, "who is answerable" is a lookup, not an investigation.
Implements Principle 3: assertions carry provenance.
The source link travels with the claim into the permanent record. A claim that arrives without one is rejected at the boundary, not flagged for later.
Provenance is enforced as a schema constraint, not a convention: the interface between agent and record refuses assertions without an authenticated source reference. This turns "the system should cite sources" from a policy hope into a structural property — the failure mode becomes a visible rejection rather than a confident, orphaned sentence.
Implements Principle 4: confidence is declared, not implied.
Uncertain outputs cannot disguise themselves as certain ones — the routing decision is made by the declared score against a threshold fixed before deployment.
The threshold lives in configuration signed off at deployment, so it cannot be quietly renegotiated when review queues grow. What the gate buys is honesty under load: pressure to move faster shows up as an explicit request to change a governed number, not as a silent drift in what gets waved through.
Implements Principle 5: the audit record is local, complete, producible on demand.
Every interaction writes to a record the organisation controls. Nothing about auditability depends on a supplier's continued cooperation.
The record is append-only, held in the organisation's own custody, and complete by construction because logging sits on the message path rather than beside it. When a regulator, a court, or a board asks what happened, production is an export — not a negotiation with a vendor.
Implements Principle 6: measure the baseline before you automate it.
No payback claim is admissible without the left-hand box. This is the pattern most often skipped — and the one our delivered programme found missing in every team.
Instrumentation precedes automation as a gate in the project lifecycle: an initiative cannot enter build until its process step has a measured baseline under a stated protocol. The same protocol is re-run after deployment, which is what makes "continue or stop" a decision about evidence rather than a debate about impressions.
These five patterns are the working core. They are published as they mature; pattern-level reference implementations and failure-mode catalogues are in development. The patterns are vendor-neutral: any architecture implementing the structures above satisfies the corresponding Octopus Protocol principle, whoever builds it.