A2A Task Lifecycle Witnessing: Cryptographic Evidence for Agent-to-Agent Delegation

1. Why A2A Needs Witnessing

The A2A protocol solves agent-to-agent communication. It does not solve agent-to-agent accountability. When Agent A delegates a financial analysis task to Agent B, and Agent B sub-delegates data retrieval to Agent C, the following questions have no answer in the protocol itself:

• Which agent touched which data, and when?
• Did the delegated agent actually complete the task, or did it silently fail?
• Was the context passed between agents complete and unmodified?
• Can a regulator reconstruct the full decision chain after the fact?
• Did any agent in the chain exceed its authorized scope?

These are not hypothetical concerns. The CSA MAESTRO threat model identifies repudiation (an agent denying it performed an action) and diffused accountability (no single party responsible for a multi-agent outcome) as structural risks in agentic systems. The Five Eyes "Careful Adoption" guidance explicitly calls for cryptographic agent identity and continuous behavioral monitoring across agent boundaries.

SWT3 addresses this by treating each A2A task state transition as a witnessable event. The witness layer sits beneath the A2A protocol, records every transition, and produces independently verifiable anchors. No modifications to agent logic are needed. The witness adapter observes state changes through the A2A task object and mints anchors automatically.

2. The A2A Task State Machine

The A2A protocol defines a task state machine with seven states. Each state transition represents a consequential moment in the agent delegation lifecycle. SWT3 witnesses each transition as an AI-A2A.1 anchor.

3. Factor Semantics

Three procedures cover the A2A witnessing surface. Each procedure captures different evidence through three factor fields (fa, fb, fc) that feed into the SWT3 fingerprint formula.

The fingerprint for each anchor is computed as SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. This formula is locked across all seven SDK languages.

4. Python Integration

Task Lifecycle Witnessing

from swt3_ai import Witness

witness = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_...",
    tenant_id="ACME_DEFENSE",
    agent_id="orchestrator-v3",
)

# Witness a task state transition
witness.witness_task_lifecycle(
    task_id="task-7f3a",
    state="submitted",
    target_agent="financial-analyst-agent",
    description_hash="e3b0c44298fc...",
)
# Produces: AI-A2A.1 anchor with state=submitted

# Later, when the task completes
witness.witness_task_lifecycle(
    task_id="task-7f3a",
    state="completed",
    target_agent="financial-analyst-agent",
    result_hash="a9f2b8d1c4e7...",
    duration_ms=1843,
)

Agent Card Discovery

# Witness the discovery of a remote agent's capabilities
witness.witness_agent_card_discovery(
    discovered_url="https://agents.example.com/.well-known/agent.json",
    card_hash="b7c9d2e4f1a8...",
    capabilities_matched=3,
    governance_coverage=0.94,
)

Context Chain

# Witness context being passed between agents
witness.witness_context_chain(
    destination_agent="financial-analyst-agent",
    context_hash="d4e5f6a7b8c9...",
    context_size=24576,
    context_type="filtered",
)

Auto-Witnessing with wrap_a2a

from swt3_ai.adapters.a2a import wrap_a2a

# Wrap the agent client to auto-witness every send()
witnessed_agent = wrap_a2a(my_a2a_client, witness=witness)

# All task lifecycle transitions are now witnessed automatically
result = witnessed_agent.send({"text": "Analyze Q3 revenue trends"})
# Mints AI-A2A.1 (submitted) on send, AI-A2A.1 (completed/failed) on response

5. TypeScript Integration

Task Lifecycle Witnessing

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  endpoint: "https://sovereign.tenova.io",
  apiKey: "axm_live_...",
  tenantId: "ACME_DEFENSE",
  agentId: "orchestrator-v3",
});

// Witness a task state transition
await witness.witnessTaskLifecycle({
  taskId: "task-7f3a",
  state: "submitted",
  targetAgent: "financial-analyst-agent",
  descriptionHash: "e3b0c44298fc...",
});

