AACP and JSON: why not just use what already exists?

The obvious question

When I first described AACP to engineers, the first response was almost always a version of the same question.

"Why not just use JSON?"

It is a fair question. JSON is well understood, well tooled, supported everywhere, and already used extensively in agent frameworks for structured data. If the goal is structured, parseable coordination messages, it seems like the obvious choice.

I had to think carefully about this before I could answer it properly. The short answer is: JSON is excellent at what it does, and what it does is not quite the same thing AACP is trying to do.

What JSON is good at

JSON is a data serialisation format. It is designed to represent structured data clearly and portably. For payloads, results, configuration, and inter-service communication between well-defined endpoints, it is close to the ideal choice.

Most agent frameworks already use JSON extensively for exactly this. Tool call results come back as JSON. API responses are JSON. Configuration is JSON. That is correct and should not change.

The question is what happens at the coordination message layer, the instruction one agent sends to another. That is a different surface from a data payload. It is a directive, not a dataset.

What JSON looks like as a coordination message

You can write coordination messages in JSON. They would look something like this:

{
  "task": "FETCH",
  "domain": "HR",
  "return_to": "HR-Agent",
  "priority": 1,
  "protocol_version": "1.4",
  "resource": "emp_salary",
  "period": "2026-03",
  "filter": "status=active",
  "format": "json"
}

That is valid, parseable, and unambiguous. It solves the determinism problem. It is also 221 characters and nine lines to express what AACP encodes in 79 characters on one line:

FETCH|HR|return:HR-Agent|p:1|aacp:1.4|res:emp_salary|period:2026-03|filter:status=active|fmt:json

At a single message that difference is small. Across a 59-hop coordination workflow, it adds up. But that is not the main reason AACP is not JSON.

The schema verbosity problem

JSON coordination messages require a schema agreement between every pair of agents that communicate. If agent A needs to coordinate with agent B, both need to agree on the field names, the value formats, the required versus optional fields, and what to do with unknown fields.

In a system with many agents from different teams or different frameworks, this creates a proliferation of bespoke schemas. Some will call it return_to. Some will call it reply_agent or respond_to. Some will include priority, some will not bother. Some will use ISO date strings. Some will use Unix timestamps.

JSON does not specify any of this. It is a format, not a coordination vocabulary. Every team implementing JSON coordination has to define the vocabulary themselves, which means every integration is a custom one.

AACP defines the vocabulary. The field names, the valid TASK verbs, the domain codes, the version pinning, the handling of unknown keys: all of it is specified in the protocol. When two agents both implement AACP, they share a common vocabulary without a bespoke schema agreement between them.

What LLMs do with each format

There is a second consideration that is specific to LLM-based agents.

When an LLM receives a JSON coordination message, it has to parse it as text. JSON is readable by language models, but it is not particularly compact. The curly braces, quotation marks, commas, and nested structure all contribute to token consumption before any semantic content is reached.

AACP packets are designed to be parsed by both machines and LLMs. The pipe-delimited format is immediately readable. A model receiving:

FETCH|HR|return:HR-Agent|p:1|aacp:1.4|res:emp_salary|period:2026-03|filter:status=active|fmt:json

does not need to parse JSON structure before understanding the instruction. The verb is first. The domain is second. Everything else is named. The format is consistent across every packet the model has ever seen from this system.

Measured across a four-hop payroll workflow, AACP coordination tokens came in approximately 23% lower than equivalent JSON coordination messages on Claude Sonnet 4.5 and GPT-4o. That is a real but secondary benefit. The vocabulary standardisation is the more durable one.

Where JSON belongs in an AACP system

JSON and AACP are not competing in the same layer.

AACP packets carry the coordination directive. What to do, where to send the result, in what format, at what priority. The fmt:json field in the packet above is an instruction to return the result as JSON. The result itself comes back as JSON. That is correct.

FETCH|HR|return:HR-Agent|p:1|aacp:1.4|res:emp_salary|period:2026-03|filter:status=active|fmt:json

→ {"employees": [...], "period": "2026-03", "count": 147}

The coordination layer is AACP. The data layer is JSON. Both are doing what they are best at.

The honest case for JSON coordination

If your system is a closed, two-agent setup with a single team maintaining both agents, JSON coordination is probably fine. You control both ends. You can define whatever schema you want. You can enforce it internally. The overhead of a shared vocabulary standard is not worth it for a system that will never need to interoperate with anything outside itself.

AACP adds the most value when the agent system is larger, when agents come from different teams or frameworks, when workflows run repeatedly and need to produce identical coordination messages across runs, or when the coordination layer needs to be audited. In those conditions, a shared, specified vocabulary is worth more than the flexibility of defining your own JSON schema.

The third option: natural language

The comparison should probably include a third option, because that is what most agent frameworks default to today.

Natural language coordination is more flexible than either JSON or AACP. It handles novel situations gracefully. But it varies on every run, it costs an LLM call on every hop, it cannot be validated before transmission, and it produces an audit trail that is difficult to parse programmatically.

JSON coordination is structured and parseable, but requires per-system schema agreements and carries more tokens than necessary.

AACP coordination is structured, validated, vocabulary-standardised, token-efficient, and designed for LLM consumption specifically. The tradeoff is that it covers a defined set of task types and domains. Outside those, you fall back to LLM encoding, which adds cost on first use and serves from cache on subsequent runs.

No single approach is right for every system. The question is which tradeoff fits your actual workflow. The why-not-JSON page has the side-by-side comparison in more detail.