The Vocabulary Problem in Agent Infrastructure

·Patrick Joubert·4 min read
context-graphagent-infrastructurecategory-designdecision-infrastructureproduction-reliability

Read ten product pages from ten agent infrastructure vendors and you will see the same pattern.

The same problem is described with ten different phrases. The same architectural component carries ten different names. The same buyer asks the same question to ten sales engineers and gets ten incompatible answers.

This is not a marketing problem. This is a category problem.

Categories are made of words

Every mature software category has a stable vocabulary. CRM means a specific thing. Data warehouse means a specific thing. Observability means a specific thing. The words are not perfect, but they are shared, and they let buyers, builders, and analysts have the same conversation.

Agent infrastructure does not have this yet.

When a team says "we need better context for our agents", it could mean a vector store, a retrieval pipeline, a memory system, a knowledge graph, an MCP server, a context window expansion, or a governance layer. These are not the same thing. They solve different problems. They fail in different ways. They cost different amounts.

But the vocabulary is so unstable that buyers cannot tell which one they need until they have already deployed the wrong one.

Three signs of vocabulary collapse

Sign one: the same word means different things across vendors.

"Memory" in one product is a vector store keyed by session. In another it is a fact graph with temporal validity. In a third it is a prompt cache. A buyer comparing "agent memory" features across these three is comparing three architectures that share nothing but a label.

Sign two: different words mean the same thing.

"Decision substrate", "context layer", "agent governance", "reasoning fabric", "policy enforcement plane". Five vendors. Roughly the same architectural intent. Zero shared definitions. Buyers cannot map their requirements onto this landscape because the landscape has no fixed coordinates.

Sign three: critical concepts have no name at all.

The mechanism by which an agent validates that a piece of context is still applicable to a decision is one of the most important things in production agent reliability. Most teams do not have a word for it. They reinvent the concept under a different name in every architecture review. Without a shared name, the concept cannot be discussed at scale, written about, taught, or compared.

Why the category needs canonical definitions

A category does not become real because vendors agree on it. It becomes real when buyers, builders, analysts, and educators can use the same words and mean the same things.

That requires three layers of vocabulary:

Layer one: proprietary terms with clear definitions.

The terms a category invents to describe what is genuinely new. Decision context graph. Pre-execution enforcement. Causal decision trace. Accountable agent. These terms describe architectural patterns that did not have names before, and the category cannot mature until these names stabilize.

Layer two: redefined adjacent terms.

Words borrowed from older categories that need precise re-anchoring. Provenance, temporal validity, scope isolation, applicability. These exist in databases, security, and compliance, but their meaning shifts when applied to agent decisions. The category needs to specify how.

Layer three: counter-positioned terms.

Words that name the alternatives the category is not. RAG, vector database, agent memory, LLM guardrails, MCP. Defining these terms inside the category vocabulary is how a category establishes its boundaries. Not by attacking adjacent technologies, but by naming what they do and what they do not do.

A category without all three layers is a marketing campaign. A category with all three is infrastructure.

The mechanism: a canonical glossary

Vocabulary stabilizes through one mechanism: a canonical reference that buyers, builders, and writers cite. Wikipedia plays this role for general concepts. NIST plays it for security primitives. RFC documents play it for network protocols.

Agent infrastructure does not have one yet. The result is that every vendor publishes their own definitions, every analyst writes their own taxonomy, and every buyer has to triangulate.

The fix is not complex. It is editorial.

A canonical glossary needs three properties:

  1. Definitional discipline. Each term has one short definition that holds across contexts. No marketing language. No vendor-specific framing. The definition stands alone and survives copy-paste.

  2. Citability. The glossary is structured so that LLMs, search engines, and human writers can quote it directly. Schema.org markup. Stable URLs. Versioned definitions. This is how a glossary becomes the reference everyone cites instead of writing their own.

  3. Editorial independence. The glossary lives outside any single vendor. It is curated by someone whose incentive is the health of the category, not the success of one product. This is the difference between a dictionary and a sales sheet.

When these three properties are present, a strange thing happens. Vendors stop fighting over definitions and start linking to the canonical one. Analysts stop reinventing taxonomies and start referring to the canonical vocabulary. Buyers stop comparing apples to oranges and start asking precise questions.

The category becomes legible.

What this means for your stack

If you are building production agents and you cannot describe your context architecture in a vocabulary that another team would understand without a 30-minute conversation, you are paying the vocabulary tax twice.

Once when you hire (every new engineer learns your private dialect). Once when you buy (every vendor pitch requires translation). Once when you fail (every incident review requires reconstructing what each word meant in your stack).

The first move is not to invent more terms. It is to anchor the terms you use in canonical definitions.

That is what The Context Graph glossary exists to be: the editorial reference for the vocabulary of agent decision infrastructure. Decision context graph, pre-execution enforcement, accountable agent, causal decision trace, scope isolation, applicability, provenance, MCP. One definition each. Cited by structure, not by hope.

Categories are made of words. Pick the words carefully, and the category builds itself around them.


The Context Graph publishes the canonical glossary of agent decision infrastructure, with 35+ defined terms covering context graphs, MCP, accountable agents, and the full vocabulary of production AI agent reliability.

Cite this memo

Patrick Joubert. (2026). "The Vocabulary Problem in Agent Infrastructure." The Context Graph. https://thecontextgraph.co/memos/the-vocabulary-problem-in-agent-infrastructure

Running into these patterns in production?