TL;DR
MCP and A2A solve different integration problems. MCP standardizes how an agent discovers and invokes tools, APIs, resources, and data services. A2A standardizes how independent agents discover one another, exchange messages, delegate work, manage long-running tasks, and return artifacts.
A durable enterprise design does not choose one protocol and force it to do both jobs. It uses A2A across agent boundaries and MCP inside each agent’s execution boundary. Identity, discovery, gateways, policy enforcement, approval controls, and observability surround both. The result is a layered architecture where agents can collaborate without exposing their internal tools, and tools remain governed without being misrepresented as autonomous agents.
Introduction
Enterprise agent platforms are moving beyond a single model calling a few APIs. A production workflow may involve a coordinator agent, several domain agents, dozens of tools, multiple identity systems, long-running tasks, human approvals, and data that crosses organizational boundaries.
That creates two different interoperability problems.
The first is agent-to-tool connectivity. An agent needs a consistent way to discover a capability, understand its input schema, call it, and validate the result. MCP fits this problem.
The second is agent-to-agent collaboration. One agent needs to determine whether another agent can perform a task, delegate work, exchange context, monitor progress, handle clarification requests, and receive one or more artifacts. A2A fits this problem.
The protocols are complementary, but combining them is not simply a matter of enabling both SDKs. The architecture must define where each protocol starts and stops, how identity is propagated without passing tokens blindly, how agents and tools are discovered, where policies are enforced, and how one transaction is traced across both protocols.
This article presents an enterprise reference pattern for doing that deliberately.
The Boundary That Keeps the Architecture Understandable
The most important design decision is not which protocol to deploy first. It is how the organization distinguishes an agent from a tool.
A tool exposes a bounded capability. It normally has a defined input, a defined output, and a relatively narrow responsibility. A database query, ticket creation operation, document search, configuration check, or deployment action can be modeled as a tool even when the implementation behind it is complex.
An agent accepts a goal rather than only a function call. It may reason, plan, ask for clarification, select tools, maintain task state, produce multiple artifacts, or decide that it cannot safely complete the request. That autonomy and task lifecycle are what make A2A appropriate.
| Decision question | Use MCP | Use A2A |
|---|---|---|
| Is the target a bounded operation with a defined schema? | Yes | Usually no |
| Can the caller treat the target as a capability rather than a collaborator? | Yes | No |
| Does the interaction require task state, clarification, or asynchronous updates? | Usually no | Yes |
| Does the target choose its own internal tools or plan? | Not required | Common |
| Should the target expose its internal memory or tool inventory? | Not applicable | No |
| Is the interaction primarily delegation between independent systems? | No | Yes |
The boundary is simple to state:
Use MCP to invoke capabilities. Use A2A to delegate outcomes.
That rule prevents two common design failures. The first is wrapping every API in an agent, which adds latency, non-determinism, and operational overhead without adding useful autonomy. The second is exposing a remote autonomous agent as if it were a synchronous tool, which hides task state, clarification, authorization pauses, cancellation, and failure semantics.
The Enterprise Reference Architecture
The architecture below separates the user-facing orchestration layer, the A2A collaboration plane, the internal MCP tool plane, and the enterprise control services that govern both.
What matters in this model is that the coordinator does not need direct access to every downstream tool. It delegates a task to the agent that owns the domain, policy context, operational knowledge, and tool set. The receiving agent uses MCP locally or through a controlled MCP gateway to perform the work.
This reduces the blast radius of the coordinator. It also lets domain teams change internal tools without changing every upstream agent, provided the A2A skill contract remains stable.
The Architecture Layers and Their Responsibilities
Experience and Entry Layer
The experience layer accepts requests from users, applications, event systems, or APIs. It authenticates the initiating principal, establishes the request context, applies intake controls, and selects the initial coordinator or domain agent.
This layer should not be allowed to invent downstream permissions. It carries the user and workload context into the agent system, but the authorization service decides what that context permits.
Typical responsibilities include request validation, rate limiting, tenant resolution, data-classification checks, abuse controls, session establishment, and creation of the root correlation identifier used throughout the workflow.
Coordinator Agent Layer
The coordinator determines whether it can answer directly, call one of its own MCP tools, or delegate to another agent through A2A. Its job is orchestration, not universal access.
A well-designed coordinator has a constrained set of responsibilities:
- decompose the request into tasks
- select approved agents from a trusted catalog
- attach the minimum context required for the delegated task
- define completion criteria and deadlines
- monitor task status
- handle clarification and authorization-required states
- combine returned artifacts
- present the final result or request human action
The coordinator should not receive broad credentials for every tool used by every downstream agent. That model turns orchestration into a privileged monolith.
A2A Collaboration Plane
The A2A plane carries task-oriented communication between independent agents. It is where the coordinator discovers an agent’s declared skills, confirms supported interaction modes, sends a task, receives progress updates, handles multi-turn clarification, and retrieves final artifacts.
The A2A Agent Card is the discovery contract. In an enterprise environment, it should be treated as a signed and governed service manifest, not as an automatically trusted advertisement. Public cards can expose a limited capability view, while authenticated extended cards can reveal additional approved skills to authorized clients.
A2A is also the correct place to preserve long-running task semantics. A downstream agent may return immediately, stream progress, expose a task for polling, or send asynchronous notifications. The caller should not have to pretend that every delegated outcome is a single synchronous function response.
Agent Runtime Boundary
Each domain agent owns its internal reasoning loop, state model, prompts, memory policy, tool selection, and exception handling. A2A does not require that internal implementation to be exposed to the caller.
This boundary is valuable for both security and organizational ownership. A finance agent can be operated by the finance platform team, a security agent by the security automation team, and an infrastructure agent by the platform engineering team. Each can maintain its own MCP servers, tool policies, evaluation suite, release cadence, and support model.
The A2A contract remains focused on what the agent can do, not how it does it.
MCP Tool Plane
The MCP plane provides structured tool and resource access inside an agent’s execution domain. MCP servers expose tools with names, descriptions, input schemas, and optional output schemas. Clients can list available tools and invoke the selected operation.
In production, the MCP plane should be curated. An agent should not be allowed to connect to any server it can find. Approved MCP servers belong in a registry with ownership, trust level, allowed environments, data classification, required scopes, network policy, version, and review status.
The MCP gateway or broker can then apply controls such as:
- server allowlists
- tool-level authorization
- schema validation
- argument constraints
- rate and concurrency limits
- egress restrictions
- secret injection
- approval gates for destructive operations
- output filtering and data-loss prevention
- audit event generation
MCP standardizes the interaction, but the enterprise still owns the policy.
Shared Enterprise Control Layers
Identity, authorization, policy, discovery, secrets, approvals, and observability should be shared services with protocol-specific adapters. They should not be duplicated independently inside every agent and MCP server.
Shared does not mean one physical component. It means one control model, consistent policy vocabulary, common evidence, and clearly defined ownership.
Identity Must Survive Both Protocol Boundaries
The hardest part of combining MCP and A2A is not message formatting. It is preserving trustworthy identity and authorization context across a chain of independent actors.
At minimum, the system may contain four identities:
- the human user or originating application
- the coordinator agent workload
- the delegated domain agent workload
- the MCP server or downstream resource
These identities are related, but they are not interchangeable.
Separate User Context from Workload Identity
The user identity answers who initiated the request. The workload identity answers which software component is making the current call. Both matter.
A delegated request should be able to say, in effect, that the infrastructure agent is acting because the coordinator delegated a task initiated by a specific user, under a specific tenant and policy context. It should not claim that the infrastructure agent is the user, and it should not erase the coordinator from the chain.
This distinction improves policy decisions and incident investigation. It also prevents every downstream system from receiving the user’s original bearer token.
Issue Audience-Bound Tokens Per Hop
Each protected service should receive a token intended for that service. A token issued for the A2A server should not be forwarded to an MCP server, and a token accepted by an MCP server should not be passed through unchanged to an underlying API.
The safer pattern is token exchange or fresh token acquisition at each boundary:
Every hop should have a narrower audience, shorter useful lifetime, and only the scopes required for that step. The delegation record should preserve who initiated the request, which agent delegated it, what purpose was approved, and how far delegation may continue.
Keep Authorization Decisions Local to the Resource
Central policy services are useful, but the resource still needs to enforce the result. The A2A server must authorize access to its skills and tasks. The MCP server must authorize tool discovery and invocation. The downstream API must authorize the action on the target resource.
A gateway can deny a request early, but it should not be the only enforcement point. Otherwise, direct network paths, configuration errors, or gateway bypasses become authorization bypasses.
Treat Human Approval as a First-Class State
Some requests cannot be authorized entirely by static scopes. Production changes, financial commitments, data exports, account modifications, and destructive infrastructure operations may require a human decision.
A2A supports task interruption and continuation patterns that fit this need. The domain agent can pause the task when authorization is required, return the reason and requested action, and resume only after the client supplies approved authorization. The underlying MCP tool call should not occur until the approval evidence is validated.
Discovery Needs Two Catalogs, Not One Unfiltered Marketplace
MCP and A2A both involve discovery, but they discover different things.
A2A discovery locates agents and their skills. MCP discovery locates servers, tools, prompts, and resources available to an agent. Combining these into one flat directory makes policy and ownership harder to understand.
The Agent Catalog
The agent catalog should store or index approved Agent Cards and enterprise metadata such as:
- agent owner and support team
- business domain
- declared skills
- A2A protocol version and bindings
- supported authentication schemes
- data classifications accepted and returned
- approved caller groups
- deployment region and residency constraints
- evaluation status
- change history
- card signature and verification state
- production readiness and lifecycle status
The well-known Agent Card endpoint is useful for protocol discovery, but enterprise callers should normally resolve agents through a trusted catalog or gateway. The catalog can validate signatures, apply allowlists, detect unauthorized card changes, and prevent direct trust in arbitrary endpoints.
The MCP Server and Tool Catalog
The MCP catalog should focus on executable capabilities:
- MCP server owner
- available tools and resources
- input and output schemas
- environment and network zone
- required scopes
- data sensitivity
- side-effect classification
- approval requirement
- rate limits
- dependency health
- server version and compatibility
- allowed agent identities
- retirement or deprecation status
The tool catalog should be scoped to the receiving agent. A finance agent does not need to see every infrastructure remediation tool, and a customer service agent should not discover privileged security operations merely because they exist.
Discovery Is a Policy Decision
Dynamic discovery is operationally useful, but discovery should never equal authorization. Finding an Agent Card does not grant permission to invoke the agent. Listing an MCP tool does not grant permission to call it.
The catalog answers what exists and what it claims to support. The policy system answers whether the current identity, task, tenant, environment, and purpose may use it.
Gateways Should Enforce Boundaries, Not Rewrite Semantics
An enterprise deployment will often place gateways in front of both A2A endpoints and MCP servers. The gateway provides a stable control point for identity integration, routing, rate limits, network policy, threat detection, schema validation, and telemetry.
The mistake is building one generic gateway that treats A2A messages and MCP tool calls as interchangeable JSON traffic.
A protocol-aware design has separate policy paths.
A2A Gateway Responsibilities
- validate the calling workload identity
- verify protocol version and supported binding
- resolve and validate the target Agent Card
- enforce caller-to-skill authorization
- limit delegation depth and fan-out
- constrain task duration and artifact size
- validate push notification destinations
- apply tenant and residency policy
- propagate trace and delegation context
- record task lifecycle evidence
MCP Gateway Responsibilities
- validate the MCP client identity
- enforce MCP server and tool allowlists
- scope tool visibility by identity and purpose
- validate input and output schemas
- block unsafe arguments and destinations
- inject downstream credentials without exposing them to the model
- require approvals for high-impact tools
- apply egress controls and data filters
- record tool call evidence and result metadata
The same gateway platform may implement both paths, but the policy objects, telemetry fields, and failure handling should remain protocol-aware.
A Realistic End-to-End Request Flow
Consider an operations assistant asked to investigate a production service degradation and prepare a remediation plan.
The coordinator agent can understand the request, but it should not hold direct access to every monitoring system, deployment platform, incident tool, and infrastructure API. It delegates the investigation to an operations domain agent.
The A2A task owns the investigation lifecycle. The MCP calls are implementation details inside the operations agent’s boundary. The final remediation action is a separate governed step, not an automatic consequence of diagnosis.
This distinction improves rollback, auditability, and change control. It also lets the operations agent replace one monitoring platform with another without changing the coordinator’s A2A contract.
Data, Context, and State Should Be Minimized at Every Hop
Multi-agent systems can easily copy the same prompt, conversation history, retrieved documents, and tool outputs across multiple services. That creates privacy, cost, retention, and prompt-injection risks.
The coordinator should send the receiving agent only the context required to complete the delegated task. The receiving agent should return structured artifacts and evidence rather than its full internal reasoning state or complete tool transcript.
A useful separation is:
- A2A message context: task goal, constraints, relevant business context, expected artifact, deadline, and correlation identifiers
- Agent-private state: planning notes, internal memory, model-specific state, intermediate reasoning, and private tool-selection logic
- MCP request context: exact tool name, validated arguments, purpose, authorization context, and trace identifiers
- Audit evidence: actor identities, policy decisions, tool and skill identifiers, timestamps, approvals, result classifications, and hashes or references to retained artifacts
Do not make full prompt and response capture the default observability strategy. Sensitive content should be opt-in, redacted, access-controlled, and retained for a defined purpose.
Observability Must Connect A2A Tasks to MCP Tool Calls
A2A and MCP produce different operational signals. The observability model must connect them without flattening them.
The root trace should begin at the user or application request. A2A spans should represent agent selection, delegation, task state changes, streaming, retries, and artifact transfer. MCP spans should represent server discovery, tool listing when relevant, tool invocation, latency, error status, result size, and downstream dependency calls.
At minimum, capture:
| Signal | A2A fields | MCP fields | Shared fields |
|---|---|---|---|
| Identity | caller agent, target agent, user context | MCP client, MCP server, tool caller | tenant, workload identity, delegation chain |
| Operation | send message, get task, subscribe, cancel | list tools, call tool, read resource | operation outcome, retry count |
| State | task ID, context ID, task state | request ID, tool result status | root trace ID, parent span ID |
| Performance | queue time, task duration, stream gaps | tool latency, downstream latency | end-to-end latency, timeout budget |
| Cost | agent model usage, task retries | model or tool cost where applicable | total request cost |
| Governance | selected skill, artifact classification | selected tool, side-effect class | policy decision, approval ID |
A useful trace hierarchy looks like this:
The trace should answer operational questions quickly: Which agent accepted the task? Which MCP tools were used? Which policy allowed the calls? Where did latency accumulate? Was a retry or delegation loop involved? Which artifact supported the final recommendation? Which human approved the action?
An Illustrative Policy Configuration
The following YAML is not a protocol standard. It is an example of the policy metadata an enterprise control plane could use to govern an A2A-to-MCP workflow.
agent_policy:
coordinator: operations-coordinator
allowed_delegations:
- target_agent: operations-domain-agent
allowed_skills:
- investigate-service-degradation
- prepare-remediation-plan
max_delegation_depth: 2
max_task_duration_minutes: 30
require_signed_agent_card: true
identity:
preserve_user_context: true
require_workload_identity: true
token_strategy: audience_bound_per_hop
prohibit_token_passthrough: true
mcp_policy:
agent: operations-domain-agent
allowed_servers:
- observability-mcp
- deployment-readonly-mcp
- incident-management-mcp
- remediation-mcp
tools:
remediation-mcp:
execute_change:
side_effect: destructive
require_human_approval: true
allowed_environments:
- production
max_invocations_per_task: 1
observability:
propagate_trace_context: true
capture_prompt_content: false
capture_tool_arguments: redacted
retain_policy_evidence_days: 90
retain_task_metadata_days: 30
The values that matter are not the YAML keys themselves. The important design choices are visible: delegation is constrained, Agent Cards must be trusted, tokens are issued per audience, token passthrough is prohibited, the domain agent receives only approved MCP servers, and a destructive tool requires human approval.
Deployment Patterns for Different Enterprise Boundaries
Centralized Agent Platform
A centralized platform team operates the entry gateway, agent registry, MCP registry, policy service, and observability pipeline. Domain teams publish agents and MCP servers into the shared platform.
Best fit: Organizations early in adoption that need strong standardization and a small number of platform-approved runtimes.
Advantages: Consistent controls, easier support, shared tooling, simpler onboarding, and centralized evidence.
Tradeoffs: The platform team can become a bottleneck, and domain-specific policies may be forced into a generic model.
Federated Domain Architecture
Each business or technical domain operates its own agent runtime and MCP tool plane. A shared A2A catalog, identity federation, policy vocabulary, and telemetry standard connect the domains.
Best fit: Large organizations with established domain ownership and different data, regulatory, or release requirements.
Advantages: Local autonomy, smaller blast radii, domain-specific tooling, and independent release cycles.
Tradeoffs: Stronger conformance testing, identity federation, catalog governance, and cross-domain incident processes are required.
Partner and External Agent Boundary
Internal agents communicate with supplier, customer, or partner agents through an external A2A gateway. Internal tools remain hidden behind internal MCP boundaries.
Best fit: Supply-chain coordination, managed services, partner workflows, and cross-company task delegation.
Advantages: Partner agents can collaborate without receiving direct access to internal tools or implementation details.
Tradeoffs: Trust establishment, data minimization, residency, contract versioning, artifact validation, and external incident handling become critical.
The external A2A gateway should terminate partner trust, validate Agent Cards, constrain skills, inspect artifacts, and prevent external identities from reaching internal MCP endpoints directly.
Failure Modes That Look Convenient During a Pilot
Modeling Every Agent as an MCP Tool
This works for a short demo because the caller sees one callable interface. It fails when the remote system needs clarification, long-running state, streaming progress, cancellation, authorization pauses, or multiple artifacts.
Use an MCP tool wrapper only when the capability is intentionally narrow and tool-like. Do not use it to hide a complex independent agent lifecycle.
Modeling Every Tool as an A2A Agent
An API call does not become more enterprise-ready because it is wrapped in an autonomous agent. The extra model call may increase latency, cost, and non-determinism while obscuring a perfectly good schema.
Keep deterministic capabilities as MCP tools unless autonomous planning or collaboration is genuinely required.
Passing the Original Token Through the Entire Chain
Token passthrough collapses trust boundaries and makes audience, attribution, revocation, and least privilege harder to enforce. Each hop should obtain a token intended for the next resource.
Trusting Discovery Metadata Automatically
A discovered Agent Card or MCP server description is a claim, not proof. Validate signatures where supported, resolve through trusted catalogs, enforce network policy, and require ownership and review metadata.
Letting the Coordinator Accumulate Every Permission
A coordinator with access to every tool becomes a high-value target and an operational bottleneck. Delegate to domain agents that hold narrowly scoped access to their own MCP plane.
Losing Trace Context at the Protocol Boundary
Without shared correlation identifiers, operations teams see an A2A task in one system, several MCP calls in another, and downstream API events somewhere else. Preserve trace context and delegation identifiers across all hops.
Logging Everything for Debugging
Full prompts, task histories, tool arguments, and artifacts can contain secrets, regulated data, customer content, or exploitable instructions. Capture metadata by default and sensitive content only under explicit policy.
Allowing Unbounded Delegation
Agents that can freely delegate can create loops, excessive fan-out, cost spikes, and unclear accountability. Enforce maximum depth, maximum parallel tasks, time budgets, cost budgets, and approved target agents.
A Phased Implementation Path
Establish the Protocol Boundary
Inventory current agents, APIs, tools, workflows, and integration points. Classify each target as a tool-like capability or an independent agent. Document exceptions where the choice is ambiguous.
Define the decision rule before teams begin publishing endpoints. Otherwise, each product team will make a different interpretation and the architecture will drift.
Build the Governed MCP Tool Plane
Start with a small number of high-value MCP servers behind clear ownership and policy. Require schemas, scoped identities, approval classification, output validation, logging, and lifecycle metadata.
Do not begin with unrestricted dynamic server discovery. Begin with an allowlisted registry and a small number of trusted agents.
Add A2A for Cross-Agent Delegation
Expose one or two domain agents through A2A. Publish governed Agent Cards, define stable skills, validate task lifecycle behavior, and test clarification, cancellation, timeout, failure, and authorization-required states.
The first A2A pilot should demonstrate a real delegation boundary, not two copies of the same agent calling one another.
Integrate Identity and Policy Per Hop
Introduce workload identities for every agent and server. Issue audience-bound tokens per resource. Preserve user context separately from workload identity. Add delegation-depth limits, tenant restrictions, data-classification rules, and approval evidence.
Test denied paths as seriously as successful paths.
Add End-to-End Observability and Evaluation
Propagate trace context across the entry gateway, A2A calls, agent runtimes, MCP calls, and downstream APIs. Create dashboards for latency, failure, task state, tool usage, cost, policy denials, and approval delays.
Evaluate the complete workflow, not only each model. A successful domain agent is not enough if the coordinator selects it incorrectly, context is lost, or the MCP tool produces an unsafe side effect.
Scale by Domain, Not by Tool Count
Expand one governed domain at a time. Add the domain agent, its A2A skills, its MCP server set, its policy owners, its evaluation suite, its support runbook, and its observability views as one operational unit.
This produces a manageable enterprise agent fabric instead of a large collection of disconnected protocol endpoints.
Ownership and Operating Model
| Capability | Primary owner | Operational responsibility |
|---|---|---|
| A2A protocol profile | Enterprise architecture or agent platform team | Versions, bindings, card standards, interoperability testing |
| Agent catalog | Agent platform team with domain owners | Registration, signature validation, lifecycle, ownership metadata |
| MCP registry and gateway | Platform engineering or integration team | Server approval, tool policy, routing, egress, compatibility |
| Identity and token service | Identity and security teams | Workload identity, token issuance, audience, revocation, federation |
| Policy decision service | Security governance with domain policy owners | Delegation, skills, tools, data, environment, approvals |
| Agent runtime | Domain product team | Prompts, models, state, tool selection, evaluation, support |
| MCP servers | Owning application or platform team | Tool schemas, downstream integration, validation, least privilege |
| Observability | Platform operations and SRE | Trace continuity, dashboards, alerts, retention, incident evidence |
| Human approvals | Business and operational control owners | Approval criteria, segregation of duties, evidence, escalation |
Ownership should follow the trust boundary. The team that owns the domain agent should own its behavior and MCP tool set. The central platform should own interoperability and shared controls, not every domain decision.
Decision Checklist
Before approving a combined MCP and A2A design, confirm that the architecture can answer these questions:
- Is every interaction classified as agent delegation, tool invocation, or ordinary API integration?
- Can each agent be operated without exposing its private memory or internal tool inventory?
- Are Agent Cards resolved through a trusted discovery path and verified before use?
- Are MCP servers and tools restricted by identity, purpose, tenant, and environment?
- Does every hop use a token intended for the receiving resource?
- Is user context preserved separately from workload identity?
- Can the system pause for authorization or human approval before a high-impact action?
- Are delegation depth, fan-out, duration, and cost bounded?
- Can one trace connect the user request, A2A task, MCP calls, policy decisions, and final artifact?
- Are sensitive prompts, arguments, results, and artifacts minimized and governed?
- Can operators cancel a task, revoke access, isolate an agent, and roll back a tool change?
- Does each agent and MCP server have a named owner, support path, and lifecycle status?
A design that cannot answer these questions is not ready for broad dynamic discovery or autonomous execution.
Conclusion
MCP and A2A fit together because they preserve two different abstractions. MCP lets an agent use a capability through a structured tool or resource interface. A2A lets an independent agent delegate a goal to another agent that owns its own reasoning, state, tools, and operational boundary.
The enterprise architecture should reflect that separation. A2A belongs between agents. MCP belongs between an agent and the tools inside its execution domain. Identity, discovery, gateways, policy, approvals, and observability must cross both layers without erasing their different semantics.
The practical starting point is not a large agent marketplace. It is one governed workflow with a clear coordinator, one domain agent, a small approved MCP tool plane, audience-bound identity at each hop, and a trace that proves what happened. Once that pattern is secure, observable, and operable, it can be repeated by domain.
The goal is not to connect everything to everything. The goal is to create controlled delegation between agents while keeping tool access narrow, explainable, and owned.
External References
- Model Context Protocol: Specification
Canonical URL: https://modelcontextprotocol.io/specification/2025-06-18 - Model Context Protocol: Authorization
Canonical URL: https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization - Model Context Protocol: Tools
Canonical URL: https://modelcontextprotocol.io/specification/2025-06-18/server/tools - Model Context Protocol: Security Best Practices
Canonical URL: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices - A2A Protocol: Agent2Agent (A2A) Protocol Specification
Canonical URL: https://a2a-protocol.org/v1.0.0/specification/ - A2A Protocol: A2A and MCP: Detailed Comparison
Canonical URL: https://a2a-protocol.org/v1.0.0/topics/a2a-and-mcp/ - A2A Protocol: Enterprise Implementation of A2A
Canonical URL: https://a2a-protocol.org/v1.0.0/topics/enterprise-ready/ - OpenTelemetry: Inside the LLM Call: GenAI Observability with OpenTelemetry
Canonical URL: https://opentelemetry.io/blog/2026/genai-observability/ - OpenTelemetry: OpenTelemetry GenAI Semantic Conventions
Canonical URL: https://github.com/open-telemetry/semantic-conventions-genai
TL;DR NVIDIA Triton Inference Server performance tuning is not a matter of enabling dynamic batching and increasing model instances until GPU utilization...