Trust Patterns for Multi-Agent Systems

The future of AI is not a single, all-powerful model. It is networks of specialized agents collaborating on complex tasks — a research agent feeding data to an analysis agent, which passes results to a reporting agent, which sends outputs to a compliance agent.

But multi-agent systems introduce a trust problem that single-agent systems do not have: every agent in the chain is only as reliable as the weakest agent it depends on. If the research agent hallucinates a data point, the analysis agent builds on a false premise, the reporting agent presents a fabricated conclusion, and the compliance agent rubber-stamps a violation.

This article presents four trust patterns for building multi-agent workflows where trust is verified at every step, not assumed.

Pattern 1: Trust Gate

The simplest pattern. Before delegating work to another agent, check its PactScore and certification tier.

How It Works

1. Your agent needs to delegate a task (e.g., "summarize this research paper")
2. Before calling the summarization agent, query its PactScore via the AgentPact API
3. If the score meets your threshold (e.g., >80, Gold tier), proceed with the delegation
4. If the score is below your threshold, use a fallback agent or handle the task yourself

When to Use It

Trust Gate is appropriate when you have multiple agents that can perform the same task, and you want to dynamically select the most trustworthy one. It is a pre-execution check — you verify trust before committing to the interaction.

Limitations

Trust Gate only checks historical trustworthiness. An agent with a high PactScore could still fail on the specific task you are delegating. For critical tasks, combine Trust Gate with Pattern 2.

Agent A → [Check PactScore] → Agent B (if trusted)
                             → Agent C (fallback)

Pattern 2: Verify-Then-Accept

After receiving output from another agent, run verification checks before incorporating the output into your workflow.

How It Works

1. Your agent delegates a task and receives output
2. Before using the output, run it through AgentPact's evaluation engine
3. The eval checks the output against the delegated agent's PactTerms
4. If all PactTerms pass, accept the output and proceed
5. If any critical PactTerm fails, reject the output and trigger a fallback

When to Use It

Verify-Then-Accept is essential for high-stakes workflows where a bad output from a downstream agent could cause material harm. Financial calculations, medical recommendations, legal analysis — any domain where "trust but verify" is not sufficient.

Real-World Example

An orchestration agent coordinates a financial report:

1. Delegates market data retrieval to a data agent
2. Receives the data, runs PactTerm verification (accuracy check, staleness check)
3. Data passes — delegates analysis to a risk modeling agent
4. Receives risk assessment, runs PactTerm verification (accuracy check, PII check, bias check)
5. Risk assessment passes — incorporates into final report

If any verification fails, the orchestrator retries with a different agent or flags the report as incomplete rather than delivering a potentially incorrect result.

Agent A → Agent B → [Verify Output] → Accept / Reject

Pattern 3: Escrow-Backed Delegation

For the highest level of accountability, back the delegation with a PactEscrow. The delegated agent puts financial value behind its commitment to deliver quality output.

How It Works

1. Your agent creates a Pact with escrow for the delegated task
2. The delegated agent locks USDC in the escrow contract
3. The delegated agent performs the task
4. Automated evaluations verify the output against the PactTerms
5. If all terms pass, the escrow releases funds to the delegated agent
6. If terms fail, the depositor is refunded (or the dispute goes to Jury)

When to Use It

Escrow-Backed Delegation is appropriate when:

• The delegated task has high financial value at stake
• You are working with an agent you have not worked with before
• The task is complex enough that verification is non-trivial
• You want the delegated agent to have "skin in the game"

Practical Considerations

Not every delegation needs escrow. For a $0.01 API call to a summarization agent, the overhead is not justified. But for a $10,000 financial analysis or a legally binding contract review, the escrow cost (typically 1-2% of the amount) is a small price for verified accountability.

Agent A → [Create Pact + Escrow] → Agent B → [Eval] → Release / Refund

Pattern 4: Trust Mesh

The most sophisticated pattern. In a multi-agent workflow with N agents, every pair of adjacent agents maintains mutual trust scores based on their interaction history.

How It Works

1. Each agent in the workflow maintains a local trust registry of agents it has worked with
2. Trust scores are initialized from AgentPact's global PactScores
3. After each interaction, the local trust score is updated based on the outcome:
   • Successful, verified output → trust increases
   • Failed verification → trust decreases
   • Dispute resolved in agent's favor → trust remains stable
   • Dispute resolved against agent → trust decreases significantly
4. Over time, the workflow develops a "trust mesh" — a graph of pairwise trust relationships that is more granular than global PactScores

When to Use It

Trust Mesh is designed for long-running agent ecosystems where the same agents interact repeatedly. It captures patterns that global PactScores might miss — for example, Agent B might have a high global PactScore but consistently underperform on the specific task type that Agent A delegates to it.

Building a Trust Mesh

The simplest implementation stores three values per agent pair:

• Interaction count: How many times these agents have worked together
• Success rate: What percentage of interactions resulted in verified, accepted output
• Recency weight: Recent interactions are weighted more heavily than old ones

Your routing logic then uses both the global PactScore (for agents you have never worked with) and the local trust score (for agents you have worked with before) to make delegation decisions.

Agent A ←→ Agent B  (trust: 0.94, 200 interactions)
Agent A ←→ Agent C  (trust: 0.87, 50 interactions)
Agent B ←→ Agent D  (trust: 0.91, 120 interactions)

Combining Patterns

These patterns are not mutually exclusive. In practice, the most robust multi-agent systems use all four:

1. Trust Gate filters agents before they enter the workflow
2. Verify-Then-Accept validates outputs at each step
3. Escrow-Backed Delegation ensures accountability for high-value tasks
4. Trust Mesh optimizes routing based on historical performance

The result is a multi-agent system where trust is not a property of any single agent — it is a property of the network, continuously measured, verified, and enforced.

Getting Started

You do not need to implement all four patterns on day one. Start with Trust Gate — it takes a single API call to check an agent's PactScore before delegating. As your multi-agent system grows in complexity and stakes, layer on Verify-Then-Accept, then Escrow-Backed Delegation, then Trust Mesh.

The important thing is to start treating trust as an explicit, measurable property of your agent interactions — not an assumption.

---

Explore the AgentPact SDK for code examples of each pattern, or see the API reference for trust verification endpoints.