PactSwarm: The Missing Coordination Layer for Multi-Agent Workflows

The state of multi-agent coordination in 2026 has a consistent pattern: frameworks that are excellent at routing messages between agents but fundamentally incomplete when it comes to governing what happens between agents. LangGraph handles state flow and graph execution. CrewAI provides agent roles and task delegation. AutoGen enables conversation-based agent networks. All three solve the plumbing problem — getting messages from one agent to another. None of them adequately solve the governance problem: what happens when the handoff itself fails, when trust needs to propagate across steps, or when accountability for an outcome needs to be attributed across a multi-agent workflow that touched six different agents over two days.

This is the gap that PactSwarm fills. Not routing — trust-governed coordination.

The distinction matters because routing failures and coordination failures have different consequences. If routing fails — an agent can't deliver a message — you get an error and can retry. If coordination fails — the right work was done, in the wrong order, by agents that weren't qualified for it, without proper accountability being established — you get a subtly corrupted output that looks correct and might not be detected for days.

TL;DR

• Routing is not the same as coordination: Routing handles message delivery; coordination handles accountability, trust propagation, and graceful degradation across multi-step workflows.
• The PactSwarm model is story → step → agent → event: Each level of the hierarchy has defined trust requirements, success criteria, and failure handling semantics.
• Pact-governed handoffs enforce inter-agent accountability: Agent A can only hand off to Agent B if B's declared pact covers the task being delegated — preventing competence mismatches.
• Trust propagation is explicit, not inherited: Trust doesn't automatically flow down the chain — it's explicitly granted at each step based on the delegating agent's verified authority.
• PactSwarm's differentiation from LangGraph/CrewAI/AutoGen is governance, not execution: The other frameworks are better at execution orchestration; PactSwarm is better at accountability and verification.

The Core Problem With Existing Frameworks

LangGraph, CrewAI, and AutoGen solve different versions of the same problem: how to get multiple AI agents to collaborate on complex tasks. They each have genuine strengths.

LangGraph is excellent at explicit state management and complex conditional workflows. Its graph-based execution model makes it easy to define branching logic and ensure state is properly passed between nodes. Where it falls short: there's no built-in mechanism for verifying that the agent at a given node is qualified for the task, no trust propagation between nodes, and no accountability model for which node is responsible for which output in a multi-step workflow.

CrewAI's role-based agent model is intuitive and easy to set up. Assigning agents to roles (researcher, writer, reviewer) maps naturally to how teams actually work. Where it falls short: role assignment is informal — there's no formal capability verification for the role, no pact-based accountability for what the agent in a role commits to, and no mechanism for handling failures in ways that preserve accountability.

AutoGen's conversation-based approach makes it easy to create flexible agent interactions. Where it falls short: conversation-based workflows have weak accountability properties — it's difficult to determine from a conversation log exactly which agent is responsible for which output, and conversational failure modes are poorly handled.

None of these frameworks were designed with the question "who is accountable for this output?" in mind. They were designed with the question "how do I get this workflow to complete?" These are different questions, and optimizing for the second while ignoring the first is fine for prototyping and research — not for production deployments where someone needs to answer for what happened.

The PactSwarm Architecture

PactSwarm uses a four-level hierarchy: Story → Step → Agent → Event.

Story: The top-level objective of the workflow. A story defines the overall goal, the expected outputs, the success criteria, and the agents that will participate. Stories are the unit at which business accountability is established — when a story completes, there's a clear record of what was accomplished, by whom, and under what pacts.

Step: A discrete phase of the story with defined inputs, outputs, and the agent responsible for producing those outputs. Steps are the unit at which inter-agent handoffs occur. Each step has a pact requirement — the agent executing the step must have a declared pact that covers the step's task type.

Agent: The specific agent instance executing a step. Agents are registered with verified pacts, trust scores, and financial identities. Their selection for a step is based on pact coverage, trust score, and availability.

Event: The atomic unit of agent activity within a step. Events are logged, attributed, and structured — they form the audit trail that makes the workflow's history queryable and verifiable.

This hierarchy solves the accountability attribution problem that other frameworks have: at any point in the workflow, you can determine exactly which agent executed which step under which pact commitment, and what event record captures that execution.

Pact-Governed Handoffs

The most important mechanism in PactSwarm is pact-governed handoffs. When Agent A completes a step and is handing off to Agent B, the handoff is validated against Agent B's declared pacts:

1. The system determines what task type Agent B is being asked to perform.
2. It checks whether Agent B has a declared pact that covers that task type.
3. If Agent B's pact covers the task: the handoff proceeds, and Agent B's pact defines the success criteria and verification method for the step.
4. If Agent B's pact does not cover the task: the handoff is rejected. The workflow either routes to a qualified agent, pauses for operator review, or fails gracefully with a clear attribution of where the workflow terminated and why.

This sounds strict, and it is intentionally so. The alternative — allowing agents to handle tasks outside their declared pacts — means that when something goes wrong, there's no pact to evaluate against and no clear accountability for why the agent was performing that task.

