Skip to content
Carbonfay
RU

engineering notes

Do machines need their own languages to coordinate

Why agents need compact machine representations of meaning instead of natural language, and what it changes in cost and reliability.

In brief for executives. When agents “agree” among themselves in natural language, it is expensive (extra tokens) and unreliable (ambiguity). The industry is already moving toward machine coordination protocols — this is not futurology but an infrastructure shift that will set the cost and reliability of the next generation of AI systems. Why Carbonfay is looking there already — in this note.


Today the typical way to connect agents is to make them exchange natural-language text: one describes the task in words, another reads and answers in words. This is convenient for a human and bad for machines. The question is not “will machine coordination languages appear” but “how fast will they become infrastructure”.

question

Why would machines need a human language to agree with each other?

Hypothesis: natural language is not a coordination interface

Natural language was made for humans: it is redundant, context-dependent and ambiguous. For coordinating machines these are flaws, not virtues. Effective inter-agent coordination requires a compact, unambiguous representation of meaning — i.e. a separate “language” for machines, not human text.

data
Inter-agent protocols are becoming a standard
1000+
MCP servers available by early 2025 (protocol introduced late 2024)
97M+
SDK downloads per month a year after launch
4 of 4
of the largest model providers adopted it (Anthropic, OpenAI, Google, Microsoft)

Machine coordination is already getting its protocols — an infrastructure shift, not a hypothesis. The future engineering of AI systems is built around such standards.

Source: Model Context Protocol, годовой обзор, 2025 https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/

This is already happening: agent-interaction protocols became a de facto standard within a year, backed by all major providers.

Problem: text coordination is expensive and unreliable

Every “message in words” between agents is extra tokens (hence money) and a risk of differing interpretation (hence a failure). The more agents and steps, the more both cost and ambiguity accumulate. A system built on agents corresponding in text gets more expensive and less predictable as it grows.

Why the usual approaches don’t work

“Describe the protocol in words in the prompt” doesn’t work: a prompt is not a protocol, it cannot be validated and versioned, and each iteration costs tokens.

“Take a smarter model” doesn’t help: ambiguity is a property of the exchange language, not of the participant’s intelligence.

“Agree on an answer format in words” doesn’t work without schema enforcement: the model may return something similar but not valid.

Engineering model: compact meaning and protocols

Typed messages instead of text. Agents exchange a structure with mandatory fields, not a free description. This is checkable, versionable and compact.

Semantic DSLs. For recurring domains — narrow formal languages that express meaning densely and unambiguously, instead of verbose natural text.

Interaction protocols. Standardized interfaces between agents and tools (like the emerging industry protocols) are the infrastructure the future systems are built on.

Natural language only at the human boundary. Where a human is in the loop, text is appropriate; between machines — a compact representation.

Practical takeaway for business

This affects cost and reliability already today. A system where agents coordinate in a typed way is cheaper to operate and more predictable than one where they “correspond in words”. This is an engineering choice with a direct consequence for the bill.

Interaction standards are a factor in choosing a contractor. A solution built on formal protocols and contracts will survive a change of models and tools; one built on text correspondence will not.

Carbonfay designs inter-agent coordination formally because that is where the infrastructure is going — not because it is fashionable.

Apply this to your processes — .

Open questions

Whether a single “agent language” appears or it stays a set of per-domain protocols is an open question; the bet on formalization is right either way. How to balance expressiveness and compactness of semantic DSLs is a research task. Where the boundary is beyond which formalization hampers flexibility is set by the domain, not a general rule.


If in your system agents “correspond in words” — that is both cost and risk that can be removed. — we’ll look at where to replace text coordination with a formal one.

related cases

Next step

Let's design an AI-native automation layer for your operations.

DBCV