Communication between two local agents - how?

[lrosenthol]

In the diagram on the A2A main page (https://a2a-protocol.org/latest/#a2a-and-mcp-complementary-protocols) it shows a section called "local agents", which I take to mean a series of agents all deployed on the same system. And it shows how two separate systems of agents talk between themselves using A2A.

My question is what if two agents running on the same system - perhaps even a single (disconnected/offline!) device - want to talk to each other. Is A2A the correct solution (using localhost as the endpoint), or is there some other approach that is commonly used?

[darrelmiller]

One of the advantages of using HTTPS as the underlying protocol for all the A2A transports and a URL for the Agent identifier is that it provides location independence. Two agents can communicate if they are on the same machine or if they are continents away. The one exception here is the use of .well-known as the agent card discovery mechanism. It is currently not possible to have two agents on the same logical host name. However, use of .well-known is optional.

[lrosenthol]

@darrelmiller All of that is true in the larger server-side context of agents....But thinking about how local device agents will operate, I think it introduces more problems than it solves.

• Each agent will need to expose an https server on some arbitrary port number, which is now open on that device for ANYONE (e.g., bad actor) to go after. Additionally, those agents will have to deal with port conflicts, which leads us to...
• How do you register an agent for discovery on a device, since as you note, .well-known won't work? And how can you do it, if you don't know the available port until you start it up? Looks like this one already has an open issue tracking it - [Feat]: Agent automatic discovery (on local machine / k8s) #378
• HTTPS for localhost doesn't work well in many cases, since the common solution is to use a self-signed cert...but what you really want is a cert specific to that agent's "owner" (just as you have for the web-server case).