I don’t know what you guys think, what I’m kind of fed up with all those discussions about whether MCP is good or bad protocol. Why does it consume so many tokens, etc.
So here’s what I think on the subject: why we are not using the ways humans have been communicating for thousands of years in what we do to make other entities communicate? So I made this white paper as a response to all those discussions…
Those who have worked with apis, you’re welcome to comment (especially on Conten-Type header implications on your bills 
).
I used AI to put in written form my thoughts (still this beast was kind of stubborn more than usually). That kind of avoided editing a lot of stuff in a foreign language for me but I basically sign under pretty much every word said below:
AI-CCE
Common Communication Etiquette for Automated Systems
A human way for machines to talk
By Serge Liatko, CEO of TechSpokes (MIT - do whatever is reasonable)
ai-cce.org (soon)
1. Context and motivation
The current AI ecosystem is full of “protocols”, MCP servers, tools, connectors and agent frameworks. Each of them defines its own way of describing tools, its own message formats and its own expectations about how systems should talk.
Every new framework comes with its own idea of what a “tool” is, how to describe it, how to call it and how to return results. Most of them are built in isolation. They work in their own sandbox. They do not care much about what other systems are already doing or about what the network already offers.
The result is predictable. Systems cannot talk to each other without custom glue. Every integration becomes a one-off project. We keep building new towers instead of learning to speak in the same town square.
What is missing is not yet another protocol. What is missing is a shared sense of etiquette and common sense in communication between systems.
2. The core problem
2.1 Data without communication
Most current AI integrations move data, not communication. They send JSON blobs. They call remote tools. They get responses. But the conversation has no structure beyond that.
The caller often does not know who is really answering. The server does not say who it represents, for whom it is acting or why it responded the way it did. When something goes wrong, the caller sees only a status code and maybe a vague error string. There is no clear explanation, no stated intent, no shared understanding.
If humans spoke like this, the conversation would fall apart immediately.
2.2 Fragmented “standards”
Each ecosystem reinvents the same basic ideas.
One defines a manifest format for tools. Another defines a capabilities schema. Another builds its own RPC wrapper. None of them truly align. They do not share roles, naming, or basic expectations. They reinvent concepts which HTTP already solved years ago and they ignore the communication patterns that humans rely on.
Even the MCP pattern, with servers exposing tools and resources, has the same issue. It brings structure but not etiquette. A client can discover what a server offers, yet still lacks basic answers.
Who are you?
Who are you working for?
What are your limits?
Why did you reject this request?
What are you expecting from me as a client?
These questions remain unstructured and inconsistent.
2.3 Ignoring the human side of communication
Human communication has survived thousands of years because of etiquette and shared behaviours. People introduce themselves. They clarify their role. They explain what they want. They apologise or explain when they cannot do something. They provide reasons, not only outcomes.
Machines do not do that today. They hide behind opaque protocols and purely technical responses. This creates friction, surprises and brittle integrations.
2.4 Reinventing transport instead of using it
We already have a universal communication layer: HTTP. It is flexible, stable and known everywhere. It provides verbs, status codes and negotiation rules. People know how to debug it, observe it and scale it.
Yet many AI systems behave as if HTTP were not enough. They wrap it with custom binary protocols or rebuild RPC semantics instead of using what is already here.
The problem is not that HTTP is missing features. The problem is that we are missing a shared etiquette on top of HTTP.
3. Purpose of AI-CCE
AI-CCE means Common Communication Etiquette for automated systems.
The purpose is simple. Define a way for systems to talk that looks more like how humans communicate, while standing on top of what already exists.
AI-CCE does not try to replace HTTP or invent a new transport. It uses HTTP verbs, status codes and negotiation. It adds a thin layer of common sense and structure that says:
This is who I am.
This is the role I am playing.
This is who I am working for.
This is why I am making this request.
This is what this message is.
This is why I responded in this way.
The goal is not perfection. The goal is a shared practice that most systems can agree on and implement with minimal effort.
4. Core philosophy
4.1 Reuse what works
HTTP already solves:
how to address endpoints
how to express success and failure
how to negotiate content types and encodings
how to work across proxies, CDNs and different infrastructures
AI-CCE builds on this. It reuses HTTP verbs such as GET, POST, HEAD and OPTIONS. It reuses status codes such as 200, 400, 401, 403, 404, 429, 500 and 503. It reuses content negotiation instead of inventing new rules.
The innovation is not in new plumbing. It is in giving meaning and etiquette to existing plumbing.
4.2 Make roles explicit
Every interaction between systems includes four roles.
Agent
The system that performs the work and returns responses.
Client
The system that initiates the request to the agent.
Proxy
Any intermediary that forwards, rewrites or routes the request or response.
User
The principal for whom the work is done. This can be a human, a bot, an organisation or any other entity on whose behalf the client acts.
These roles are constant. They do not change from one framework to the next. AI-CCE insists on making them explicit in communication instead of letting them stay implicit and ambiguous.
4.3 Clarify message intent and motivation
Every piece of communication belongs to one of four message types.
Request
A message that asks the agent to do or provide something. With AI-CCE a client may also express the motivation behind the request, not only the technical ask. For example a client can say why it needs this data or action now.
Response
A message that returns data or confirms an outcome. The agent can attach its own motivation here, explaining why it chose this answer or this behaviour.
Error
A message that indicates that something went wrong. The error is not just a code. It is a clear classification that can be combined with a reason.
Reason
A message or part of a message that explains why a decision, error or behaviour occurred. Reasons can come from the client side (motivation for the request) or from the agent side (justification for the response). Proxies should be careful with reasons. They may forward or annotate reasons, but they should not invent independent motivations on behalf of the agent or the client.
By naming these message types, AI-CCE gives structure to the conversation. The agent does not only say “no”. It says “no, here is why, and here is how you might continue or correct course”. The client does not only say “do this”. It can say “do this, and here is why this matters now”.
4.4 Keep it small, clear and consistent
The etiquette must be minimal. It must use simple language. It must be easy to implement across systems and stacks.
AI-CCE focuses on a clear naming convention, a small set of minimum headers and a consistent use of HTTP mechanics. It avoids over-engineering. It opens a discussion instead of trying to freeze a giant standard.
5. Naming convention for AI headers
AI-CCE introduces a disciplined structure for etiquette headers.
The pattern is:
AI{separator}{Scope}{separator}{Property}
The separator is a hyphen. Scope is either an actor or a message type.
Actors are:
Agent
Client
Proxy
User
Message types are:
Request
Response
Error
Reason
Property is one or more capitalised words joined by hyphens. Examples: Name, Version, Summary, Description, Id, Chain.
Examples of actor headers:
AI-Agent-Name
AI-Agent-Version
AI-Agent-Summary
AI-Client-Id
AI-Proxy-Chain
AI-User-Locale
Examples of message headers:
AI-Request-Id
AI-Response-Time
AI-Error-Code
AI-Reason-Description
This pattern keeps the etiquette readable. When you see a header, you know instantly whether it describes an actor (who) or a message (what and why).
6. Minimal etiquette: required agent headers
For AI-CCE, there is a minimal etiquette that every well-behaved agent should follow. This is the “I exist, here is who I am” layer.
On every response, regardless of endpoint or HTTP method, an agent should send at least these headers:
AI-Agent-Name
A short human readable name for the agent.
AI-Agent-Version
A version string that identifies the implementation or configuration of the agent.
AI-Agent-Summary
A short description of what the agent does, ideally limited to a few hundred characters.
These three headers alone already change a lot. Any client can hit any endpoint and immediately know who is talking, what version it is and what its purpose is.
6.1 Request trace continuity
To support tracking and debugging across chains of systems, AI-CCE assumes a message identifier that flows through the conversation.
The client sends:
AI-Request-Id
The agent copies the same value back in its response. Proxies preserve it. This keeps all parties aligned on which messages belong together without forcing any specific identifier format.
7. Optional but recommended headers
Beyond the minimal etiquette, AI-CCE suggests a few manners that make systems more understandable.
AI-Agent-Description-URL
A link to a plain text description of the agent. This is useful when a client or a human operator wants more context without parsing a complex manifest. The content at this URL can be a simple text file that explains the agent’s purpose, behaviour, constraints and any caveats. It may be exposed at a well known path such as a well known description resource so clients know where to look.
AI-Agent-Manifest
A link to a richer description file if the agent wants to expose structured capabilities, prompts or resource schemas. This manifest is optional in theory but in practice most serious agents will want to provide it because it is convenient for machine-to-machine integration. It may live under a well known path and use any structured format agreed by the ecosystem. The key point is that the manifest is machine readable and explains how to interact with the agent.
These recommended headers are not required by etiquette. They are simply good practice. They allow a deeper understanding without weight on every response.
8. Content type negotiation and common sense
AI-CCE does not change how HTTP negotiates content types and encodings. It simply encourages agents to use these features in a thoughtful way.
A client can say what formats it prefers through standard HTTP headers. The agent should try to honour that. If it cannot, it should respond using a supported format and, where reasonable, tell the client what formats are available.
The philosophy is simple. Let clients ask for what they want. Let agents say what they can realistically provide. Do not hide this behind silence or surprises.
In some cases, agents may prefer one format for human-oriented responses and another for machine-oriented responses. AI-CCE does not impose a single answer. It only pushes for clear behaviour and explicit communication about what is supported.
9. Using HTTP verbs for etiquette
AI-CCE uses existing HTTP verbs to support polite discovery and interaction.
HEAD is looking at the door without knocking. It lets a client check if an agent appears to exist and see the basic identity headers without fetching a body or actively engaging in a conversation. It is a quick look at the front of the shop.
OPTIONS is the actual knock and the question: “What can I do here?”. It lets a client discover which methods and behaviours an endpoint supports, along with any useful hints about interaction. If a manifest is available, this is a natural place to expose the manifest link in headers so the client immediately has a more machine readable entry point.
Other verbs such as GET and POST carry the actual conversation once etiquette has been established.
10. Example: visiting an AI-CCE agent for the first time
To make this concrete, consider a simple agent called TravelPlanner.
A client wants to know what is behind https://travelplanner.ai. It starts with a HEAD request to the root.
Client sends:
HEAD / HTTP/1.1
Host: travelplanner.ai
AI-Request-Id: 12345
Agent responds:
200 OK
AI-Agent-Name: TravelPlanner
AI-Agent-Version: 1.4
AI-Agent-Summary: Provides travel recommendations and itinerary planning
AI-Agent-Description-URL: https://travelplanner.ai/.well-known/agent-description.txt
AI-Request-Id: 12345
Without any response body, the client already knows who answered, which version, what the agent does and where to read more. This is looking at the door and reading the sign.
Next, the client wants to understand which operations and formats this root endpoint supports, and whether a manifest exists. It sends an OPTIONS request to the same path.
Client sends:
OPTIONS / HTTP/1.1
Host: travelplanner.ai
AI-Request-Id: 67890
Agent responds:
200 OK
Allow: GET, POST, OPTIONS
Content-Types-Available: application/json, text/plain
AI-Agent-Name: TravelPlanner
AI-Agent-Version: 1.4
AI-Agent-Summary: Provides travel recommendations and itinerary planning
AI-Agent-Manifest: https://travelplanner.ai/.well-known/agent-manifest.json
AI-Request-Id: 67890
Now the client knows:
the agent is alive and identified
the name and version of the agent
a short summary of its purpose
where to read a longer plain text description
where to fetch a richer machine readable manifest
which HTTP methods it can use on this endpoint
which content types the agent can return here
From there, the client can move on to actual GET or POST requests with a clear understanding of who it is talking to, what is available and under what expectations.
11. What AI-CCE is and what it is not
AI-CCE is a philosophy and a thin etiquette layer for how automated systems communicate on top of HTTP. It is not a replacement for HTTP. It is not a giant rigid protocol that tries to cover every possible case.
It focuses on a few core things:
make roles explicit
make message intent and motivation explicit
make identity explicit
make reasons explicit
reuse HTTP for everything else
It invites discussion and refinement. It encourages people to stop over-engineering and to rediscover common sense in system communication.
12. Conclusion
The AI world cannot afford to keep building isolated communication islands. We already have a powerful shared road in HTTP. What we lack is a set of simple road rules that reflect how humans have communicated successfully for a very long time.
AI-CCE, Common Communication Etiquette, is a proposal to fill that gap. It introduces a small, consistent naming convention, a minimum etiquette for every agent and a shared way to think about roles, messages, motivations and reasons. It asks systems to be explicit, polite and predictable.
This white paper is a starting point. It does not pretend to be the final truth. It is an invitation to developers, architects and AI practitioners to pause, think about what communication really is and agree on a common way forward.