Agent2Agent Protocol: A new standard for agentic collaboration

A protocol that can reshape and revolutionise agentic workflows

Image by Author

The Internet era marked the emergence of standard network and software protocols, such as HTTP, GRPC, and others.

The AI era feels like we are entering a new dimension with unlimited possibilities built on and driven by intelligent systems.

The standard protocols were not designed with AI in mind, at least not as standalone protocols. However, when unified with others, we get some interesting results.

Our thoughts and actions might lag sometimes and fail to catch up with what is happening, but markets and technology never fall behind. At least that’s what we have witnessed so far.

A simple yet brutal reality about technology as we know it; evolve or become obsolete.

To keep up with the advancements in the GenAI domain, Anthropic has open-sourced the model context protocol (MCP), and its adoption rate is wild.

MCPs’ ability to share the context with models so that models can better consume the whole truth and generate accurate and up-to-date responses.

This might sound like RAG, but it is not. MCP even allows tool calling and other cool features, which are not in the scope of this post, so let’s stick to our topic.

Google has released a new protocol, the Agent2Agent protocol. This protocol is designed around the principle of agent communication.

Let’s dive in to understand how this protocol works and whether it’s mature enough for production yet.

How Agent2Agent Protocol Works

The protocol’s core principle is to let agents communicate without sharing their memories, thoughts, or tools. Instead, the protocol allows agents to share context, status, data, and instructions, irrespective of their modalities.

That sounds interesting, right? Yes.

Image by Author

In a nutshell, the Agent2Agent protocol works more or less like the master-slave protocol.

Look out for Kortecx, a unified agentic library for agentic workflow development and management at scale.

here’s the breakdown,

1. The user prompts the client agent on what needs to be done.

2. The client will search for remote agents exposing their capabilities via agent cards.

3. Agent cards hold metadata about remote agents.

Sample-Agent-Card
{
  "name": "Health Assistant Agent",
  "description": "Agent that provides general health information and tracks wellness goals.",
  "url": "https://agents.example.com/health-assistant",
  "provider": {
    "organization": "Wellness AI Co.",
    "url": "https://wellnessai.example.com"
  },
  "version": "0.9.5-beta",
  "documentationUrl": "https://docs.example.com/health-assistant",
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "track-habits",
      "name": "Track Habits",
      "description": "Tracks user habits like water intake, sleep, and exercise.",
      "tags": ["health", "tracking", "fitness"],
      "examples": ["Log 8 hours of sleep", "Track 2 liters of water today"]
    },
    {
      "id": "health-faq",
      "name": "Health FAQs",
      "description": "Answers general health-related questions based on public medical knowledge.",
      "tags": ["health", "information", "faq"],
      "examples": ["What are the symptoms of vitamin D deficiency?", "How much water should I drink daily?"]
    }
  ]
}

4. Now the client knows which remote agents are available and their dedicated functionalities. The client will send tasks to the remote agents.

5. Agent and client will stay in sync until the task is completed. If it is a long-running task, the client will keep polling the remote agent until the task completion. The remote agent will return the below responses to the client based on the task status.

   "submitted" | "working" | "input-required" | "completed" | "canceled" | "failed" | "unknown";

6. If completed successfully, the remote agent will send the artifact which is the response.

Artifact
{
  "name": "Daily Wellness Summary",
  "description": "A summary of tracked wellness activities for the user on 2025-04-10.",
  "parts": [
    {
      "type": "text/plain",
      "content": "Health Assistant Daily Summary for 2025-04-10:\n\n- Water Intake: 2.0 liters\n- Sleep Duration: 7.5 hours\n- Exercise: 30 minutes (Yoga)\n- Mood: Positive\n\nKeep up the great work! Don't forget to stretch and hydrate."
    }
  ],
  "metadata": {
    "date": "2025-04-10",
    "userId": "user-1234",
    "agent": "Health Assistant Agent",
    "goal": "habit-tracking",
    "tags": ["health", "summary", "daily", "wellness"]
  },
  "index": 0,
  "append": false,
  "lastChunk": true
}

7. The response is sent back to the user.

The client and remote agent communicate via messages. These messages are plain JSON objects holding metadata.

Message
{
  "role": "user",
  "parts": [
    {
      "type": "text/plain",
      "content": "Track that I drank 2 liters of water today and walked for 30 minutes."
    }
  ],
  "metadata": {
    "timestamp": "2025-04-10T10:15:00Z",
    "userId": "user-1234",
    "intent": "track-habits"
  }
}

There is one more concept called part, the actual content exchanged between a client and a remote agent as part of a Message or an Artifact.

Text-Part
{
  "type": "text",
  "text": "Log 7 hours of sleep and a 15-minute meditation session.",
  "metadata": {
    "timestamp": "2025-04-10T08:00:00Z",
    "source": "user-input",
    "context": "habit-tracking"
  }
}

This protocol is built on MCP for context sharing and agenting collaboration handling.

Push notifications and agent cards are a nice addition with enterprise-ready auth, security, privacy, tracing, and monitoring capabilities.

However, the protocol is under active development, and features will be refactored or deprecated based on user feedback.

We are in the early stages of exploration so let's keep our hopes closer to reality.

Keep exploring and experimenting.

Keep in touch and support me by leaving a like and comment.