Agents are kernels of micro-autonomous intelligence which have the potential to complete a lot of intellectual and knowledge-based tasks. The key to enabling these agents to perform well is deep task specialization, along with having the context of that task and in-context learning. It’s important to recognize, however, that the most complex work is accomplished by ‘teams,’ not individuals. For teams to function effectively, collaboration and the right communication structure are crucial.

As humans, we’ve developed sophisticated baseline communication mechanisms in the knowledge work setup, including tickets, slack messages, in-person or remote meetings, delegations, check-ins, trackers, etc. These mechanisms facilitate meaningful collaboration for accomplishing complex tasks. A similar mechanism is missing when it comes to autonomous agents. These agents could become at least 1000x more productive if they had a suitable mechanism for interacting with their fellow agents.

All communication constructs incorporate semantic and syntactic protocols which lead to cohesive transfer and reception of encoded information. Take, for instance, binary or programming languages, which serve as effective means for humans to interact with computers. Another example is HTTP, the protocol that forms the basis for any data exchange on the Web, facilitating the transmission of hypermedia documents such as HTML. It’s a request-response protocol in the client-server computing model. Consider a web browser acting as a client while an application running on a computer hosting a webpage serves as the server. In this relationship, the client sends a request to the server, which returns a response. HTTP just gets the job done efficiently!

A similar protocol needs to exist for agents, one that isn’t restricted to mere data exchange but includes meaningful semantic transference or negotiation between intelligent agents. We propose AACP or the Agent-to-Agent Communication Protocol.


️ Key Components of AACP

The AACP can comprise the following components:

  1. Agent Identifier (AI): A globally unique identifier, like a UUID, for each agent in the network.
  2. Session Identifier (SI): A unique session identifier per interaction. This identifier is used to correlate requests and responses, especially useful in asynchronous communications.
  3. Action Code (AC): A unique code representing the action an agent wants to perform.
  4. Action Parameters (AP): A set of key-value pairs providing details necessary to perform the action. These could be data related to the action, identifiers, metadata, etc.
  5. Timestamp (TS): The time when the request/response was generated.
  6. Agent Context (CTX): The state or context of an agent at the time of generating a request. This could include its current status, sensor readings, etc.
  7. Payload (PL): Any additional data or message associated with the action.

Moreover, AACP should comprise of:

  • Multiplexing: Allows multiple requests and responses in a single session.
  • Retry Mechanism: If the agent doesn’t receive a response within a certain timeframe, it can resend the request.
  • Throttling: To prevent overloading any agent, there can be a mechanism to limit the number of requests an agent can make within a certain period.
  • Backward Compatibility: Ensures that new versions of the protocol work with older ones.


A Practical Example of AACP Interaction

Consider a scenario where the Master assigns a task to the Worker, which involves analyzing a specific data set and returning the results. An example request from the Master agent to the Worker agent could look like the following:

“AI”: “Master-UUID-001”,
“SI”: “Session-UUID-100”,
“TS”: “2023-06-09T14:30:15Z”,
“AC”: “TA”,
“AP”: {
“TaskID”: “Task-UUID-200”,
“DataSet”: “DataSet-UUID-300”
“CTX”: {
“CurrentTaskStatus”: “Idle”,
“LastTaskCompletionTime”: “2023-06-09T14:00:00Z”
“PL”: {
“AnalysisType”: “Deep Learning”,
“Model”: “Model-UUID-400”

‍ Implementing AACP Message Codes

In addition to the previously mentioned components, AACP should also establish shared message codes, similar to HTTP status codes like 404, 200, etc. These could include:

  1. Data Exchange (DE): The ‘AP’ carries data to be exchanged, and the ‘PL’ may include large data objects.
  2. Task Assignment (TA): The ‘AP’ specifies the task, and the ‘PL’ might contain additional task details.
  3. Capability Request (CR): The ‘AP’ specifies what capabilities are being inquired about.
  4. Status Query (SQ): The ‘AP’ comprises identifiers of tasks to check the status for.

Building a shared communication protocol as an open framework can significantly increase agent network productivity. Picture a scenario where a procurement agent from a company like SAP interacts with a new vendor’s sales agent, or your personal health agent communicates with a doctor. The possibilities are, indeed, exciting and limitless.