Skip to main content

Command Palette

Search for a command to run...

Day 51: Why agents need a shared language

Why agents need shared message contracts before they can collaborate reliably.

Updated
3 min readView as Markdown
Day 51: Why agents need a shared language
V
I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

Inside one framework, agent communication feels free. Everything shares the same types, the same task model, the same assumptions about what "done" means.

The problem starts at the boundary, and the boundary is coming for everyone. A partner team's agent. A vendor's agent. The system built on a different stack two acquisitions ago. Suddenly nobody can hand over a task without a translator.

Four layers a real protocol has to pin down

  • Identity. Who is this agent, and on what basis do I trust it? An agent accepting tasks from anything that can reach its endpoint is a security problem waiting for a motivated party.
  • Capability. What can it actually do, stated machine-readably? Without this, task assignment is guesswork encoded in someone's config file.
  • Task state. Requested, accepted, in progress, done, failed, with both sides agreeing on the transitions and what triggers them.
  • Artifacts. How results get packaged, referenced, and verified. Passing a blob of prose and hoping the receiver parses it is not an interface.

This is exactly why standards like MCP and A2A exist: every team was reinventing these four layers, badly, in slightly incompatible ways.

The failure is semantic, not syntactic

Anyone who lived through enterprise systems integration already knows how this goes. The wire format was never the hard part. Agreement on meaning was.

Two agents can exchange flawless, schema-valid JSON while holding incompatible beliefs about what a field means. Does accepted mean "I will do this" or "I received your message"? Does confidence: 0.8 mean the same thing coming from a retrieval agent and a classifier? Does an empty result mean "nothing found" or "I could not check"?

Every one of those ambiguities becomes a production incident with a delay fuse: the system works fine until the case where the difference matters, and then it fails in a way that looks like neither agent misbehaved. Because neither did.

What to do about it

Negotiate semantics before traffic, not during the incident. Write down what each status value means, in prose, and have both teams confirm it.

Then version the protocol from day one. It will change, and unversioned protocol changes break integrations silently — the worst possible way for a contract to fail.

Closing thought

Agents need a shared language. The schema is the easy half; agreeing on what the words mean is the work, and it is the half that gets skipped because it looks like documentation rather than engineering.

Day 51 of 60 Days of Production AI Systems.

Are your agents genuinely interoperable, or just co-located in the same codebase?


Previous: Day 50: Why role design matters more than agent count
Next: Day 52: Why shared memory becomes a permission problem

Day 51 of 60 · Agent Coordination Contracts (chapter 9 of 10)

Agent Coordination Contracts

Part 3 of 6

A practical series on the contracts that let agents coordinate without chaos. It covers decentralized behavior, role design, shared communication, shared versus private memory, handoff payloads, and decision rules when agents disagree.

Up next

Day 52: Why shared memory becomes a permission problem

Why shared memory becomes an access-control problem in multi-agent systems.