The enterprise AI agent architecture nobody has built yet. Config-driven deployment, zero-trust auth at every hop, composable MCP domain services, durable execution, and BYOC deployment—on the A2A protocol.
Google’s Agent-to-Agent (A2A) protocol—now a Linux Foundation project—defines how AI agents discover each other, exchange tasks, and stream results over standard HTTP. The Model Context Protocol (MCP) defines how agents access tools. Together, they are the TCP/IP of the agentic AI era: the interoperability layer that lets enterprise AI agents from different vendors, different clouds, and different organizations work together.
But here is the problem nobody is talking about: neither protocol tells you how to actually deploy AI agents to production.
A2A gives you Agent Cards for discovery, task lifecycle for state management, and SSE for streaming. MCP gives you tool invocation and authorization. What neither spec provides is the runtime that connects these protocols to enterprise reality—config-driven AI agent deployment, zero-trust authentication at every hop, durable execution for multi-step workflows, domain-separated MCP servers that encode business logic, and a bring-your-own-cloud (BYOC) deployment model that keeps customer data in the customer’s cloud.
We built that runtime. It is the execution layer of Ultrathink Axon™, and this post explains why we built it, how the AI agent architecture works, and why the composability baked into this design is the difference between AI demos and AI that moves the P&L.
The A2A spec is a protocol, not a platform. It defines the wire format for agent communication the same way HTTP defines the wire format for web communication. Nobody ships a web application by implementing HTTP from scratch—they use a framework. The agentic AI ecosystem needs the same thing: a production runtime that implements A2A and MCP with the enterprise concerns—AI agent security, AI agent governance, observability, durability, multi-tenancy—already solved. That runtime does not exist in the open-source agentic AI frameworks today. We built it because our clients cannot wait for it.
The A2A protocol hit v1.0 in April 2026. The contributor list reads like a who’s who of enterprise AI: Google, Salesforce, ServiceNow, Databricks, SAP, Atlassian, AWS. The spec is well-designed. The reference implementations are clean. And if you follow the quickstart guide, you can have two agents talking to each other in an afternoon.
Then you try to deploy it for an actual enterprise.
Your sales team needs an AI assistant that queries their CRM, enriches leads from Apollo, pulls purchase history from Snowflake, and drafts personalized outreach—all scoped to the logged-in user’s permissions. Your finance team needs an agent that reconciles bank transactions, drafts journal entries, and escalates anomalies to a human approver—with durable state that survives crashes. Your operations team needs agents triggered by webhooks and cron schedules, not chat interfaces.
Each of these agents needs different models, different system prompts, different tool access, different auth providers, different response constraints. And all of them need to run in the customer’s own cloud, governed by the customer’s own security policies, with zero customer data leaving their VPC.
That is the Execution Gap applied to agent infrastructure. The spec tells you what the wire format looks like. It does not tell you how to build the platform that ships enterprise AI agents to production.
The Axon agent runtime is a single, composable execution engine that hosts any number of domain-specific agents. Each agent is defined entirely through configuration—an A2A Agent Card—not application code. The runtime handles everything else: protocol compliance, authentication, tool access, memory, observability, and deployment.
A2A governs how clients talk to agents—discovery, task lifecycle, streaming. MCP governs how agents talk to tools—tool discovery, invocation, authorization.
Two open protocols. Complementary roles. One runtime that connects them with the enterprise plumbing the specs left as an exercise for the reader.
This is the architectural decision that makes everything else possible.
Every agentic AI framework in the market today treats agents as application code. You write Python, define tools inline, hardcode your system prompt, wire up your model, deploy a new container. Need five agents? Deploy five applications. Need to tweak a system prompt? Rebuild and redeploy.
We took a different approach. An agent in the Axon runtime is an A2A Agent Card—a JSON document that declares everything the runtime needs to execute it:
name: "finance-reconciliation-agent"
description: "Daily bank reconciliation and journal entry drafts"
version: "1.0.0"
skills:
- id: "bank-reconciliation"
name: "Bank Reconciliation"
description: "Match bank transactions to GL entries"
- id: "journal-entry-drafting"
name: "Journal Entry Drafts"
description: "Draft journal entries from unmatched transactions"
# Axon runtime extensions
x-axon:
model: "claude-sonnet-4-6"
systemPrompt: "You are a finance agent for {org_name}..."
executionMode: "durable"
mcpServers:
- url: "https://finance-mcp.axon-system.svc/mcp"
audience: "finance-mcp"
toolHints: ["list_invoices", "get_transaction", "create_journal_*"]
- url: "https://snowflake-mcp.axon-system.svc/mcp"
audience: "snowflake-mcp"
toolHints: ["run_query"]
memory:
enabled: true
retrievalLimit: 5
responseConstraints:
sms: { maxLength: 1500, format: "plain_text" }
chat: { maxLength: 8000, format: "markdown" }
guardrails:
piiDetection: true
maxToolCalls: 20
costBudgetPerRun: 0.50
Standard A2A fields at the top provide interoperability—any
A2A-compliant client can discover this agent, understand its
skills, and send it tasks. The
x-axon
extension carries runtime-specific configuration: which model, which
MCP servers, what auth scopes, what constraints.
Deploying a new agent is a ConfigMap update, not an application deployment. The runtime watches for changes and hot-reloads. A new agent ships in seconds—write the card, apply it, done. No build pipeline. No container image. No Helm release.
This is not a simplification. It is a recognition that the execution loop—prompt the model, call tools, prompt again, return result—is generic. What varies between agents is configuration: the system prompt, the model, the tools, the constraints. Encoding that variance as data instead of code is what makes the runtime composable.
Most agentic AI frameworks treat auth as an afterthought—a middleware you bolt on at the edge. The MCP authorization specification is explicit about why that is wrong: token passthrough is forbidden. An access token scoped to one server must never be forwarded to another. Each MCP server must act as an independent OAuth 2.1 resource server, validating its own audience-scoped tokens.
Every hop gets its own token. Every token is audience-scoped. Every MCP server independently validates its own tokens. SpiceDB provides fine-grained, relationship-based access control at the tool level and the data level.
This is not theoretical. This is the MCP authorization spec implemented end-to-end: RFC 8693 token exchange, RFC 8707 resource indicators for audience binding, RFC 9728 Protected Resource Metadata for server discovery. Every standard cited in the spec, implemented in production.
Why this matters for enterprises: When your agents need to call MCP servers operated by different vendors—your CRM provider, your data warehouse, your ERP—zero-trust token exchange is the only pattern that works across organizational trust boundaries. A shared service account is a compliance failure. Token passthrough is a security vulnerability. Per-server audience-scoped tokens with identity propagation is the only architecture that satisfies both security requirements and the spec itself.
Here is the insight that connects the agent runtime to actual business value: MCP servers are the translation layer that converts probabilistic AI intent into deterministic business actions.
An LLM generates text. Text is not a bank transfer. Text is not a journal entry. Text is not a campaign launch. The MCP server sits at the boundary between “the model thinks we should do X” and “X actually happens in the system of record”—and it enforces every business rule, validation, and authorization check along the way.
Each domain service exposes two interfaces over the same service layer:
Same business logic underneath both. No duplication. The agent and the dashboard are both first-class consumers of the same domain, connected through different protocols optimized for their respective interaction patterns.
This is domain separation applied to agent infrastructure. Finance MCP servers encode finance business rules. HR MCP servers encode HR workflows. Operations MCP servers encode operational logic. Each one is independently deployable, independently scalable, and independently governed. An agent that needs to reconcile invoices and check inventory composes the finance MCP server and the operations MCP server—each validating its own tokens, enforcing its own authorization rules, scoping data to the authenticated user’s org.
The more domain MCP servers you build, the more capable every agent becomes. Each server compounds the value of the platform. A new agent that needs finance data and CRM data does not require new tool development—it references existing MCP servers in its Agent Card and inherits all their business logic, validation, and authorization for free.
Most agentic AI frameworks force a choice: simple request-response, or a full orchestration engine. The Axon runtime makes durability an opt-in property of the Agent Card.
Simple mode (the default) handles 80% of agent use cases—an LLM processes the request, calls tools, and returns a result. No orchestration overhead. No workflow engine.
Durable mode wraps the same agent logic in a Temporal workflow. Model requests, tool calls, and MCP communication become Temporal activities—durable, retryable, and recoverable. If the process crashes mid-reconciliation, it picks up exactly where it left off.
x-axon:
executionMode: "durable" # That is the only change.
The transport adapter does not know which mode is behind the
endpoint. The A2A protocol is the same either way. The
client—whether it is a chat UI, an SMS gateway, or a cron
trigger—sends
tasks/send
and gets back standard SSE event streams. The execution engine is an
implementation detail hidden behind the protocol.
Why this matters: Enterprise workflows like multi-step approval chains, long-running data reconciliations, and compliance audits cannot tolerate lost state. But adding orchestration complexity to every agent—even the ones that just answer a question—is engineering waste. One execution engine, two modes, one line of config to switch.
Every architectural decision above is meaningless if customer data leaves the customer’s environment. The Axon deployment model follows the Databricks pattern—control plane / data plane separation with zero inbound access:
The customer’s cluster runs NixOS + k3s. The Axon agent inside the cluster initiates all communication outbound—polling the control plane for desired state, then reconciling locally via Helm. No inbound ports. No VPN. No SSH access. The control plane pushes configuration (Agent Cards, capability specs, environment profiles). It never touches data.
Secret values—API keys, database passwords, model provider tokens—are stored in Kubernetes Secrets inside the customer cluster. The control plane stores references, never values.
Same architecture, any cloud. The deployment model is cloud-agnostic by design. NixOS + k3s runs on AWS, Azure, GCP, or bare metal. Environment profiles abstract the difference between self-hosted services and managed services. The Agent Card, the MCP servers, and the runtime are identical across all environments.
Enterprises will not have one agent vendor. They will have many—CRM agents from Salesforce, data agents from Databricks, workflow agents from ServiceNow, and domain-specific agents built on Axon. The question is not “which vendor wins?” The question is “how do these agents work together?”
A2A answers this at the protocol level. Agent Cards provide discovery. Task lifecycle provides coordination. JWS signatures verify agent authenticity across trust boundaries.
Axon implements federation end-to-end:
This is the A2A promise made real. Any A2A-compliant client—Salesforce, AWS Bedrock, ServiceNow—can discover Axon agents, authenticate, and send tasks. And Axon agents can discover and delegate to any A2A-compliant agent in the enterprise ecosystem. One protocol. Many vendors. Secure federation.
We looked for this before we built it. The build-vs-buy calculus applies to infrastructure too—and every option in the market today has the same structural gap.
Agentic AI frameworks (LangChain, CrewAI, AutoGen)—great for prototyping. None provide a production deployment model, zero-trust AI agent security, BYOC infrastructure, or spec-compliant A2A/MCP implementation. They solve the “make an agent work” problem, not the “ship agents to production with governance” problem.
AI agent orchestration platforms (LangGraph, Temporal)—excellent execution engines. Neither implements A2A for agent interoperability or MCP for tool access. Neither provides the agent-as-configuration model. They are workflow engines, not agent platforms.
Cloud AI services (AWS Bedrock Agents, Google Vertex AI Agent Builder)—managed, convenient, locked to one cloud. No BYOC. No cross-vendor federation. No customer data sovereignty. Enterprise AI agents need workflows, not chatbots—and these services conflate the two.
MCP server libraries (FastMCP, mcp-server)—the tool layer, not the runtime. No agent lifecycle, no auth, no deployment model.
The gap is in the composition layer—the runtime that takes A2A for agent communication, MCP for tool access, OAuth 2.1 for zero-trust auth, Temporal for durable execution, and a BYOC deployment model for data sovereignty, and weaves them into a single coherent platform where deploying a new enterprise AI agent is writing a config file.
That runtime is what we built. Not because we wanted another framework in the ecosystem, but because our clients—enterprise operations teams with mandates to ship AI that moves revenue and cuts costs—cannot afford to wait for one to emerge.
If you are deploying enterprise AI agents—real workflows, real data, real AI agent governance requirements—and the gap between your prototype and production is measured in months, start the conversation. The Axon agent runtime is a core component of Ultrathink Axon™, deployed into your cloud via the Outcome Partnership. We close the Execution Gap between “we have an agent that works in a demo” and “we have agents that move the P&L.”
Take the next step from insight to action.
No sales pitches. No buzzwords. Just a straightforward discussion about your challenges.