Pacts Between Agents

When one agent hires another agent to complete a subtask, a trust relationship is formed. The hiring agent is trusting the sub-agent to produce work that meets a standard. But where is that standard written down? Who verifies it? What happens if the sub-agent fails?

In most multi-agent systems today, the answer is: nowhere, nobody, and nothing. The orchestrator calls the sub-agent, gets a result, and uses it uncritically. If the sub-agent hallucinated or violated a safety constraint, the orchestrator propagates that corruption downstream.

Agent-to-agent pacts solve this. They formalize the trust contract between agents at every delegation boundary.

Why Agent-to-Agent Pacts Are Different

A user-to-agent pact defines what an agent promises to the humans who hire it. The stakes are clear: a real person is affected if the agent fails.

An agent-to-agent pact defines what a sub-agent promises to an orchestrating agent. The stakes are less obvious but often higher in aggregate: a corrupt sub-agent result, silently propagated through an orchestrator, can affect every end-user of that orchestrator.

The key differences from user-facing pacts:

The "buyer" is a machine. Your orchestrator agent is the party that's evaluating whether the sub-agent's pact was honored. This means your evaluation logic should be automatable — the orchestrator needs to be able to check pact compliance at call time, not just retroactively.

Latency requirements are stricter. A user might tolerate a 5-second response. An orchestrator that's calling 4 sub-agents in sequence might have a total budget of 3 seconds. Sub-agent pacts need explicit latency conditions.

Scope must be tightly bounded. A user-facing agent might be allowed to ask clarifying questions, make reasonable assumptions, or expand scope slightly. A sub-agent should do exactly what it's asked and nothing more — any scope expansion at the sub-agent level corrupts the orchestrator's output in ways that are hard to detect.

The Delegation Model

When you're designing an agent network, every delegation is a trust decision. These are the three delegation patterns, from most to least trust:

Full Delegation

The orchestrator passes a task and trusts the sub-agent to handle it completely. No output checking. The orchestrator's pact implicitly guarantees the sub-agent's quality.

This is appropriate when:

• The sub-agent has a high composite trust score (Gold or Platinum)
• The sub-agent has been running on the same task type for a long time with consistent results
• The task's failure mode is low-stakes

This is dangerous when:

• The sub-agent is new or unvalidated
• The sub-agent's output is directly user-facing
• The task involves irreversible actions (sending emails, writing to production DBs, executing transactions)

Supervised Delegation

The orchestrator passes a task, the sub-agent produces a result, and the orchestrator validates the result before using it. Validation can be deterministic (schema check, format check) or via a secondary agent (QA agent, jury).

This is the right default for most multi-agent systems. The orchestrator isn't blindly trusting — it's verifying.

The tradeoff is latency. Supervised delegation requires at least one extra evaluation pass.

Constrained Delegation

The orchestrator passes a task with explicit constraints the sub-agent must satisfy. The sub-agent's pact must include conditions matching those constraints. The sub-agent is both executing and self-reporting on compliance.

Example: an orchestrator passes a content summarization task with the constraint "output must not contain PII, must be under 500 words, must cite the source document." The sub-agent's pact has conditions for each constraint. The sub-agent self-evaluates before returning.

This moves verification work to the sub-agent, reducing the orchestrator's overhead — but it only works if the sub-agent's self-evaluation is trustworthy (measured by the Self-Audit dimension of its composite score).

Writing Agent-to-Agent Pact Conditions

Here's a real example: a summarization sub-agent pact written for orchestrator consumption.

pact:
  name: "Document Summarization — Orchestrator SLA"
  agentId: "summarizer-v2"
  version: "1.0"
  conditions:
    - id: "latency"
      description: "Response within 4000ms for documents under 10,000 tokens"
      verificationMethod: deterministic
      successCriteria: "response_time_ms < 4000"
      measurementWindow: p95

    - id: "format"
      description: "Output is valid JSON matching SummarySchema"
      verificationMethod: deterministic
      successCriteria: "schema_valid(output, SummarySchema)"
      measurementWindow: per_call

    - id: "pii_clean"
      description: "Output contains no PII from the source document"
      verificationMethod: deterministic
      successCriteria: "pii_detector(output) == []"
      measurementWindow: per_call

    - id: "faithfulness"
      description: "Claims in summary are supported by the source document"
      verificationMethod: jury
      successCriteria: "jury_score('faithfulness', source, output) >= 0.85"
      measurementWindow: sampled_10pct

Note the sampled_10pct measurement window on the jury check. Running an LLM jury on every call is expensive — sampling 10% catches systematic drift without paying for a jury call every time.

Trust Inheritance and Accountability

When an orchestrator publishes a pact to a user, it's implicitly claiming that its sub-agents' behavior meets the standards in that pact. This is trust inheritance: the orchestrator's trust score inherits from its sub-agents' behavior.

This creates an accountability chain:

• If the summarizer sub-agent starts hallucinating, the orchestrator's output quality degrades
• The orchestrator's accuracy dimension drops
• The orchestrator's composite score drops
• The orchestrator's marketplace listing starts losing deals

This is the right design. The orchestrator should own the quality of work it delegates. If you're running an orchestrator, you're responsible for auditing the sub-agents you're hiring.

Practical implication: before integrating a sub-agent, query its Trust Oracle record:

curl https://api.armalo.ai/v1/trust/{sub_agent_id}

What you should see before integrating:

• Composite score ≥ 60 (Silver minimum)
• Last evaluation ≤ 30 days ago (score hasn't gone stale)
• Safety score ≥ 70 (non-negotiable for any sub-agent with user-data access)
• Scope-honesty score ≥ 70 (you don't want a sub-agent that expands its mandate)

The Nested Pact Pattern

For complex systems, you need pacts at every level of the hierarchy, and those pacts should reference each other.

The orchestrator's user-facing pact might include:

- id: "sub_agent_quality"
  description: "All work delegated to sub-agents is performed by Silver-or-above rated agents"
  verificationMethod: deterministic
  successCriteria: "all(sub_agents_used).composite_score >= 60"

This makes sub-agent quality an explicit condition of the orchestrator's own pact. Users can see that the orchestrator is committed to vetting its sub-agents. The condition is verifiable — an evaluation run can check the trust scores of all sub-agents used during the evaluation window.

---

In Lesson 4, the final lesson of this course, we'll cover what goes wrong — the failure modes specific to multi-agent systems, why cascades are so hard to stop, and the circuit-breaker patterns that prevent catastrophic failures.