Reference Architecture for Autonomous Machine-to-Machine Intelligence Systems

Full report

On this page

Introduction to Autonomous Machine-to-Machine Systems

The transition from isolated, human-operated generative models to autonomous Machine-to-Machine (MATM) intelligence systems requires a fundamental shift in software architecture. In conventional deployments, a human operator acts as the orchestrator, identity provider, context manager, and error handler for an artificial intelligence application. When these systems are decoupled from routine human operation, they must independently discover capabilities, negotiate boundaries, assert cryptographic identities, delegate permissions, execute complex multi-step workflows, and recover from transient or systemic failures. Historically, integrating external knowledge and tools into large language models (LLMs) presented an "N x M integration problem," where every new data source required a bespoke custom integration code, such as an HTTP client or database connector, confining models to information available at training time1. To achieve autonomy without compromising security or operational predictability, a reference architecture must synthesize modern identity protocols, standardized tool-access layers, durable execution frameworks, and distributed tracing mechanisms. This report details an exhaustive reference architecture for MATM systems, analyzing the required protocol layers, comparing primary deployment paradigms, and outlining a structured adoption sequence. The design relies entirely on established specifications and current primary research, merging workload identity standards, rich authorization frameworks, and decentralized cryptographic tracing to formulate a robust ecosystem for autonomous software agents.

Synthesis of the Essential MATM Layers

A functional MATM architecture cannot rely on a single monolithic application framework. Instead, it must be constructed as a stack of specialized, composable protocols that separate concerns such as transport, identity, authorization, orchestration, and evidence. Distinguishing mandatory foundations from optional or emerging features is critical for establishing a secure, scalable system. Furthermore, identifying where established standards reduce integration costs versus where custom contracts are still necessary defines the current frontier of MATM engineering.

Client Access, Discovery, and Transport

For software agents to interact with external data sources, tools, and other agents, they require a standardized communication protocol. The Model Context Protocol (MCP), open-sourced in November 2024, provides a mandatory foundational layer for this purpose, utilizing JSON-RPC 2.0 to establish a standardized connection between applications (Hosts), connectors (Clients), and capability providers (Servers)1. MCP normalizes the exposure of Resources (readable or subscribable data), Prompts (templated workflows), and Tools (executable functions defined by JSON Schema)1. By standardizing these primitives, MCP eliminates the need for bespoke API integrations, solving the integration bottleneck that historically limited autonomous systems1. MCP supports multiple transport layers, including Standard Input/Output (STDIO) for local processes and HTTP with Server-Sent Events (SSE) for remote sessions1. During initialization, clients and servers negotiate capabilities; for instance, a server might offer "tools" and "resources," while a client might offer "sampling," allowing the server to request server-initiated LLM interactions1. Beyond the core protocol, experimental extensions such as Tasks (for asynchronous execution of long-running operations) and Skills (for discovering structured agent workflows) represent emerging proposals that further extend autonomy3. While MCP drastically reduces integration costs for transport, custom contracts are still needed to define the specific business logic and semantic meaning of the JSON payloads transferred between agents.

Communication Semantics and Intent

While MCP handles the transport and structural formatting of tool usage, true multi-agent coordination requires semantic intent. An agent must understand not just the shape of a JSON payload, but the purpose of the message. Established practices from the Foundation for Intelligent Physical Agents Agent Communication Language (FIPA ACL) offer a critical theoretical foundation here7. Originating from speech act theory, FIPA ACL introduces "performatives" or communicative acts, such as inform (stating a fact), request (asking for an action), cfp (call for proposal), propose, and agree9. Modern MATM systems incorporate these principles by passing semantic intent within the standardized JSON payloads of MCP or RESTful Agent Protocol interactions10. For example, the RESTful Agent Protocol, standardized by the AI Engineer Foundation, provides an open, vendor-neutral specification for starting tasks and streaming steps12. However, FIPA specifications highlight that while the performative specifies the intent, the actual content relies on a shared ontology7. This ontological mapping remains an area where custom contracts are required, as agents built by different developers must agree on the vocabulary used to describe domain-specific concepts, such as financial transactions or supply chain logistics10.

