Structuring Information in Agent Communications

Effective communication between agents, particularly those powered by Large Language Models, relies not just on the chosen transport protocol but critically on the content and structure of the information exchanged. An LLM might be proficient at understanding natural language, but in a multi-agent system, ambiguity in communication can lead to cascading errors, inefficient processing, and failed objectives. Methods for designing message structures that promote clarity, efficiency, and reliable interpretation by LLM agents are outlined.

Core Tenets of Message Design for LLM Agents

When agents communicate, especially when LLMs are involved in interpreting or generating messages, several principles guide the design of the information they exchange:

1. Clarity and Unambiguity: Each message must have a clear, singular interpretation. For LLM agents, this means structuring messages so that the intent and data are easily discernible. Avoid colloquialisms or language that might be misinterpreted, unless the system is specifically designed for such interactions with context handling. Prefer explicit commands and well-defined data fields.

2. Conciseness: LLMs have input token limits, and processing large amounts of text incurs latency and cost. Messages should be as concise as possible while still conveying all necessary information. This often involves using codes, identifiers, or structured data instead of verbose natural language for every piece of information.

3. Completeness: While conciseness is important, a message must contain all the information the recipient agent needs to perform its task or make a decision. Missing data can lead to follow-up requests, increasing communication overhead, or incorrect actions. Finding the right balance between conciseness and completeness is a significant aspect of message design.

4. Contextual Integrity: Agents, especially LLMs, often operate within a larger conversational or task context. Messages should carry identifiers (e.g., session_id, task_id, thread_id) that allow the recipient to situate the current message within an ongoing interaction. This helps LLMs maintain coherence and access relevant memory or historical data.

5. Actionability: A message should clearly signal what is expected of the recipient. Is it a request for information, an instruction to perform an action, a notification, or a response to a prior query? Explicitly defining the message's intent aids the receiving agent in routing the message to the correct internal logic or LLM prompt.

Common Message Structures and Formats

While plain text can be used, structured data formats are generally preferred for inter-agent communication due to their parseability and schema enforcement capabilities.

JSON (JavaScript Object Notation) is a prevalent choice due to its human readability, ease of parsing by machines, and wide support across programming languages. It's particularly well-suited for LLM-based systems because LLMs can be effectively prompted to both generate and interpret JSON-structured text.

Here's an example of a JSON message for assigning a task to an LLM agent:

{
  "message_id": "msg_f4a12c",
  "timestamp": "2024-08-15T14:22:05Z",
  "sender_agent_id": "orchestrator_main",
  "recipient_agent_id": "data_analysis_agent_03",
  "conversation_id": "conv_77b_alpha",
  "task_id": "task_901_beta",
  "intent": "PERFORM_DATA_ANALYSIS",
  "payload": {
    "data_source_uri": "s3://company-data-lake/raw_sales/2024_q2.csv",
    "analysis_type": "trend_identification",
    "parameters": {
      "time_period": "quarterly",
      "comparison_metric": "YoY_growth"
    },
    "output_requirements": "Generate a concise summary (max 200 words) and a list of important percentage changes. Return as JSON.",
    "priority": 1
  },
  "metadata": {
    "reply_to_topic": "results_data_analysis_agent_03"
  }
}

In this structure:

• Header Fields (message_id, timestamp, sender_agent_id, recipient_agent_id): Provide essential routing and tracking information.
• Contextual Identifiers (conversation_id, task_id): Link the message to broader workflows.
• Intent (PERFORM_DATA_ANALYSIS): Clearly states the purpose of the message. This can be a string from a predefined set of intents.
• Payload: Contains the actual data and instructions. Notice how output_requirements gives specific instructions to the LLM agent. Structured parameters make it easy for the agent to extract what it needs.
• Metadata (reply_to_topic, priority): Can guide routing of responses or task execution order.

Other Formats:

• XML (Extensible Markup Language): Though less common for new inter-service communication compared to JSON, XML is still used in some enterprise systems. Its verbosity can be a drawback for LLM token limits.
• Protocol Buffers (Protobuf) or Apache Avro: These are binary serialization formats that offer high performance and strict schema enforcement. They are excellent for high-throughput systems or when network bandwidth is a major concern. While LLMs don't directly parse binary formats, your agent's code would deserialize the Protobuf/Avro message into an internal object, and then relevant parts (often converted to text or JSON-like structures) would be passed to the LLM.

