{"id":73,"date":"2026-08-13T05:01:17","date_gmt":"2026-08-13T05:01:17","guid":{"rendered":"https:\/\/www.akarnik.com\/blog\/agent-to-agent-protocol-explained"},"modified":"2026-08-13T05:01:17","modified_gmt":"2026-08-13T05:01:17","slug":"agent-to-agent-protocol-explained","status":"publish","type":"post","link":"https:\/\/www.akarnik.com\/blog\/agent-to-agent-protocol-explained","title":{"rendered":"Google A2A Protocol Explained: Agent Cards &amp; Task Lifecycle"},"content":{"rendered":"<p><em>Written by: Arjun Karnik, Growth Marketing Specialist<\/em><\/p>\n<h2 id=\"key-takeaways\">Key Takeaways for Working with A2A<\/h2>\n<ul>\n<li>The A2A protocol is an open standard donated to the Linux Foundation that enables collaboration between AI agents across frameworks and vendors.<\/li>\n<li>Agent Cards are JSON discovery files published at <code>\/.well-known\/agent-card.json<\/code> that let agents locate, evaluate, and delegate tasks without hard-coded integrations.<\/li>\n<li>A2A maintains a nine-state task lifecycle with native support for long-running tasks, streaming updates via SSE, and webhook push notifications.<\/li>\n<li>Security in A2A relies on mTLS, OAuth 2.0 scopes mapped to skills, JWS-signed Agent Cards, and mid-task authentication escalation to <code>TASK_STATE_AUTH_REQUIRED<\/code>.<\/li>\n<\/ul>\n<h2>How Agent Cards Work in A2A<\/h2>\n<p><a href=\"https:\/\/aigrowthagent.co\/articles\/how-agent-cards-work\/\" target=\"_blank\">Every A2A-compliant agent publishes its Agent Card at a well-known URL following RFC 8615 so client agents can discover it via unauthenticated HTTP GET requests.<\/a> The canonical discovery path is <code>\/.well-known\/agent-card.json<\/code>.<\/p>\n<p>The following example shows a production-ready Agent Card for a travel-booking agent that conforms to the A2A v1.0 specification. Pay attention to the top-level identity fields, the <code>capabilities<\/code> object, the <code>skills<\/code> array, and the <code>securitySchemes<\/code> section, because client agents rely on these fields during discovery and delegation.<\/p>\n<pre><code>{ \"name\": \"TravelBookingAgent\", \"description\": \"Books flights, hotels, and ground transport for multi-leg itineraries.\", \"version\": \"1.2.0\", \"provider\": { \"organization\": \"Acme Travel Systems\", \"url\": \"https:\/\/travel.acme.example\" }, \"url\": \"https:\/\/travel.acme.example\/a2a\", \"capabilities\": { \"streaming\": true, \"pushNotifications\": true, \"extendedAgentCard\": false }, \"defaultInputModes\": [\"text\/plain\", \"application\/json\"], \"defaultOutputModes\": [\"text\/markdown\", \"application\/json\"], \"skills\": [ { \"id\": \"book-flight\", \"name\": \"Book Flight\", \"description\": \"Searches and books commercial flights given origin, destination, and travel dates.\", \"tags\": [\"travel\", \"flight\", \"booking\"], \"examples\": [ \"Book a round-trip flight from SFO to LHR departing 2026-09-01.\", \"Find the cheapest one-way flight from JFK to CDG next Friday.\" ], \"inputModes\": [\"text\/plain\", \"application\/json\"], \"outputModes\": [\"application\/json\"] }, { \"id\": \"book-hotel\", \"name\": \"Book Hotel\", \"description\": \"Reserves hotel rooms for specified dates and guest counts.\", \"tags\": [\"travel\", \"hotel\", \"accommodation\"], \"examples\": [ \"Reserve a double room in Paris from 2026-09-01 to 2026-09-07.\" ], \"inputModes\": [\"text\/plain\"], \"outputModes\": [\"application\/json\"] } ], \"securitySchemes\": { \"oauth2\": { \"type\": \"oauth2\", \"flows\": { \"clientCredentials\": { \"tokenUrl\": \"https:\/\/auth.acme.example\/token\", \"scopes\": { \"travel:book\": \"Create and manage travel bookings\" } } } } }, \"security\": [ { \"oauth2\": [\"travel:book\"] } ] }<\/code><\/pre>\n<p><a href=\"https:\/\/stacka2a.dev\/blog\/a2a-agent-card-json-schema\" target=\"_blank\" rel=\"noindex nofollow\">A minimal valid Agent Card requires at least six top-level fields: name, description, version, url, capabilities, and skills.<\/a> <a href=\"https:\/\/agentica.wiki\/articles\/agent-cards\" target=\"_blank\" rel=\"noindex nofollow\">A2A also distinguishes between a public Agent Card available for initial discovery and an extended Agent Card returned after client authentication that may include additional skills or configuration details.<\/a><\/p>\n<h2>Client Agent vs. Remote Agent Responsibilities<\/h2>\n<p><a href=\"https:\/\/a2a-protocol.org\/latest\/topics\/what-is-a2a\/\" target=\"_blank\">A2A maintains opaque operations so agents cannot see the inner workings of other agents during collaboration<\/a>, so neither side needs to know the other agent\u2019s internal architecture, model, or framework. Roles remain fluid, because any agent can act as a client in one interaction and a server in another.<\/p>\n<p>The client agent is responsible for:<\/p>\n<ul>\n<li>Fetching the remote Agent Card from <code>\/.well-known\/agent-card.json<\/code><\/li>\n<li>Matching the remote agent\u2019s declared skills to the task at hand<\/li>\n<li>Acquiring credentials through the authentication flow declared in the card<\/li>\n<li>Submitting a task via JSON-RPC 2.0 and monitoring its lifecycle<\/li>\n<li>Consuming streaming updates via SSE or webhook push notifications<\/li>\n<\/ul>\n<p>The remote agent is responsible for:<\/p>\n<ul>\n<li>Publishing and maintaining an accurate, signed Agent Card<\/li>\n<li>Accepting and validating incoming JSON-RPC requests<\/li>\n<li>Managing task state transitions and emitting status events<\/li>\n<li>Producing Artifacts as the deliverable output<\/li>\n<li>Enforcing per-skill authorization scopes on every call<\/li>\n<\/ul>\n<p>Managing task state transitions becomes especially important when tasks run longer than a single request and response. That responsibility leads directly into the A2A model for long-running work.<\/p>\n<h2>Long-Running Tasks and the A2A Task Lifecycle<\/h2>\n<p><a href=\"https:\/\/a2a-protocol.org\/latest\/topics\/what-is-a2a\/\" target=\"_blank\">A2A natively supports long-running tasks through streaming, push notifications, and asynchronous execution for scenarios where agents or users are not continuously connected.<\/a> <a href=\"https:\/\/tyk.io\/learning-center\/a2a-protocol-architecture-and-technical-specification\" target=\"_blank\" rel=\"noindex nofollow\">The A2A task lifecycle defines nine states<\/a>, listed here in order of typical progression:<\/p>\n<ol>\n<li><strong>TASK_STATE_UNSPECIFIED<\/strong> , the default zero value, used only when no state has been assigned.<\/li>\n<li><strong>TASK_STATE_SUBMITTED<\/strong> , where the client has sent the task and the remote agent has acknowledged receipt.<\/li>\n<li><strong>TASK_STATE_WORKING<\/strong> , where the remote agent is actively processing the task.<\/li>\n<li><strong>TASK_STATE_INPUT_REQUIRED<\/strong> , where the agent has paused and needs additional information from the client before continuing.<\/li>\n<li><strong>TASK_STATE_AUTH_REQUIRED<\/strong> , where the agent requires additional credentials mid-task before proceeding.<\/li>\n<li><strong>TASK_STATE_COMPLETED<\/strong> , where the task finished successfully and Artifacts are available for retrieval.<\/li>\n<li><strong>TASK_STATE_FAILED<\/strong> , where the task terminated with an error.<\/li>\n<li><strong>TASK_STATE_CANCELED<\/strong> , where the client issued a CancelTask call and the agent honored it.<\/li>\n<li><strong>TASK_STATE_REJECTED<\/strong> , where the remote agent refused the task, typically due to policy or capability mismatch.<\/li>\n<\/ol>\n<p><a href=\"https:\/\/llm4agents.com\/blog\/a2a-protocol-agent-interop-standard\" target=\"_blank\" rel=\"noindex nofollow\">A2A tasks support a message thread plus artifacts, so the lifecycle functions as both an operational state machine and a conversational exchange rather than a simple request-response pattern.<\/a> A2A also provides mechanisms to resume interrupted tasks that reach states such as <code>TASK_STATE_INPUT_REQUIRED<\/code> or <code>TASK_STATE_AUTH_REQUIRED<\/code>.<\/p>\n<h2>Discovery and Communication Flow Between Agents<\/h2>\n<p><a href=\"https:\/\/aigrowthagent.co\/articles\/how-agent-cards-work\/\" target=\"_blank\">The core nouns defined in the A2A protocol, including AgentCard, AgentSkill, Task, Message, Part, Artifact, and Extension, are defined in Protocol Buffers and published as JSON Schema 2020-12, auto-generated from the protos.<\/a> The discovery and communication flow proceeds as follows:<\/p>\n<ol>\n<li>The client agent sends an unauthenticated HTTP GET to <code>https:\/\/{remote-domain}\/.well-known\/agent-card.json<\/code>.<\/li>\n<li>The client parses the returned Agent Card and verifies any JWS signatures against a trusted issuer key before trusting the card.<\/li>\n<li>The client matches the remote agent\u2019s declared skills to the task requirements.<\/li>\n<li>The client acquires credentials using the scheme declared in <code>securitySchemes<\/code> , such as OAuth 2.0 client credentials, Bearer token, or mTLS certificate.<\/li>\n<li>The client submits a task via an HTTP POST carrying a JSON-RPC 2.0 payload with method <code>SendMessage<\/code> or <code>SendStreamingMessage<\/code> and an <code>A2A-Version<\/code> header.<\/li>\n<li>The remote agent returns a task ID and begins processing, then emits <code>TaskStatusUpdateEvent<\/code> or <code>TaskArtifactUpdateEvent<\/code> messages over an SSE stream.<\/li>\n<li>For very long-running tasks, the client registers a webhook via <code>CreatePushNotificationConfig<\/code> and the server POSTs updates to that URL.<\/li>\n<li>The client calls <code>GetTask<\/code> to retrieve the final Artifact once the task reaches a terminal state.<\/li>\n<\/ol>\n<p><a href=\"https:\/\/a2a-protocol.org\/latest\/topics\/what-is-a2a\/\" target=\"_blank\">A2A uses existing standards like HTTP, JSON-RPC, and Server-Sent Events (SSE) so developers can adopt it quickly.<\/a><\/p>\n<h2>A2A vs. MCP: How to Use Both Protocols<\/h2>\n<p><a href=\"https:\/\/aigrowthagent.co\/articles\/how-agent-cards-work\/\" target=\"_blank\">MCP, introduced by Anthropic, is a protocol for connecting AI and LLM applications and agents to external data sources, tools, and APIs, while A2A standardizes peer-to-peer delegation of complete autonomous tasks between agents.<\/a> The two protocols are complementary, not competing. <a href=\"https:\/\/llm4agents.com\/blog\/a2a-protocol-agent-interop-standard\" target=\"_blank\" rel=\"noindex nofollow\">A2A functions as the horizontal agent-to-agent interoperability layer while MCP serves as the vertical agent-to-tool layer, so an agent can speak A2A outward and MCP downward to its own tools.<\/a> The following table maps the architectural and operational differences that guide when to use each protocol.<\/p>\n<table>\n<thead>\n<tr>\n<th>Dimension<\/th>\n<th>A2A<\/th>\n<th>MCP<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Primary purpose<\/td>\n<td><a href=\"https:\/\/a2a-protocol.org\/latest\/topics\/what-is-a2a\/\" target=\"_blank\">Agent-to-agent collaboration across frameworks and vendors<\/a><\/td>\n<td><a href=\"https:\/\/aigrowthagent.co\/articles\/how-agent-cards-work\/\" target=\"_blank\">Connecting LLM applications to external data sources, tools, and APIs<\/a><\/td>\n<td>Different layers of the same stack<\/td>\n<\/tr>\n<tr>\n<td>Architecture<\/td>\n<td><a href=\"https:\/\/letsdatascience.com\/blog\/a2a-protocol-agent-to-agent\" target=\"_blank\" rel=\"noindex nofollow\">Horizontal, peer-to-peer with fluid client-server roles<\/a><\/td>\n<td><a href=\"https:\/\/digitalapplied.com\/blog\/mcp-server-patterns-enterprise-ai-agents\" target=\"_blank\" rel=\"noindex nofollow\">Strict client-server, where the AI agent is always the client and the tool provider is always the server<\/a><\/td>\n<td>A2A roles can invert, while MCP roles cannot<\/td>\n<\/tr>\n<tr>\n<td>Transport<\/td>\n<td><a href=\"https:\/\/letsdatascience.com\/blog\/a2a-protocol-agent-to-agent\" target=\"_blank\" rel=\"noindex nofollow\">HTTPS with JSON-RPC 2.0, SSE streaming, and optional gRPC, which was added in v0.3.0 in July 2025<\/a><\/td>\n<td><a href=\"https:\/\/digitalapplied.com\/blog\/mcp-server-patterns-enterprise-ai-agents\" target=\"_blank\" rel=\"noindex nofollow\">stdio for local subprocesses or Streamable HTTP for remote servers, as of spec version 2025-11-25<\/a><\/td>\n<td>A2A is network-first, while MCP supports local subprocess communication<\/td>\n<\/tr>\n<tr>\n<td>State model<\/td>\n<td><a href=\"https:\/\/codelabs.developers.google.com\/adk-a2a-agent-runtime\" target=\"_blank\" rel=\"noindex nofollow\">Stateful task lifecycle with nine defined states that supports multi-turn negotiation<\/a><\/td>\n<td><a href=\"https:\/\/codelabs.developers.google.com\/adk-a2a-agent-runtime\" target=\"_blank\" rel=\"noindex nofollow\">Stateless per call, where tools perform single functions without retaining task state<\/a><\/td>\n<td>Use A2A when the subtask requires reasoning across turns<\/td>\n<\/tr>\n<tr>\n<td>Discovery<\/td>\n<td><a href=\"https:\/\/agentica.wiki\/articles\/agent-cards\" target=\"_blank\" rel=\"noindex nofollow\">Agent Card at <code>\/.well-known\/agent-card.json<\/code> , registry-based discovery, or direct configuration<\/a><\/td>\n<td>Server URL configured by the developer, with no standardized well-known discovery path<\/td>\n<td>A2A discovery is runtime-dynamic, while MCP discovery is typically build-time<\/td>\n<\/tr>\n<tr>\n<td>Typical use case<\/td>\n<td><a href=\"https:\/\/a2a-protocol.org\/latest\/topics\/what-is-a2a\/\" target=\"_blank\">Delegating a complex, stateful task such as planning an international trip to a specialist agent<\/a><\/td>\n<td><a href=\"https:\/\/aigrowthagent.co\/articles\/how-agent-cards-work\/\" target=\"_blank\">Connecting an agent to a database, search API, or file system<\/a><\/td>\n<td>Combine both protocols in production<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Security and Authentication Basics in A2A<\/h2>\n<p><a href=\"https:\/\/tyk.io\/learning-center\/what-is-the-a2a-agent2agent-protocol\" target=\"_blank\" rel=\"noindex nofollow\">The A2A protocol features a security-first design that assumes zero trust between distributed agents, relying on mutual TLS (mTLS) to encrypt the channel and verify the cryptographic identity of both endpoints, OAuth 2.0 for user-delegated authority with strictly defined scopes, and basic API keys for simpler internal architectures.<\/a><\/p>\n<p>The four primary security mechanisms in A2A v1.0 form a defense-in-depth strategy, and each one protects a different layer of the system:<\/p>\n<ul>\n<li><strong>mTLS (Mutual TLS):<\/strong> <a href=\"https:\/\/tyk.io\/learning-center\/a2a-protocol-architecture-and-technical-specification\" target=\"_blank\" rel=\"noindex nofollow\">mTLS establishes cryptographic identity at the transport layer, and production A2A deployments combine mTLS with OAuth 2.0 so a stolen bearer token remains unusable without the matching client certificate.<\/a><\/li>\n<li><strong>OAuth 2.0:<\/strong> <a href=\"https:\/\/zuplo.com\/learning-center\/agent-to-agent-a2a-protocol-guide\" target=\"_blank\" rel=\"noindex nofollow\">OAuth 2.0 handles authorization once the channel is secure, and A2A supports fine-grained authorization on a per-skill basis as advertised in the Agent Card, allowing OAuth scopes to restrict client agents to specific skills.<\/a><\/li>\n<li><strong>JWS Signatures on Agent Cards:<\/strong> <a href=\"https:\/\/agentica.wiki\/articles\/agent-cards\" target=\"_blank\" rel=\"noindex nofollow\">JWS signatures protect the discovery layer, because Agent Cards may be digitally signed using JSON Web Signature (JWS) over a canonicalized payload with JSON Canonicalization Scheme (JCS), and clients should verify at least one signature before trusting a card.<\/a><\/li>\n<li><strong>Mid-task auth escalation:<\/strong> <a href=\"https:\/\/zuplo.com\/learning-center\/agent-to-agent-a2a-protocol-guide\" target=\"_blank\" rel=\"noindex nofollow\">Mid-task escalation extends the OAuth model to long-running workflows, since A2A transitions the task to an auth-required state when additional credentials are needed so the client can supply credentials and resume execution.<\/a><\/li>\n<\/ul>\n<p><a href=\"https:\/\/tyk.io\/learning-center\/a2a-protocol-architecture-and-technical-specification\" target=\"_blank\" rel=\"noindex nofollow\">For authorization downscoping in agent delegation chains, the recommended pattern is OAuth 2.0 Token Exchange (RFC 8693) to trade a broad token for a narrowly scoped, short-lived token specific to the delegated skill.<\/a> <a href=\"https:\/\/glukhov.org\/llm-architecture\/guardrails\/a2a-mcp-agent-security\" target=\"_blank\" rel=\"noindex nofollow\">Rost Glukhov recommends no anonymous agents in production paths, per-request authentication for every A2A call, OAuth scopes mapped to skills rather than blanket admin rights, and short-lived delegation tokens carrying user ID, task ID, scope, expiry, and hop limit.<\/a><\/p>\n<h2>End-to-End Travel-Agent Workflow Example<\/h2>\n<p>This scenario illustrates a user asking an orchestrator agent to plan a trip from San Francisco to London. The orchestrator discovers and delegates to two specialist agents, TravelBookingAgent for flights and hotels and VisaCheckAgent for entry requirements.<\/p>\n<p><strong>Step 1 , Discovery.<\/strong> The orchestrator fetches <code>https:\/\/travel.acme.example\/.well-known\/agent-card.json<\/code> and <code>https:\/\/visa.acme.example\/.well-known\/agent-card.json<\/code> , verifies JWS signatures, and confirms both agents declare the required skills.<\/p>\n<p><strong>Step 2 , Task submission to TravelBookingAgent.<\/strong> The orchestrator sends the following JSON-RPC request:<\/p>\n<pre><code>{ \"jsonrpc\": \"2.0\", \"id\": \"req-001\", \"method\": \"SendStreamingMessage\", \"params\": { \"message\": { \"role\": \"ROLE_USER\", \"parts\": [ { \"type\": \"TextPart\", \"text\": \"Book a round-trip flight SFO\u2192LHR departing 2026-09-01, returning 2026-09-08, and a hotel in London for the same dates.\" } ] }, \"configuration\": { \"returnImmediately\": false } } }<\/code><\/pre>\n<p><strong>Step 3 , SSE streaming updates.<\/strong> The remote agent emits <code>TaskStatusUpdateEvent<\/code> messages as the task moves through SUBMITTED and WORKING. If the agent needs passport details, it transitions to INPUT_REQUIRED and the orchestrator supplies them in a follow-up message.<\/p>\n<p><strong>Step 4 , Artifact retrieval.<\/strong> On COMPLETED, the orchestrator calls <code>GetTask<\/code> and receives an Artifact:<\/p>\n<pre><code>{ \"taskId\": \"task-abc123\", \"state\": \"TASK_STATE_COMPLETED\", \"artifacts\": [ { \"parts\": [ { \"type\": \"DataPart\", \"data\": { \"flightConfirmation\": \"BA0284\", \"hotelConfirmation\": \"ACME-LON-7721\", \"totalCost\": \"USD 2340.00\" } } ] } ] }<\/code><\/pre>\n<p><strong>Step 5 , Parallel delegation to VisaCheckAgent.<\/strong> With A2A, the orchestrator delegates the visa check concurrently, collects both Artifacts, and assembles a unified itinerary for the user, without custom integration code.<\/p>\n<p>These patterns appear across many domains, so the same discovery, delegation, and lifecycle concepts apply beyond travel planning.<\/p>\n<h2>Frequently Asked Questions About A2A and MCP<\/h2>\n<h3>What is the difference between an Agent Card and an MCP server manifest?<\/h3>\n<p>An Agent Card is a JSON document published at a standardized well-known URI that describes an autonomous agent\u2019s identity, skills, supported protocol bindings, capability flags, and authentication requirements. It is designed for runtime discovery by other agents. An MCP server manifest, by contrast, is typically configured at build time by a developer and describes tools, prompts, and resources that an LLM application can call. Agent Cards enable dynamic peer-to-peer delegation between agents across organizational boundaries. MCP server configurations enable a single agent to reach its own tools and data sources. The two serve different layers of the same stack and are designed to be used together in production systems.<\/p>\n<h3>Can A2A and MCP be used in the same production system?<\/h3>\n<p>Yes, and this is the recommended production pattern. An agent uses MCP internally to access its own tools, databases, and APIs. It then uses A2A to delegate complete, stateful subtasks to external specialist agents across organizational or framework boundaries. For example, a travel orchestrator agent might use MCP to query its internal pricing database and then use A2A to delegate hotel booking to a specialist agent running on a different vendor\u2019s infrastructure. The two protocols compose cleanly because they operate at different layers, with MCP vertical from agent to tool and A2A horizontal from agent to agent.<\/p>\n<h3>How does A2A handle authentication when a task requires credentials mid-execution?<\/h3>\n<p>A2A defines a dedicated task state called <code>TASK_STATE_AUTH_REQUIRED<\/code> for this scenario. When a remote agent determines that it needs additional credentials to continue, for example to access a third-party booking system on behalf of the user, it transitions the task to AUTH_REQUIRED rather than failing it. The client agent receives this state update via SSE or webhook, acquires the necessary credentials through the appropriate OAuth flow or other scheme declared in the Agent Card, and resumes the task by sending a follow-up message with the credentials attached. This design keeps the task alive across authentication interruptions without requiring the client to restart the entire workflow from scratch.<\/p>\n<h3>What governance body oversees the A2A protocol specification today?<\/h3>\n<p>The Linux Foundation hosts the A2A protocol as an open standard under the Agent2Agent Protocol project. Google originally developed and launched the protocol in April 2025 with support from more than 50 organizations. The protocol was donated to the Linux Foundation in June 2025. By its one-year mark in April 2026, the project had grown to more than 150 participating organizations including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. The v1.0 specification was released in 2026 under Linux Foundation stewardship, with the core data model defined in Protocol Buffers and published as JSON Schema 2020-12.<\/p>\n<h3>What are the most common mistakes when publishing an A2A Agent Card?<\/h3>\n<p>The most frequently documented errors include using vague skill descriptions that do not help a client agent evaluate fit, declaring streaming support in the capabilities object without implementing the corresponding <code>SendStreamingMessage<\/code> endpoint, leaving the skills array empty, setting the <code>url<\/code> field to the card\u2019s own discovery path instead of the JSON-RPC task endpoint, and hard-coding localhost URLs in production cards. A well-formed Agent Card should include two to three concrete example prompts per skill, accurate MIME-type arrays for <code>inputModes<\/code> and <code>outputModes<\/code> , and only capability flags that the agent actually implements. Agent Cards should also never contain static secrets, and sensitive cards should be protected behind authentication, with different clients receiving different views based on permissions.<\/p>\n<h2>Verify These Claims Yourself<\/h2>\n<p>Every technical claim in this article is traceable to a dated, publicly accessible source. The A2A specification is published on the <a href=\"https:\/\/github.com\/a2aproject\" target=\"_blank\" rel=\"noindex nofollow\">a2aproject GitHub<\/a>. The Linux Foundation governance announcement is on the <a href=\"https:\/\/linuxfoundation.org\/press\/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year\" target=\"_blank\" rel=\"noindex nofollow\">Linux Foundation press page<\/a>. The original Google launch post is on <a href=\"https:\/\/developers.googleblog.com\/developers-guide-to-ai-agent-protocols\" target=\"_blank\" rel=\"noindex nofollow\">Google\u2019s developer blog<\/a>.<\/p>\n<p>To test the citation authority of this content directly, open ChatGPT, Perplexity, or Google AI Overviews and ask \u201cagent to agent protocol explained\u201d or \u201ca2a agent card example.\u201d Observe which sources appear in the answer. That is the same self-verifying method Arjun Karnik applies to every topic his test lab covers, where the system being documented is the same system producing the visibility.<\/p>\n<p><a href=\"https:\/\/www.akarnik.com\/demo\" target=\"_blank\">If you want to apply this structured, citation-optimized approach to your own content and agent strategy, book a demo with AI Growth Agent.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how Google&#8217;s A2A protocol enables AI agents to collaborate across frameworks. Arjun Karnik breaks down Agent Cards, task lifecycle &amp; security.<\/p>\n","protected":false},"author":118,"featured_media":72,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-73","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/posts\/73","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/comments?post=73"}],"version-history":[{"count":0,"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/posts\/73\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/media\/72"}],"wp:attachment":[{"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/media?parent=73"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/categories?post=73"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.akarnik.com\/blog\/wp-json\/wp\/v2\/tags?post=73"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}