Cryptographic Identity and Authentication

In a system devoid of routine human operation, an agent cannot rely on forwarding a human user's session token indefinitely. Agents require a verifiable, independent identity. The architecture mandates the Secure Production Identity Framework For Everyone (SPIFFE) and its runtime environment, SPIRE, as the foundation for workload identity13. SPIFFE provides each executing agent with a cryptographically verifiable identity document (SVID), typically encoded as an X.509 certificate or a JSON Web Token (JWT-SVID)13. SPIRE achieves this through local platform attestation, verifying the actual running process—such as its Kubernetes namespace, pod labels, or kernel metadata—before issuing the credential13. This eliminates the reliance on static, long-lived secrets, establishing a zero-trust mutual TLS (mTLS) foundation for all MATM communications13. For distributed or cross-organizational MATM systems, the W3C Decentralized Identifiers (DIDs) Core v1.0 specification, published as a W3C Recommendation in July 2022, serves as a vital emerging standard17. DIDs provide a globally unique, cryptographically verifiable identifier that is not tied to a centralized registry or identity provider17. When an agent acts as a DID controller, it can independently prove its identity across trust domains. Each DID resolves to a DID document containing cryptographic material, such as public keys and verification methods, enabling entities to prove control over their identities without relying on external certificate authorities19.

Authorization and Explicit Delegation

