Reading guide: This guide covers multi-agent patterns. For the SDK quickstart, see the Implementation Guide. For assessor checklists, see the Assessment Guide. For MCP-specific integration, see the MCP Trust Mesh Guide.
CRITICAL ASSESSOR NOTICE: SWT3 witness anchors are evidence artifacts, not compliance determinations. Each anchor records that a governance-relevant event occurred and preserves its cryptographic fingerprint. The assessor determines whether the evidence satisfies a given control requirement. The protocol does not make pass/fail compliance decisions on behalf of any regulatory body. Substance verification remains the assessor's responsibility.

1. The Problem

Multi-agent AI systems are networks of specialists. An orchestrator dispatches tasks to a classifier, a summarizer, a retrieval agent, and a tool executor. Each agent may run on different infrastructure, use different models, and be maintained by different teams. The orchestrator delegates authority with every dispatch.

No multi-agent framework provides compliance verification natively. LangGraph routes messages between nodes. CrewAI assigns tasks to agents. AutoGen manages conversations between participants. None of them ask: "Does this agent have active guardrails? Is its model attested? Has it been revoked?" The routing happens. The compliance gap stays invisible until an auditor asks for evidence.

The SWT3 Trust Mesh adds a verification gate at every handoff. Before an orchestrator sends data to a worker, before two peers exchange context, before a delegation chain passes authority, the receiving agent's compliance posture is verified and recorded.

2. What Trust Mesh Does

Trust Mesh is a protocol for mutual compliance verification between AI agents. Each agent presents a cryptographic credential proving its compliance posture. The receiving agent verifies the credential locally, assigns a trust level (0=denied through 4=sovereign), and the verification itself is recorded as an immutable SWT3 witness anchor.

Two procedures are minted per verification: AI-TRUST.1 (verification result: pass/fail and trust level) and AI-TRUST.2 (handshake evidence: checks performed and passed). Both are independently verifiable at the public /verify endpoint.

For the full protocol specification, see the Protocol Reference. For the SDK quickstart, see the Implementation Guide.

3. Pattern A: Orchestrator Verifies Workers

The most common multi-agent architecture. A central orchestrator dispatches tasks to specialist agents. Before sending data, the orchestrator verifies each specialist. This pattern works with LangGraph, CrewAI, AutoGen, or any custom orchestrator.

from swt3_ai import Witness

# Orchestrator
orchestrator = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_orch_key",
    tenant_id="acme-prod",
    agent_id="orchestrator-v1",
    signing_key="orch-signing-key",
    flush_interval=30,
)

# Worker agents present credentials at registration
workers = {
    "classifier": classifier_witness.present_credential(),
    "summarizer": summarizer_witness.present_credential(),
    "retrieval":  retrieval_witness.present_credential(),
}

# Before dispatching each task, verify the worker
def dispatch(task, worker_name):
    credential = workers[worker_name]
    result = orchestrator.verify_trust(credential)

    if not result.granted:
        log.warning(f"Worker {worker_name} denied: {result.denial_reason}")
        return None  # Do not dispatch to unverified agent

    # Safe to dispatch
    return send_task(task, worker_name)
What the assessor sees:

The ledger shows a sequence of AI-TRUST.1 anchors minted by the orchestrator, each with a different counterpart_agent_id. The assessor can confirm that every worker was verified before receiving data. If a worker was denied (factor_b=0), the corresponding task was not dispatched. This satisfies EU AI Act Art. 9 (risk management) and NIST AI RMF MAP 1.5 (third-party AI characterization).

Framework-agnostic: This pattern works with any orchestrator. In LangGraph, place the verification in the edge function before routing to a node. In CrewAI, verify in the task callback before assignment. In AutoGen, verify in the message filter before forwarding. The Trust Mesh API is the same regardless of framework.

4. Pattern B: Peer-to-Peer Verification

No central orchestrator. Agents discover and communicate directly. Each verifies the other before exchanging data. This pattern is common in decentralized agent networks and federated deployments.

from swt3_ai import Witness

# Agent A and Agent B are peers in different organizations
agent_a = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_a_key",
    tenant_id="org-alpha",
    agent_id="research-bot",
    signing_key="alpha-signing-key",
    flush_interval=30,
)

agent_b = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_b_key",
    tenant_id="org-beta",
    agent_id="data-bot",
    signing_key="beta-signing-key",
    flush_interval=30,
)

# Each trusts the other's organization
agent_a.trust_registry.trust_tenant("org-beta")
agent_a.trust_registry.register_signing_key("data-bot", "beta-signing-key")
agent_a.trust_registry.set_require_signature(True)

agent_b.trust_registry.trust_tenant("org-alpha")
agent_b.trust_registry.register_signing_key("research-bot", "alpha-signing-key")
agent_b.trust_registry.set_require_signature(True)

# Mutual verification
cred_a = agent_a.present_credential()
cred_b = agent_b.present_credential()

result_ab = agent_b.verify_trust(cred_a)  # B verifies A
result_ba = agent_a.verify_trust(cred_b)  # A verifies B

if result_ab.granted and result_ba.granted:
    # Both verified. Safe to exchange data.
    exchange_data(agent_a, agent_b)
What the assessor sees:

Four anchors in the ledger: two AI-TRUST.1 + two AI-TRUST.2 (one pair per direction). The assessor can confirm bilateral verification occurred. Cross-tenant verification (different tenant_id values) proves the organizations explicitly trusted each other. Signed credentials (factor_c >= 2) prove cryptographic identity verification, not just tenant membership.