The following table illustrates the typical components found in a well-structured inter-agent message.

Component Group	Typical Elements & Purpose
Envelope/Header	Message ID, Sender ID, Recipient ID, Timestamp.<br>Ensures routing, uniqueness, and auditability.
Intent Specification	A clear verb or standardized code defining the message's purpose. (e.g., QUERY_DATABASE, EXECUTE_FUNCTION, NOTIFY_EVENT)<br>Directs agent's internal processing.
Contextual Identifiers	Task ID, Session ID, Conversation ID, Thread ID.<br>Links message to ongoing processes or histories.
Payload/Body	The core data or instructions. Often structured (e.g., JSON object).<br>May contain specific parameters for actions or natural language for LLM processing.<br>Provides the 'what' and 'how' for the agent.
Response/Error Handling	Status codes, error messages, correlation IDs for replies.<br>Facilitates two-way communication.

Components of a well-structured inter-agent message. Clarity in these areas is crucial for effective LLM agent collaboration.

Schema Definition and Validation

Regardless of the format chosen, defining a schema for your messages is a highly recommended practice. A schema formally describes the structure of your messages: what fields are expected, their data types, and whether they are mandatory or optional.

• For JSON, JSON Schema is a widely adopted standard.
• For Protobuf or Avro, the schema is an integral part of their definition language.

Benefits of using schemas:

1. Consistency: Ensures all agents send and expect messages in the same format.
2. Validation: Allows for automatic validation of incoming and outgoing messages, catching errors early.
3. Documentation: Schemas serve as clear documentation for message structures.
4. Code Generation: Some schema tools can generate boilerplate code for message handling.
5. LLM Guidance: For LLM agents, a schema (or a description of it) can be part of the prompt, guiding the LLM to generate responses that conform to the required structure. This significantly improves the reliability of LLM-generated structured data.

Designing Payloads for LLM Agent Interpretation

When an LLM agent is the recipient, the payload design requires special attention:

• Explicit Instructions within Payload: If the LLM needs to perform a specific task based on the message, embed clear, direct instructions within the payload. For instance, instead of just sending raw data, include a field like "instruction": "Summarize the following text for a non-technical audience."
• Separation of Data and Instructions: It's often useful to have distinct fields for raw data and for instructions pertaining to that data. This helps the LLM differentiate between content to be processed and meta-instructions about how to process it.
• Format Preferences: If the LLM agent is expected to generate a response in a specific format (e.g., JSON, Markdown, a list of bullet points), clearly specify this requirement in the message payload. Example: "requested_output_format": "json_array_of_strings".
• Providing Examples (Few-Shot Prompting via Message): For complex tasks or desired output formats, you can include a few examples (shots) within the message payload itself to guide the LLM's response generation. This is an application of few-shot prompting delivered through the communication channel.
• Token Economy: Be mindful of LLM token limits when designing payloads. If passing large documents, pass references (e.g., URIs, document IDs) that the agent can use to retrieve the content via a tool, rather than embedding the entire document in the message.

Semantic Consistency: Shared Understanding

Beyond syntactic structure, semantic consistency is important for reliable multi-agent systems. This means agents should have a shared understanding of the terms and concepts used in messages. For instance, if one agent sends a message with status: "completed", all other agents should interpret "completed" in the same way.

In complex systems, this might involve:

• Controlled Vocabularies: Using predefined sets of terms for certain fields (e.g., intents, status codes).
• Shared Ontologies (Advanced): For highly sophisticated systems, a formal ontology can define concepts and relationships, ensuring that different agents, potentially developed by different teams or using different underlying LLMs, have a common ground for interpreting information. While a full ontological approach is a significant undertaking, even a simpler, well-documented data dictionary for message fields can greatly reduce misunderstandings.

By thoughtfully structuring the information agents exchange, you lay a solid foundation for more complex interactions like shared awareness, negotiation, and collaborative problem-solving, which are explored in subsequent sections. Clear, unambiguous, and actionable messages are the foundation upon which effective multi-agent LLM systems are built.