Agent to Agent (a2a) Communication

[daveshap]

We will need to test and experiment with Agent to Agent (A2A)

• https://github.com/yoheinakajima/GPTvsGPT
• https://youtu.be/4o8tymMQ5GM?si=Y-QWERCgykxNOmYd

One of the key principles is the same that we use here: OPTIMIZE SIGNAL TO NOISE RATIO. We found the same thing in the ACE framework experiments. Attenuating noise is no. 1 problem.

Discuss, share results.

[daveshap]

https://twitter.com/SmokeAwayyy/status/1723151208549130349

[JoshRDFI]

I've been thinking on the agent to agent communication issue. One of the ideas I had was using MQTT as the protocol. Messages can be up to 256MB, comms can be secured, and sending JSON within the messages appears to work well. Additionally, QoS can be added in. This protocol would allow each agent to be both broker and recipient of messages. If there was a groups of agents, say 'copywriters,' those would all receive the message from the manager agent to write a product description. The manager would include the product details in JSON, each copywriter agent would generate their own description, sending it back to the manager.

Since each message can be an instruction, the agents would be able to collaborate on various tasks. All of the messages between agents can also be stored for review by a human. Any thoughts on taking this further?

[ben-AI-cybersec]

I've been doing some digging around, and while the protocol supports large messages, the cloud providers all charge by 4kb chunk.

I had a chat with one of my agents and it came up with the following alternatives, I'll go research:

AMQP (Advanced Message Queuing Protocol):

• An open standard application layer protocol designed for message-oriented middleware with a focus on queuing, routing (point-to-point, publish-and-subscribe), reliability and security.
• Providers like RabbitMQ offer a robust and reliable open-source AMQP broker. It's designed for high-throughput and can handle large messages. RabbitMQ can be run on your own server, reducing costs associated with cloud service message size limits.

ZeroMQ:

• A high-performance, asynchronous messaging library aimed at use in distributed or concurrent applications.
• ZeroMQ handles message transmission across a decentralized network of transports with sockets, providing a messaging queue without the need for a message broker.
• It's a brokerless design which means you don't have the overhead of an MQTT broker and no message size fees.

Apache Kafka:

• A high-throughput, distributed, publish-subscribe messaging system designed to handle data streams from multiple sources and distribute them to multiple consumers.
• Kafka is tailored for high-volume event streams and can be used to transport large data payloads efficiently.
• It is more complex than MQTT and AMQP but offers high performance and fault tolerance.

WebSockets:

• A protocol providing full-duplex communication channels over a single TCP connection.
• Suitable for real-time data exchange between clients and a server, and if combined with a broker similar to MQTT (like Socket.IO), it can be used to broadcast messages to multiple clients.
• While WebSockets themselves aren't message-oriented middleware, implementing a simple broker or using a library can achieve similar publish-subscribe capabilities.

gRPC:

• A high-performance, open-source and cross-platform framework by Google.
• Supports bi-directional streaming and is based on HTTP/2 protocol, enabling efficient connection overhead.
• It can be a good choice if you need to call remote procedures directly and pass complex data structures.

Restful APIs with Streaming:

• If you need to send large data blobs, and it's acceptable to do it over HTTP(s), consider using RESTful APIs with support for streaming the data.
• You could set up an HTTP server to accept large POST requests and stream data, avoiding the cost associated with the size of messages.

[daveshap]

Seems like people are consolidating around these clusters of technologies.

[ZacharyDK]

I agree. JSON is necessary for wrapping messages in a package. Either the model is told to output as a JSON, or converted into a JSON with the relevant fields. The model can be told to populate fields or the environment running the models can handle it. For example, a python script could be waiting to receive a message from the server, and then unpacks the JSON into a string that could be fed into a model. Then the model runs and outputs a string or a JSON which contains all the information necessary to send out the message.

Moreover, it is possible to force models to output in JSON. This has the effect of forcing the model to at least consider populating specific fields (like who to reply to) when returning a response. Sometimes models don't answer the question completely, and JSON structured replys can mitigate it.

[daveshap]

JSON is also going to be standard in OpenAI with "JSON-Mode" so we may as well standardize on JSON too.