Multi-agent systems: contracts, orchestration and recovery

A multi-agent system should distribute work without obscuring responsibility. Naming a role “verifier” does not establish independence. Specify what evidence it receives, which checks it performs and what permits it to reject a result.

Anthropic’s engineering account describes delegated research. Why Do Multi-Agent LLM Systems Fail? studies design, coordination and verification failures. For security workflows, we propose explicit task contracts that make these boundaries observable.

Choose the necessary flexibility

A fixed workflow fits known sequences. A single agent can adapt retrieval without coordination overhead. Several agents may help when subtasks are genuinely separable or need distinct contexts.

Compare these options against the same objective, corpus and budget. Agents repeatedly copying the same material may not provide useful independence. Message volume cannot establish result quality.

Define a portable task contract

In a fictional advisory-qualification workflow, one role collects references, another compares versions and a third examines evidence. The orchestrator retains responsibility for scope and state transitions.

{
  "task": "qualification-17",
  "organisation": "alpha",
  "objective": "compare observed version and advisory",
  "inputs": ["inventory:8@3", "advisory:12@1"],
  "expected_result": "affected, unaffected or unknown",
  "required_evidence": ["version", "conditions", "source"],
  "action_budget": 6
}

This contract does not itself grant access. The execution environment must authorise source reads. A model-written organisation identifier must not switch customer workspaces.

Make task endings unambiguous

Define created, running, blocked, completed and rejected states, their transitions and required evidence. A blocked state preserves missing access instead of forcing an approximate conclusion.

Accepting “affected” should require compared versions and an applicable reference. Unsupported assertions should be rejectable with a useful explanation, allowing recovery without restarting the entire investigation.

Handle retries and concurrent writes

A timeout does not prove failure. If ticket creation succeeds but its response is lost, a blind retry may create a duplicate. Assign an idempotency key and retain an execution receipt that recovery can consult.

Shared memory creates another conflict: agents can write from different prior versions. An expected version or atomic operation makes this detectable. A later write should not silently overwrite an earlier change. These controls belong in the execution system; a prompt asking agents to avoid duplicates cannot replace them.

Evaluate the whole workflow

Retain decisions, tool calls, references and transitions needed for diagnosis with appropriate redaction. Useful traces need not disclose secrets or private internal reasoning.

Test incomplete messages, unavailable agents, contradictory evidence, exhausted budgets and recovery after an already completed external effect. Measure task success, unwanted effects, latency and correctly recognised blockers.

Read the cybersecurity-agent overview, versioned memory lifecycle and cyber-agent evaluation guide. The series index connects the architecture to its controls.