What to Log When Your Agents Start Calling Each Other
What changes when agents call each other
When your agents only call tools, a mistake stays inside your own system. When they start calling other agents, some of them owned by other companies, mistakes arrive from outside it.
That changes what you need to be able to find out afterwards.
The A2A protocol is the standard for those calls. It is at version 1.0.0 and is governed under the Linux Foundation rather than by a single vendor.
How one agent decides to trust another
Every A2A agent publishes an Agent Card: a short description of who it is and what it can do, kept at a predictable address, /.well-known/agent-card.json. Before handing over work, an agent reads the other one’s card.
Cards can be signed, so you can tell that one has not been altered. Read the rules in order, though:
- Signing it: “Agent Cards MAY be digitally signed using JSON Web Signature (JWS)”, the JWS being RFC 7515.
- Checking the signature: “Clients SHOULD verify at least one signature before trusting an Agent Card.”
- Formatting the bytes first: the content “MUST be canonicalized using the JSON Canonicalization Scheme (JCS)”, which is RFC 8785.
Permitted, advised, required. The strictest rule in the sequence is the one about text formatting.
Even a perfect signature proves less than it sounds like. It lets you “verify that an Agent Card has not been tampered with and originates from the claimed provider”. That is a genuine return address on a sealed envelope. It tells you who sent it. It tells you nothing about whether what is inside is safe.
So record enough to reconstruct it
If you cannot reliably stop a bad agent from being trusted, the useful question becomes a different one. After something goes wrong, what will you wish you had written down?
We find it helps to split that record by what it costs to keep.

The cheap part grows with the number of agents you deal with, so keep all of it. The expensive part grows with your traffic. The prompts themselves need a store of their own, because they hold whatever your users typed.
The last line of the figure is the one worth arguing hardest for. If every write to shared memory records what it was derived from, you can work out exactly what is contaminated when an agent turns out to be malicious. Without it, you have to distrust everything written since you started trusting that agent.
For the plumbing, the spec points at OpenTelemetry and W3C Trace Context. That is the right call because it is vendor-neutral: the same instrumentation exports to Amazon CloudWatch Logs, Azure Monitor Logs or Google Cloud Logging.
This is where we would start. It is not a standard, nobody has agreed one yet, and you may well decide parts of it cost more than they return.
Why the trail still breaks
Agents summarize. The instruction that reached the agent which finally acted is rarely the text that entered the system. It was shortened and reworded along the way. Searching for the original phrasing finds nothing, so each agent has to record what it received and what it passed on.
Shared memory hides the connection. When one agent writes something down and another reads it an hour later, nothing links the two. Tracing the chain of calls will never find that step. It has to be recorded at the moment of the write.
What this gets you
A short list of likely causes, and the ability to re-run the step and watch what happens. Not proof. The models are not repeatable enough for that.
That is usually enough to act on: revoke the credential, drop the agent, narrow what it is allowed to do. It is not enough to demonstrate to somebody outside who is entitled to ask how you know. Decide which of those two you need before you decide how much to keep.
