← Back to knowledge center

A2A and MCP: an enterprise AI-agent architecture

An enterprise agent rarely works alone: one accepts the goal, another retrieves evidence, a third prepares a change and a fourth verifies the result. The architecture should let teams replace participants without granting excessive authority or losing an end-to-end execution record.

V
Virtek AI and Infrastructure TeamCompute platform architecture

Separate horizontal and vertical communication

A2A supports collaboration between agents: capability discovery, task exchange, result delivery and tracking of long-running work. MCP connects an AI application to tools, APIs and data sources. In a typical design, agents communicate through A2A while each participant reaches its own tools through MCP or conventional service interfaces.

Combining the layers creates tight coupling: an agent learns the partner's internal tools, and replacing one implementation breaks the complete workflow.

Publish a capability contract

An agent card should declare purpose, skills, input and output types, interaction modes, authentication requirements and constraints. It is a machine-readable contract, not marketing copy. Version schemas and state latency, idempotency and cancellation behaviour.

The planner selects endpoints from an approved registry rather than accepting an arbitrary address from user content. Internal and external agents belong to separate trust zones.

Delegate bounded authority

Each request should carry the caller's workload identity, its relationship to a user or business process, and a narrow delegated scope. The receiving agent must not inherit all rights of the initiator. Short-lived authority can be restricted by task, system, time, data range and permitted action.

When work is delegated again, preserve the authority chain. Investigators can then identify who initiated the action, who selected the executor and which policy allowed it.

Make execution observable

One correlation ID should join the original goal, agent messages, tool calls, policy decisions, human approvals and the downstream outcome. Store verifiable events rather than hidden model reasoning: request, selected capability, redacted parameters, result and state change.

Track task success, hand-offs, retries, human waiting time, cost, policy denials and stranded workflows.

Design for failure and substitution

Define timeout, retry, compensation, human escalation and unavailable-agent behaviour in advance. A long-running task must survive a restart without executing twice. The architecture becomes enterprise-ready when an individual agent can be replaced, stopped or de-authorized without destroying the business process.

Need an architecture
for your workload?

We will review inputs, risks and constraints, then propose a reasoned solution.

Talk to an engineer↗︎