Agent-to-Agent Communication: Time for Agentic Patterns

The days of writing single, standalone agents “being intelligent at one task” is probably past. Evolution is now shifting towards enabling communication between the agents so that bigger and complex problems can be solved using AI. This paradigm shift has given rise to agentic patterns – standardized approaches for enabling AI agents to discover, communicate, and coordinate with each other across different frameworks and platforms. This article focuses on 3 such frameworks available as of today.

Three major frameworks:

1. OpenAI's Agents SDK focuses on multi-agent workflows with primitives like Agents, Handoffs, and Guardrails. The SDK enables developers to create specialized agents that can delegate tasks through structured handoffs, allowing for modular systems where each agent excels at specific tasks while seamlessly coordinating through standardized interfaces.

2. IBM's Agent Communication Protocol (ACP) is an open standard for agent-to-agent communication that transforms our current landscape of siloed agents into interoperable agentic systems. Built on JSON-RPC over HTTP, ACP provides a lightweight framework for agents to discover, authenticate, and cooperate without requiring custom integration code.

3. Google's Agent2Agent (A2A) protocol represents a new, open protocol with support and contributions from more than 50 technology partners including Atlassian, Salesforce, and MongoDB. A2A lets agents "communicate with each other, securely exchange information, and coordinate actions" across different platforms as autonomous peers rather than mere tools.

Each Agents to Agents frameworks listed above are solving the communication between agents problem in different ways. This article is not focussed on these frameworks per se. Rather this article identifies that all these frameworks have something in common as “agentic-patterns” to them.

Agentic Patterns

Sequential Workflows

This is the standard problem solving approach. The problem to solve is broken down into smaller steps and in sequence. For example, I have a simple travel booking system of 3 agents, one that takes user preferences, another that looks up various websites based on the input and the third that sorts and plans based on the search results. Straight forward, deterministic flow here. A —> B —> C and done.

Hierarchical Delegation

Router agents that distribute tasks to domain-specific sub-agents. This is a classic multi-agent like problem to solve. The workflow is not decided or hardcoded in the program code. For example, a calculator, implemented in the AI world, will have few different agents that specialise say in calculus, mensuration and converting NL based problems to algebraic expressions. There then is a need to a “Router/Triage/Ingress Agent” that will based on the nature of the problem input, route the requests to the appropriate agent. Note that it is possible that the Triage Agent runs a loop and delegates the requests a multiple times (steps) to different or same agents, as needed to solve the initial problem. Such a pattern when implemented is extremely flexible and robust, since the actual calling of the agents is not hardcoded. It easy to plugin a new Agent (means a new capability in the system) without impacting existing flows (unlike in traditional programming structures)

Parallel Processing

Multiple agents working simultaneously on independent subtasks. This is for use cases where a task can be broken into smaller steps and some or of the steps can be run in parallel. The most classic example in this case, is the translation agents, where each agent specialises in one particular language. So then when a task is to translate to multiple languages, it is possible to invoke the run() of each of these agents simultaneously and then keep a track of all of them finishing up before dispatching the final result. The code in this pattern, will need to implement some sort of a “join()” mechanism to “wait” for all agents to finish.

Iterative Improvement

Agents providing feedback to enhance each other's outputs. This pattern I found a little different across the frameworks. Essentially, it is about one agent producing and output and another agent “correcting” it and then sending it back again for an “improved” version. Generally, the first model is a “weaker” or “cheaper” model whereas the “judging” model is a superior model. So while we use superior model as a “judge”, we can iterate the “weaker” model to produce better and better responses in each iteration or step.

Having explored few of the agentic patterns I found common across agentic frameworks described above, I am very sure that things will evolve in the future. There will be more use cases, changes in the implementation of the agents and more robust frameworks and interoperability between different frameworks. Interesting times ahead!