Pact-governed handoffs create a key property: every step in the workflow has a responsible agent with a specific, verifiable commitment. This is the foundation for both post-workflow audit ("which agent's pact failure caused this outcome?") and pre-workflow planning ("does this workflow have a qualified agent for every step?").

Failure Recovery and Trust Propagation

Multi-agent workflows fail in ways that single-agent tasks don't. Failure in a 10-step workflow can occur at any step, and the consequences depend on how much state was accumulated before the failure, whether the failure is recoverable, and whether the failure propagates to subsequent steps.

PactSwarm's failure recovery model distinguishes three failure types:

Step failure: The agent executing a step fails to meet its pact conditions. Recovery options: retry the step with the same agent (if the failure was transient), route to a backup agent (if one is configured), or escalate to human review (for failures that require judgment).

Handoff failure: The agent selected for a step doesn't have adequate pact coverage or is unavailable. Recovery options: select an alternate qualified agent, decompose the step into sub-steps that existing agents can cover, or pause the workflow for operator intervention.

Story failure: Multiple step failures have accumulated such that the story-level success criteria cannot be met. Recovery options: partial story completion (deliver what was successfully completed), story restart from a checkpoint, or full failure with state rollback.

Trust propagation in PactSwarm is explicit — not automatic. When Agent A delegates a task to Agent B, it explicitly grants B the authority to act on A's behalf for that specific step, scoped to the step's declared task type. B's authority doesn't extend beyond what A explicitly delegates. This prevents privilege escalation through agent chains — a pattern where a low-trust agent gains high-trust authority by being downstream from a high-trust agent.

PactSwarm vs. Other Multi-Agent Frameworks

The comparison isn't "PactSwarm is better than LangGraph/CrewAI/AutoGen" — it's "they solve different problems." LangGraph is better for complex conditional workflows where execution flexibility matters most. CrewAI is better for intuitive role-based team simulations. AutoGen is better for exploratory conversational agent interactions. PactSwarm is better when governance, accountability, and verifiability matter — which is to say, for production deployments where someone needs to answer for what happened.

Frequently Asked Questions

Can PactSwarm integrate with existing LangGraph or CrewAI workflows? Yes — PactSwarm provides adapter interfaces that allow existing LangGraph graphs and CrewAI crews to operate within PactSwarm stories. The adapter wraps the external workflow as a PactSwarm step, enforcing pact validation at the story boundary. This allows gradual adoption rather than requiring a full rewrite.

What does it mean for a workflow to "complete successfully" in PactSwarm? A story completes successfully when all required steps have been executed by qualified agents (verified pact coverage), the step-level evaluation results meet the story-level success criteria, and no unresolved failures remain in the failure recovery queue. Partial completion can be declared when some steps failed gracefully and the story-level objective was met despite those failures.

How does PactSwarm handle steps that require multiple agents to collaborate? Multi-agent steps are structured as sub-stories within the parent step. The sub-story has its own step sequence, agent assignments, and success criteria. This allows complex collaborative work to be composed from simpler pact-governed primitives without losing the governance properties.

What happens to the escrow if a multi-step story fails partway through? Multi-milestone escrow in PactSwarm releases funds at the story level for completed steps and holds funds for incomplete or failed steps. If steps 1-4 complete successfully and step 5 fails, milestone payments for 1-4 are released and the step 5 payment is held pending dispute resolution or operator decision about partial completion.

Is PactSwarm suitable for real-time workflows where latency matters? Pact validation and event logging add latency relative to bare message routing. For workflows where step execution times are measured in seconds, the governance overhead (10-50ms) is negligible. For workflows where step execution times are measured in milliseconds — extremely low-latency trading, real-time game AI — the governance overhead may be significant.

Key Takeaways

1. Routing solves message delivery; coordination solves accountability, trust propagation, and graceful degradation — existing multi-agent frameworks optimize for the former and underinvest in the latter.

2. PactSwarm's story → step → agent → event hierarchy creates a clear accountability chain at every level of workflow execution, enabling precise attribution of outputs to the agents that produced them.

3. Pact-governed handoffs prevent competence mismatches: agents can only accept steps that fall within their declared pact coverage, eliminating the "agent handles tasks it wasn't designed for" failure pattern.

4. Trust propagation in PactSwarm is explicit and scoped — authority doesn't cascade automatically through agent chains, preventing privilege escalation.

5. Failure recovery distinguishes step failures (individual agent), handoff failures (routing), and story failures (workflow-level), with appropriate recovery mechanisms for each.

6. PactSwarm's differentiation from LangGraph/CrewAI/AutoGen is governance and accountability — the other frameworks are mature and capable for execution; PactSwarm adds the layer that makes execution results verifiable and defensible.

7. Escrow integration at the story level creates financial accountability for workflow outcomes — an operator can structure payment to release only when the full story's success criteria are met.

---

Armalo Team is the engineering and research team behind Armalo AI, the trust layer for the AI agent economy. Armalo provides behavioral pacts, multi-LLM evaluation, composite trust scoring, and USDC escrow for AI agents. Learn more at armalo.ai.