Authentication verifies who the agent is; authorization dictates what the agent is permitted to do on behalf of a human user or another system. Impersonation—where an agent simply uses a human's bearer token—destroys auditability, obscures the actor's true identity, and violates the principle of least privilege21. Instead, the architecture mandates explicit delegation using OAuth 2.0 Token Exchange (RFC 8693), published in January 202016. In this flow, an agent presents a subject\_token (representing the human user) and an actor\_token (the agent's own SPIFFE JWT-SVID), receiving a newly minted, tightly scoped access token16. Crucially, this new token includes an act (actor) claim that explicitly records the delegation chain, ensuring that every downstream system recognizes both the original human subject and the specific software agent performing the action21. To achieve fine-grained precision during this exchange, the architecture leverages OAuth 2.0 Rich Authorization Requests (RAR, RFC 9396), published in May 202323. RAR replaces coarse-grained, static scopes with structured JSON objects detailing the exact nature of the request24. These objects include the type of action, target locations (such as specific URIs), actions, and specific datatypes24. This combination of RFC 8693 and RFC 9396 guarantees that each hop in a multi-agent workflow operates with the minimal necessary permissions, explicitly bound to both the user's granular consent and the agent's attested identity13.

Task Orchestration and Durable State

Agents operating autonomously will inevitably encounter network timeouts, API rate limits, transient infrastructure outages, and resource exhaustion. If an agent's memory or execution state resides entirely in volatile memory, any interruption results in a total loss of progress. To solve this, the architecture mandates a durable execution framework, such as Temporal, for task orchestration26. It is critical to avoid calling a simple message store or event bus an autonomous runtime merely because agents can connect to it; a message broker routes data but does not persist the programmatic execution state of the agent itself. Durable execution environments persist the state of every workflow step, including local variable states and execution histories, to an underlying database26. If an agent process crashes while waiting for an external MCP tool to respond, the orchestration engine seamlessly resumes the agent's code from the exact point of failure on a different compute node once resources are available26. Within this framework, deterministic reasoning loops are modeled as workflows, while non-deterministic interactions with the external world (such as LLM inference, API calls, or MCP tool execution) are encapsulated as retriable activities controlled by custom retry policies26.

Evidence, Resource Control, and Operations

To ensure accountability in autonomous operations, MATM systems require immutable evidence of actions taken. Advanced implementations utilize transparency logs, such as Sigstore and Trillian, to record cryptographic proofs of agent actions28. By appending a signed record of an agent's decision to an immutable ledger, operators gain an undeniable, cryptographically verified audit trail of the system's behavior29. Sigstore combines short-lived signing certificates, identity authentication through OpenID Connect, and transparency logging via Rekor to make software signing accessible and tamper-evident29. Furthermore, to prevent runaway resource consumption or malicious code execution (particularly when agents generate and execute code dynamically via MCP tools), resource control boundaries must be strictly enforced. The deployment of WebAssembly (WASM) or gVisor provides secure, lightweight sandboxing for agent execution, restricting file system access and network I/O at the kernel or runtime level30. Finally, cross-system operational visibility is maintained using the W3C Trace Context specification and OpenTelemetry31. By propagating standardized traceparent and tracestate headers through every protocol interaction—including MCP JSON-RPC messages and OAuth token exchanges—operators can reconstruct the exact lineage of a distributed multi-agent task, tracing a single user intent through multiple nested sub-agents and tool calls31.

Layer Synthesis Matrix

Major Research Findings and Evidentiary Support

An independent review of current protocols reveals several critical findings that dictate the design of modern MATM architectures. First, the integration problem has been decisively shifted from custom API adapters to standardized context protocols. The Model Context Protocol (MCP), formally detailed in specifications dated November 2024 and June 2025, successfully abstracts the connection between language models and external environments3. However, the documentation indicates that MCP itself is merely a stateless transport and capability negotiation layer1. It does not natively provide distributed state management, execution retries, or intrinsic reasoning capabilities. The architecture must therefore pair MCP with an external durable orchestration engine to achieve true autonomy26. Second, the historical conflation of human identity and agent identity is fundamentally incompatible with autonomous security. Allowing an agent to operate using a standard human bearer token obscures the actor's identity, destroying the audit trail and granting the agent over-privileged access21. The synthesis of SPIFFE (for hardware-backed workload attestation) and RFC 8693 (for cryptographic token exchange) is the only established method to maintain continuous, verifiable separation between the human who authorized the task and the software agent executing it13. This ensures that any malicious or erroneous action taken by the agent is explicitly attributed to the agent's workload identity via the act claim21. Third, the concept of "agent communication" is experiencing a renaissance, blending legacy academic models with modern web standards. While JSON schemas validate the structure of tool inputs1, they do not express the negotiation or collaborative strategies required for autonomous multi-agent systems. Research indicates a convergence toward integrating FIPA-style semantic performatives (such as cfp and propose) into the metadata of modern transport layers, allowing agents to understand not just the shape of the data, but the intent of the sender7. This is critical for scenarios where agents must bid on tasks or negotiate resource usage without human intervention.

Comparison of Deployment Architectures

MATM systems generally map to one of two structural paradigms: a centralized Hosted Coordination Service or a Distributed System with Managed Execution. Neither is universally superior; the optimal choice depends entirely on the organization's trust boundaries, latency requirements, geographic distribution, and scaling mechanics.

Hosted Coordination Service

In a hosted coordination model, a central control plane—often managed via a durable execution cluster like Temporal—acts as the absolute authority for agent lifecycle management26. Agents are deployed as stateless worker processes that poll the central orchestrator for tasks. The orchestrator maintains the global state, manages the database, and handles the centralized routing of MCP tool calls to registered servers. This style highly optimizes operational visibility and dramatically reduces the complexity of state management. Because all workflows are tracked centrally, recovering from a failed agent is trivial: the central service simply reassigns the durable task to the next available worker26. Furthermore, identity management is simplified, as the central service can operate within a single SPIFFE trust domain, relying on internal SPIRE servers for workload attestation13. However, this model introduces a heavy central dependency. If the coordination service experiences an outage or a database bottleneck, the entire agent ecosystem halts. It also struggles with edge computing scenarios where agents must operate in disconnected or highly latent environments, as constant polling to the central server is required.

Distributed System with Managed Execution

The distributed paradigm pushes autonomy to the edges of the network. In this model, agents operate as highly encapsulated, peer-to-peer entities, often running in local WebAssembly or gVisor sandboxes to isolate their execution environments15. Instead of a central database tracking state, state is passed directly between agents via asynchronous event streams or embedded within the protocol messages. Identity is negotiated directly between peers using Decentralized Identifiers (DIDs) and local Workload Identity Brokers (WIBs) rather than a centralized SPIRE server15. This approach excels in cross-organizational workflows and environments requiring strict data sovereignty. Because agents negotiate directly using protocols analogous to FIPA Contract-Net, there is no single point of failure9. Agents can securely verify each other's DIDs and Verifiable Credentials without phoning home to a centralized identity provider, utilizing OpenID for Verifiable Presentations (OpenID4VP)17. The tradeoff is a profound increase in integration cost, synchronization difficulty, and diagnostic complexity. Implementing durable state across a decentralized network requires complex consensus mechanisms, and reconstructing a failed multi-hop transaction requires meticulous implementation of distributed tracing standards like W3C Trace Context across disparate trust domains31.

Architectural Tradeoff Analysis

Recommended Design: The Minimum Useful System

For an enterprise seeking to implement a secure, autonomous MATM ecosystem, the recommended baseline design synthesizes the Hosted Coordination model with rigorous identity delegation. This architecture provides maximum control while enabling profound agent autonomy. It combines Temporal for durable state, MCP for tool discovery, and SPIFFE/OAuth 8693 for zero-trust authorization. The principles of this design easily transfer to other MATM domains, such as industrial IoT or autonomous supply chain bidding, by simply swapping the MCP tools from data-retrieval APIs to physical actuator controls or ERP system endpoints.

Core Architectural Components

1. Identity and Authorization Plane: An enterprise Identity Provider (IdP) for human authentication, an OAuth 2.0 Authorization Server capable of RFC 8693 Token Exchange, and a SPIRE server managing workload attestation13.

2. Orchestration Plane: A Temporal cluster managing durable execution workflows and ensuring task persistence26.

3. Agent Runtimes: Isolated compute instances (e.g., Kubernetes pods running gVisor) containing the LLM logic, a SPIFFE workload API socket, and an MCP Client instance2.

4. Resource Plane: External databases, SaaS applications, and local file systems exposed exclusively via standalone MCP Servers2.

Illustrative Workflow: Autonomous Financial Research Synthesis

To demonstrate this architecture in practice, consider a scenario where a human user requests a comprehensive financial risk analysis of a specific market sector. The system must autonomously coordinate a Planning Agent, a Web Search Sub-Agent, and a Database Access Sub-Agent27. Step 1: Human Consent and Policy Initiation The human user logs into an application portal, authenticating via the IdP and receiving an OAuth 2.0 access token containing an RFC 9396 Rich Authorization Request (RAR) payload23. This payload explicitly authorizes the execution of the workflow and bounds the scope. This represents the explicit authorization boundary and the primary human prerequisite.

JSON { "type": "financial\_analysis\_initiation", "locations": \[ "https://api.internal-market-data.example.com" \], "actions": \[ "read", "summarize" \], "datatypes": \[ "risk\_assessments", "market\_caps" \] }

Step 2: Workload Identity Attestation The portal application submits the human's token to the orchestrator. The Planning Agent pod spins up. Immediately, the agent contacts the local SPIRE agent via a Unix domain socket. SPIRE verifies the pod's cryptographic signature, namespace, and binary hash, returning a short-lived JWT-SVID (the agent's unique identity)13. Step 3: Cryptographic Token Exchange Before interacting with any sub-agents or tools, the Planning Agent must acquire a delegated execution token. It calls the Authorization Server using the RFC 8693 Token Exchange endpoint. It presents the human's access token as the subject\_token and its own JWT-SVID as the actor\_token16. The Authorization Server validates both, returning a new, tightly scoped "Agent Token" containing an act claim that explicitly records the agent's identity acting on behalf of the human21. Step 4: Durable Workflow Execution The Planning Agent initiates a Temporal workflow. Temporal records the start state in its durable database26. The agent analyzes the human's prompt and decides it needs external market data. Step 5: Capability Discovery via MCP The Planning Agent uses its MCP Client to query the network for available MCP Servers2. The central registry returns connection details for a Web Search MCP Server and an Internal Database MCP Server. During the MCP initialization phase, the client and servers negotiate capabilities, confirming the Database server supports the required tools capability1. Step 6: Orchestrating Sub-Agents with Trace Context The Planning Agent determines that web search and database retrieval should happen in parallel. It spins up two Sub-Agents. Crucially, the Planning Agent generates a W3C traceparent ID and passes it to both Sub-Agents, ensuring that all subsequent network calls, LLM inferences, and Temporal activities are cryptographically linked back to the original human request31. Step 7: Tool Execution and State Recovery The Database Sub-Agent connects to the Database MCP Server, passing the delegated Agent Token. The MCP Server validates the token, verifying both the human's RAR scope and the agent's identity21. During data retrieval, a network partition causes the Database Sub-Agent to crash. Because the system utilizes Temporal, the workflow does not fail. Temporal detects the timeout, automatically spins up a replacement Sub-Agent, and replays the exact state up to the point of the crash, seamlessly re-initiating the MCP tool call26. Step 8: Synthesis and Completion The Sub-Agents return their structured data. The Planning Agent synthesizes the final report, commits the output to the Temporal workflow history, and returns the result to the portal. The delegated Agent Token expires organically, preventing any further actions.

Remaining Human Prerequisites

This architecture effectively eliminates human involvement during execution, error recovery, and tool selection. However, human prerequisites strictly remain at the system's boundaries. Humans must establish the initial trust roots, including deploying the SPIRE server and configuring hardware node attestation policies14. Humans must define the baseline OAuth policies and configure the initial MCP server endpoints. Most importantly, humans must explicitly define the logical parameters of the Rich Authorization Requests that constrain the agents' operational scope prior to workflow initiation24.

Prioritized Feature Proposals for Greater Autonomy

To evolve the minimum useful system into a highly resilient, interoperable, and decentralized ecosystem, the following three features represent the optimal staging of advanced capabilities. They are prioritized based on the ratio of user value and agent autonomy gained to the implementation effort and architectural risk involved.

Proposal 1: Automated Capability Negotiation and Bidding (FIPA over MCP)

Problem: Currently, when an agent discovers multiple MCP servers offering similar tools (e.g., three different data retrieval servers or multiple peer agents capable of solving a sub-task), it lacks a standardized mechanism to determine which entity is optimal regarding latency, execution cost, or data freshness. Agents are forced to rely on static routing or hardcoded preferences, limiting system resilience. Agent-Visible Behavior: When querying for capabilities, an agent broadcasts a Call for Proposal (cfp) message formatted as a specialized MCP extension payload, mimicking the FIPA Contract-Net protocol9. State Transition Example:

1. Initiator broadcasts cfp (State: WAITING\_ANSWER).

2. Compatible MCP servers or peer agents reply with a propose message detailing their execution cost and estimated time.

3. The initiator evaluates the bids, issues an accept-proposal message to the winner, and issues a reject-proposal to the others10.

4. The winning agent executes the task and replies with an inform performative containing the results.

Expected Benefit: This feature drastically improves system resilience and cost efficiency. It allows the MATM ecosystem to self-optimize dynamically, routing around degraded services or expensive models without hardcoded load balancers, fulfilling the vision of autonomous peer-to-peer coordination. Dependencies: Requires an extension to the base MCP protocol (similar to the experimental Tasks or Roots extensions)3 and the adoption of an agreed-upon ontology mapped from FIPA ACL specifications7. Implementation Effort: Moderate. The JSON-RPC 2.0 transport of MCP is easily extensible, meaning the underlying network infrastructure requires no changes1. The primary effort involves standardizing the JSON schema for the bidding ontology and updating agent system prompts to evaluate the mathematical parameters of the bids correctly. Principal Failure Modes: Bid-storming (network congestion caused by too many servers responding to a broad broadcast); infinite negotiation loops where agents continuously counter-offer without reaching an agreement; optimization failures where generative models hallucinate the value of a bid.

Proposal 2: Cryptographic Action Provenance (Sigstore Integration)

Problem: While W3C Trace Context links logs together across distributed systems, and Temporal records workflow state, there is currently no immutable, cryptographically verifiable proof that a specific agent executed a specific action at a specific time. If the Temporal database is compromised or altered, the historical record of autonomous decisions cannot be trusted by external auditors. Agent-Visible Behavior: Immediately prior to executing a state-mutating tool via an MCP Server, the agent constructs a payload containing the tool parameters, the W3C traceparent ID, and its SPIFFE JWT-SVID. The agent signs this payload using an ephemeral key and submits it to a local Rekor transparency log14. The agent includes the resulting log inclusion proof in the MCP JSON-RPC request. The receiving MCP Server autonomously queries the Rekor log and rejects any request lacking this proof. Expected Benefit: Creates an undeniably secure, tamper-evident audit ledger of all machine-to-machine actions29. This is critical for highly regulated industries, such as finance or healthcare, where autonomous agents may execute legally binding agreements, authorize payments, or modify critical physical infrastructure. Dependencies: Requires the deployment of a Sigstore stack (Fulcio for ephemeral certificate issuance and Rekor for the transparency log) within the local trust domain, alongside deep modifications to both the Agent runtime (to generate signatures) and the MCP Server middleware (to verify inclusion proofs)28. Implementation Effort: High. Integrating ephemeral cryptographic signing into the high-frequency execution loops of autonomous agents introduces significant latency and requires fundamental modifications to the tool-execution pipeline. Principal Failure Modes: Transparency log bottlenecks slowing down total system throughput; key generation failures in the agent runtime causing tool execution denial; ledger desynchronization leading to false-positive security rejections during validation.

Proposal 3: Decentralized Identity Presentation (OID4VP over MCP)

Problem: The current SPIFFE/OAuth model relies on a centralized Authorization Server and a shared trust domain13. If an agent needs to communicate with an MCP Server hosted by an entirely different company, they do not share a SPIRE infrastructure. The agent cannot use a local JWT-SVID to authorize against a foreign server. Agent-Visible Behavior: The agent is provisioned with a W3C Decentralized Identifier (DID) and a digital wallet containing Verifiable Credentials (VCs) issued by its parent organization17. When the agent attempts to access a foreign MCP Server, the server challenges the agent using the OpenID for Verifiable Presentations (OpenID4VP) protocol35. The agent autonomously generates a Verifiable Presentation containing only the specific claims required (e.g., cryptographically proving it represents a partnered organization in good standing) and submits it to the server to establish an authenticated session36. Expected Benefit: Enables true boundaryless MATM ecosystems. Agents from different organizations can dynamically discover and utilize each other's services in a zero-trust environment without requiring their parent organizations to establish complex, static network federations, VPNs, or shared IAM directories17. Dependencies: Requires global DID resolution infrastructure, the implementation of OpenID4VP standard libraries within the agent runtime, and the transition of external authorization logic to handle verifiable presentations17. Implementation Effort: Very High. Requires shifting from traditional identity provider architectures to self-sovereign identity constructs, managing agent digital wallets, and ensuring cryptographic keys are securely generated and stored within the agent's sandboxed execution environment. Principal Failure Modes: Cryptographic key compromise within the agent wallet leading to identity spoofing across organizations; DID resolution failures due to external network partitions; complex error handling if the agent lacks the specific verifiable credential required by the foreign server's presentation definition.

Practical Adoption Sequence, Unresolved Questions, and Success Criteria

Implementing a robust MATM system should follow a phased adoption sequence, minimizing organizational risk while steadily increasing agent autonomy and architectural complexity.

Adoption Sequence

Phase 1: Transport and Encapsulation Standardization Organizations must first replace bespoke API integrations with the Model Context Protocol1. During this phase, agents remain heavily supervised by humans, operating as standard OAuth clients. The goal is strictly to standardize how context and tools are formatted and accessed, eliminating custom connector code. Phase 2: Durable Orchestration Introduce Temporal (or an equivalent durable execution engine) to manage agent lifecycles26. Transition agents from volatile, script-based execution loops to durable workflows that can survive process crashes. Implement W3C Trace Context propagation across all MCP interactions to ensure basic operational visibility31. Phase 3: Workload Identity and Delegation Implement SPIFFE/SPIRE to provide verifiable cryptographic identity to the agent runtimes13. Configure the enterprise Authorization Server to support RFC 8693 Token Exchange and RFC 9396 Rich Authorization Requests21. At this stage, agents operate autonomously but are strictly bounded by cryptographically enforced delegation chains tied back to the initiating human. Phase 4: Advanced Autonomy and Decentralization Deploy the advanced feature proposals. Implement Sigstore for immutable provenance logging of high-risk tool calls29. Expand agent logic to handle FIPA-style capability negotiation over MCP for dynamic tool selection7. Begin experimental deployment of DIDs and OpenID4VP for cross-organizational agent federation17.

Unresolved Questions

Several theoretical and technical questions remain unresolved in the current primary literature, requiring further research before industry-wide standardization can occur:

1. Context Window Contamination during Orchestration: How can a durable execution framework like Temporal efficiently snapshot and replay an agent's massive LLM context window (often exceeding 100,000 tokens) without incurring prohibitive database I/O costs and latency penalties?

2. Revocation Propagation: In a highly distributed, multi-hop MATM workflow utilizing token exchange, if the human user revokes their consent mid-execution, how is that revocation instantaneously propagated to deeply nested sub-agents operating asynchronously across different infrastructure nodes?

3. Ontological Mapping: While MCP standardizes the transport and JSON schema validation, there is no universally accepted ontology for agent-to-agent semantic communication. How can agents built by different developers reliably agree on the semantic meaning of complex multi-step proposals without human intervention?

Measurable Success Criteria

To evaluate the success of the implemented MATM architecture, future implementers should track the following measurable metrics, which serve as objective indicators of system health and autonomy:

Works cited

1. MCP Protocol Overview \- IBM, https://www.ibm.com/docs/en/quarkus/3.33.x?topic=architecture-mcp-protocol-messages-capabilities-lifecycle

2. Anthropic's Model Context Protocol (MCP): A Deep Dive ... \- Medium, https://medium.com/@amanatulla1606/anthropics-model-context-protocol-mcp-a-deep-dive-for-developers-1d3db39c9fdc

3. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28

4. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2025-06-18

5. Introducing the Model Context Protocol \- Anthropic, https://www.anthropic.com/news/model-context-protocol

6. Model Context Protocol \- GitHub, https://github.com/modelcontextprotocol

7. sarl/sarl-acl: FIPA Agent Communication Language for SARL \- GitHub, https://github.com/sarl/sarl-acl

8. Agent Communications Language \- Wikipedia, https://en.wikipedia.org/wiki/Agent\_Communications\_Language

9. Communication protocols \- ktiml mff uk, https://ktiml.mff.cuni.cz/\~pilat/en/multiagent-systems/communication-protocols/

10. Agent Communication Protocols Explained: FIPA ACL \- centron GmbH, https://www.centron.de/tutorials/agent-communication-protocols-explained-fipa-acl-kqml-mcp-ai-age

11. Some Remarks on the Semantics of FIPA's Agent Communication, https://ptabdata.blob.core.windows.net/files/2019/IPR2019-00836/v136\_Ex.%202031%20Some%20Remarks%20on%20the%20Semantics%20of%20FIPA's%20ACL.pdf

12. AI Engineer Foundation Agent Protocol (aka Arcadia) | VIPS Learn, https://learn.engineering.vips.edu/agent-protocols/arcadia-agent-protocol

13. SPIFFE vs. OAuth: Access Control for Nonhuman Identities \- Aembit, https://aembit.io/blog/spiffe-vs-oauth-access-control-nonhuman-identities/

14. \[FEATURE\] Workload identity for AI agents via SPIFFE/SPIRE \#122, https://github.com/inference-gateway/operator/issues/122

15. Local Delegated Agent Identity Architecture \- GitHub Pages, https://1password.github.io/agent-identity-specs/draft-1password-agent-identity-local-delegated.html

16. Securing agentic workflows with token exchange and workload identity, https://developer.pingidentity.com/blog/securing-agentic-workflows-with-token-exchange-and-workload-identity/

17. Decentralized Identifiers (DIDs) v1.0 \- W3C, https://www.w3.org/TR/did-core/

18. Decentralized Identifiers (DIDs) v1.0 becomes a ... \- W3C, https://www.w3.org/press-releases/2022/did-rec/

19. Decentralized Identifiers (DIDs) v1.1 \- W3C, https://www.w3.org/TR/did-1.1/

20. Decentralized Identifiers (DIDs) as Barcodes for Secure, Trusted, https://hyperonomy.com/2025/10/01/decentralized-identifiers-dids-as-retail-barcodes-for-secure-trusted-digital-communication/

21. Agent Governance Key Concepts \- TrueFoundry Docs, https://www.truefoundry.com/docs/agent-platform/agent-governance/key-concepts

22. The Kindred Agent Identity Framework (KAIF) \- IETF, https://www.ietf.org/archive/id/draft-lundholm-kaif-00.html

23. AuthZEN Request/Response Profile for OAuth 2.0 Rich ... \- IETF, https://www.ietf.org/archive/id/draft-brossard-oauth-rar-authzen-00.html

24. RFC 9396 \- OAuth 2.0 Rich Authorization Requests \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9396/

25. Rich Authorization Requests (RAR) \- Authlete Documentation, https://developers.authlete.com/v2/protocols-and-flows/protocol-extensions/rich-authorization-requests

26. Building Durable MCP Tools with Temporal: A Complete Guide \- Bitovi, https://www.bitovi.com/blog/building-durable-mcp-tools-with-temporal

27. MCP \+ Temporal Durable Agents, https://temporal.io/code-exchange/mcp-temporal-durable-agents

28. agent-provenance/docs/DESIGN.md at main \- GitHub, https://github.com/surroundapps/agent-provenance/blob/main/docs/DESIGN.md

29. Sigstore: Software Signing for Everybody \- ResearchGate, https://www.researchgate.net/publication/365216788\_Sigstore\_Software\_Signing\_for\_Everybody

30. AI Sandbox: The Complete Guide to Sandboxing AI Agents in 2026, https://cosmonic.com/blog/ai-sandbox-guide/

31. spec/cloudevents/extensions/distributed-tracing.md at main \- GitHub, https://github.com/cloudevents/spec/blob/main/cloudevents/extensions/distributed-tracing.md

32. Tracing SDK | OpenTelemetry, https://opentelemetry.io/docs/specs/otel/trace/sdk/

33. Trace Context \- W3C, https://www.w3.org/TR/trace-context/

34. Agent Identity Protocol (AIP) \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/01/

35. What is OpenID4VP? The Developer's Guide (2026), https://docs.walt.id/concepts/data-exchange-protocols/openid4vp

36. A Guide to OpenID for Verifiable Credentials \- Vouched, https://www.vouched.id/learn/blog/openid-for-verifiable-credentials

37. openwallet-foundation-labs/oid4vc-ts: OpenID for Verifiable ... \- GitHub, https://github.com/openwallet-foundation-labs/oid4vc-ts