// When the task completes
await witness.witnessTaskLifecycle({
  taskId: "task-7f3a",
  state: "completed",
  targetAgent: "financial-analyst-agent",
  resultHash: "a9f2b8d1c4e7...",
  durationMs: 1843,
});

Agent Card Discovery

await witness.witnessAgentCardDiscovery({
  discoveredUrl: "https://agents.example.com/.well-known/agent.json",
  cardHash: "b7c9d2e4f1a8...",
  capabilitiesMatched: 3,
  governanceCoverage: 0.94,
});

Context Chain

await witness.witnessContextChain({
  destinationAgent: "financial-analyst-agent",
  contextHash: "d4e5f6a7b8c9...",
  contextSize: 24576,
  contextType: "filtered",
});

Auto-Witnessing with wrapA2A

import { wrapA2A } from "@tenova/swt3-ai";

const witnessedAgent = wrapA2A(myA2AClient, { witness });

// All task lifecycle transitions witnessed automatically
const result = await witnessedAgent.send({ text: "Analyze Q3 revenue trends" });

6. MCP Server Integration

The SWT3 MCP server exposes three tools for A2A witnessing. Any MCP client (Claude Desktop, Cursor, Windsurf, or a custom agent) can call these tools directly.

// MCP tool call example (from any MCP client)
{
  "tool": "witness_task_lifecycle",
  "arguments": {
    "task_id": "task-7f3a",
    "state": "completed",
    "target_agent": "financial-analyst-agent",
    "result_hash": "a9f2b8d1c4e7..."
  }
}

The MCP server is installed as @tenova/swt3-mcp and runs as a stdio or streamable HTTP transport. See the MCP Connect guide for setup.

7. Framework Coverage

A2A task lifecycle witnessing maps to regulatory and industry frameworks across jurisdictions. The evidence produced by AI-A2A.1, AI-A2A.2, and AI-A2A.3 satisfies specific articles, controls, and recommendations.

8. Clearing Levels

SWT3 clearing levels control what evidence survives in the witness ledger. Higher levels strip more identifying data while preserving the cryptographic proof that witnessing occurred.

Jurisdiction, legal basis, and purpose class (CJT fields) survive all clearing levels. This means regulatory attribution is preserved even at Level 3, where operational details are fully redacted.

9. Delegation Chain Forensics

When multiple agents participate in a workflow, each agent mints its own anchors. Linking these anchors into a coherent chain of custody is accomplished through the contextId field, which is shared across all agents in a single workflow.

How It Works

• The orchestrator agent generates a contextId (or uses the A2A task ID) when initiating a workflow
• Every witness call within that workflow includes the same contextId
• Sub-delegations inherit the parent contextId, creating a tree structure
• AI-A2A.3 (Context Chain) anchors record what data crossed each agent boundary
• During forensic review, querying by contextId reconstructs the full chain

Reconstruction Example

# Query all anchors in a delegation chain
chain = witness.query_chain(context_id="task-7f3a")

# Returns ordered list:
# 1. AI-A2A.2 - orchestrator discovered financial-analyst (t=0ms)
# 2. AI-A2A.1 - task submitted to financial-analyst (t=12ms)
# 3. AI-A2A.3 - context passed: 24KB, type=filtered (t=15ms)
# 4. AI-A2A.1 - financial-analyst state=working (t=45ms)
# 5. AI-A2A.1 - financial-analyst state=completed (t=1843ms)
# 6. AI-A2A.3 - result context returned: 8KB (t=1850ms)

Each anchor in the chain is independently verifiable. An auditor can take any single anchor, recompute its fingerprint from the recorded factors, and confirm it matches the ledger entry. The chain provides ordering and context; the anchors provide integrity.

Gaps in the Chain

A complete chain has an AI-A2A.1 anchor for every state transition. If an agent processes a task but does not produce anchors, the gap is visible: the chain will show submitted followed by completed with no working state in between. These gaps are findings during assessment, indicating unwrapped agents in the delegation path.