5. Pattern C: Chain of Trust

Agent A delegates to Agent B, which delegates to Agent C. Each handoff includes a trust verification. The full chain is auditable in the ledger.

Agent A (Orchestrator) Agent B (Processor) Agent C (Executor) | | | |-- present_credential ---->| | | |-- verify_trust(A) | | | Mints AI-TRUST.1/2 | |<-- TrustResult (granted) -| | | | | |-- dispatch task --------->| | | |-- present_credential --->| | | |-- verify_trust(B) | | | Mints AI-TRUST.1/2 | |<-- TrustResult (granted) | | | | | |-- delegate sub-task ---->| | | |-- execute | |<-- result ---------------| |<-- result ----------------| |

The ledger now contains four AI-TRUST.1 anchors: two from B verifying A, and two from C verifying B. An assessor can trace the full delegation chain by querying AI-TRUST.1 anchors and following the counterpart_agent_id values.

What the assessor sees:

A delegation chain produces a sequence of AI-TRUST.1 anchors with timestamps that show B verified A before C verified B. Gaps in the chain (a delegation without a preceding verification) are a finding. The assessor can reconstruct the full authority path from the ledger without access to the agents themselves. This maps to EU AI Act Art. 25 (obligations along the AI value chain).

6. Factor Interpretation for Multi-Agent Chains

When reviewing a multi-agent deployment, the ledger contains multiple AI-TRUST.1 anchors. Here is how to read them as a sequence:

AnchorTimestampAgent (Verifier)Counterpartfactor_bfactor_cMeaning
AI-TRUST.110:00:01orchestrator-v1classifier-v212Orchestrator verified classifier at VERIFIED level
AI-TRUST.110:00:02orchestrator-v1summarizer-v112Orchestrator verified summarizer at VERIFIED level
AI-TRUST.110:00:03orchestrator-v1retrieval-v300Orchestrator denied retrieval agent (FAIL)
AI-TRUST.110:00:05classifier-v2summarizer-v111Classifier verified summarizer at BASIC level

What this tells the assessor: The orchestrator verified three workers. Two passed (classifier and summarizer at VERIFIED). One failed (retrieval agent denied). The classifier then independently verified the summarizer before passing its output. The retrieval agent's failure at 10:00:03 should correspond to a task not being dispatched. If retrieval results still appear in the output after 10:00:03, the denial was not enforced (a finding).

7. Configuration for Multi-Agent

A multi-agent .swt3.yaml lists all agents, their signing keys, and the minimum trust level required.

# .swt3.yaml for a multi-agent orchestrator
trust_mesh:
  mode: strict
  min_trust_level: 2
  require_signature: true
  freshness_window: 3600          # 1 hour
  required_procedures:
    - AI-INF.1                    # Must have inference provenance
    - AI-GRD.1                    # Must have guardrails
  trusted_tenants:
    - acme-prod
    - partner-org
  signing_keys:
    - agent: classifier-v2
      key_env: CLASSIFIER_KEY
    - agent: summarizer-v1
      key_env: SUMMARIZER_KEY
    - agent: retrieval-v3
      key_env: RETRIEVAL_KEY
  deny_agents:
    - deprecated-classifier-v1    # Retired agent
What the assessor sees:

The configuration declares the full agent inventory, trust requirements, and deny list. The assessor should verify: (1) every agent in the inventory has a signing key registered, (2) required_procedures match the organization's compliance requirements, (3) the deny list includes any agents that have been retired or compromised, (4) the config file is under version control with a matching deployed hash.

8. What the Assessor Asks

Multi-agent deployments require additional assessment beyond single-agent trust mesh checks. Use this checklist alongside the standard 15-point configuration checklist.

9. Regulatory Mapping

Multi-Agent EvidenceEU AI ActNIST AI RMFNIST 800-53CMMC
Orchestrator verifies workersArt. 9(2)(c) - risk managementMap 1.5 - third-party AIAC-3 - Access EnforcementAC.L2-3.1.1
Mutual peer verificationArt. 25 - value chain obligationsGovern 1.6 - stakeholder engagementIA-2 - IdentificationIA.L2-3.5.1
Delegation chain audit trailArt. 12 - record-keepingMeasure 2.5 - monitoringAU-3 - Content of Audit RecordsAU.L2-3.3.1
Agent retirement / deny listArt. 9(7) - corrective actionsManage 4.1 - risk responseAC-2 - Account ManagementAC.L2-3.1.2
Cross-tenant key exchangeArt. 15(4) - cybersecurityManage 2.4 - risk treatmentIA-5 - Authenticator ManagementIA.L2-3.5.7

10. Getting Started

pip install swt3-ai          # Python
npm install @tenova/swt3-ai  # TypeScript

Start with Pattern A (orchestrator verifies workers). It covers the most common architecture and produces the clearest audit trail. Add peer-to-peer verification when agents span organizations. Add delegation chains when authority passes through more than two agents.

No API key? The SDK runs in local demo mode. Anchors log to the console instead of persisting to the ledger. Create a free account when you want persistent evidence.

This guide is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. Regulatory mappings and crosswalk interpretations reflect the publisher's analysis and may not address all obligations applicable to your organization. Consult qualified legal counsel before making compliance decisions based on this content.