Why the same architecture has six different names.

There are at least six distinct vocabularies in current use for the work that sits between an AI model and the business outcome it's supposed to produce. Each comes from a different practitioner community. Each has its own anchor terms, its own institutional backing, its own intellectual lineage. Most of them are looking at the same architectural object from a different angle.

These aren't six different fields. They're six different vocabularies looking at the same architecture from six different sides.

That object has a name in the vocabulary I have worked in since 2003. The methodology layer. It's the structure around the model that decides what the model sees, what it's allowed to act on, what it has to verify, and what survives when the model underneath it changes. None of that's the model. All of it's the architecture the model runs inside.

If you want the fragmentation in miniature, watch what has happened to the word harness in the past eighteen months.

In Lance Martin's usage, the agent harness is the software wrapper around the model. It executes tool calls, manages the message-history loop, handles context-engineering logic. Philipp Schmid's December 2025 articulation is exact: the agent harness is what the LLM runs inside of. The harness is structural. It is engineering.

In an older usage, harness means something else entirely. To harness an existing force. To build alongside it rather than against it. The river and the waterwheel. That usage predates the AI conversation by decades and lives in innovation literature, change management, business strategy. It names a relationship with constraint, not a piece of software.

Both meanings are real. Both name something that matters. They aren't the same thing.

Once you can see what harness is doing in two different places, the other vocabularies come into focus too. Same English word. Different conceptual work. The pattern repeats across every cluster.

Framework does two different jobs depending on whether the speaker is a regulatory professional citing a compliance framework or a methodology architect citing a thinking framework. Playbook does at least three jobs across the Stanford Digital Economy Lab's enterprise AI playbook from March 29, 2026, the Site Reliability Engineering runbook tradition, and the institutional strategy decks consultancies have sold for years. Layer does different work in implementation layer, context layer, governance layer, and methodology layer. Constraint is starting to fork the same way: NJ Raman's tiered constraint model from April 2026 names levels of control that the governance vocabulary already gestures at from a different tradition.

The vocabulary is collapsing under the weight of how many distinct architectural objects need names. The same words get reused because the conceptual machinery is moving faster than the language can stabilize.

The fragmentation isn't the problem. Different vocabularies for the same object is normal in any maturing field. Geometry survived having three or four words for the same shape while its vocabulary stabilized. Computer science survived dozens of names for the objects we now call classes.

The problem is what happens when practitioners use whichever vocabulary flatters their existing skill set to claim work that actually requires the whole stack.

There are three specific recognition failures in current practice.

The first is the practitioner with a sophisticated prompt collection who describes the work as "just prompts" and lets buyers evaluate it on prompt-engineering criteria. This is the most common failure, because the procedural floor and the methodology layer live next door to each other and the vocabulary for the floor is more familiar. A hundred-prompt library and a hundred-framework library look almost identical from the outside. They're architecturally very different. The prompts are downstream artifacts of the framework, not the asset. But the buyer doesn't know that, and the market has trained the practitioner to undersell.

The second is the practitioner shipping their work as a packaged skill and letting the conversation collapse to "we built a skill." Agent Skills shipped in October 2025 and became an open standard in December 2025, adopted by OpenAI, Microsoft, and Google within weeks. The format is now ubiquitous. But the packaging isn't the methodology. There's a test for this one: strip the SKILL.md format and paste the markdown into a plain document. If the methodology survives, you have real work that happens to be packaged as a skill. If it doesn't, the envelope was doing more work than the content, and you have procedural-floor capability wearing a fashionable wrapper.

The third is the vendor selling AI governance frameworks that are control crosswalks mapped to EU AI Act articles. The crosswalk is documentation, not methodology. It's necessary, and it satisfies regulatory requirements, but it isn't the framework that governs how to think about deployment decisions. The collision happens because framework is doing different conceptual work in the two usages, and the buyer can't always tell which one they are getting.

G. Mick Smith, an executive coach and former college dean who has spent years thinking about how operational intelligence gets preserved and transferred in organizations, named the pattern in a comment on one of my recent posts. He called it expertise as a personality trait instead of infrastructure. The phrase has stayed with me because it's the cleanest articulation I have heard of what goes wrong when methodology work can't be named clearly. When the expertise lives in the person rather than the architecture, it can't be transferred. When it lives in the architecture, it can. The vocabulary failure makes expertise look like personality, which is why so many practitioners with real methodology work end up positioning themselves as thought leaders instead of builders of transferable infrastructure.

The recognition failure is the architectural problem. Naming the methodology layer is easy. Six communities have already done it. Distinguishing real methodology-layer work from claims wearing borrowed vocabulary is the hard part.

The vocabulary hasn't converged yet. The architecture has.

Karpathy's LLM Wiki is the strongest convergence anchor in the current discourse, because his lineage is so clearly inside AI research. His April 2026 gist describes three layers: immutable raw sources, a compilation layer where the model transforms sources into structured knowledge, and a compiled artifact that becomes the operational asset. He uses the compiler analogy explicitly. Source code goes in. Compiled binary comes out. You don't re-execute the source every time. You compile once and run the artifact.

This is the same architectural claim methodology practitioners have been making for two decades. The artifact compounds. It isn't retrieved at query time, it's built once and refined over time. Karpathy arrived at the claim from the AI-research side. The terminology is different. The architecture is the same.

Nate Jones made the same claim from the enterprise-strategy side. His implementation-layer thesis names six components that have to exist before a deployment works reliably in production: workflow design, data access, authority, evaluation, audit trails, and recovery. Those six map almost cleanly onto the seven-component framework architecture I have used internally for years. Different vocabulary. Different starting point. Same object.

Lance Martin's work on agent harnesses and context engineering, a discipline he traces to May 2025, arrives from the AI-engineering side. His three-part rule for context handling, reduce, offload, isolate, is operational guidance for what to do inside the harness. The harness is the structural layer. Context engineering is getting the right information into that layer's working memory at the right time. Different vocabulary. Different scope. Same architecture.

The Forward Deployed Engineer job title, now appearing in dozens of postings across Aisera, Netic, and other AI vendors, is the operational evidence that the layer is real. Companies are paying engineers to embed inside customer environments and build it. The job didn't exist three years ago. Now it has a salary band, a career path, and a set of expected competencies. The work isn't prompt engineering. It is structural.

And it's the same layer I have described from the other direction. In a companion piece on agent security, I argued that the defense against the six documented categories of agent hijacking doesn't live in the model. It lives in the methodology layer: source verification before consumption, action gates at sensitive operations, cognitive-state integrity. The synthesis layer this article maps and the defense layer described there are the same architectural object, seen from two sides.

If the architecture is consistent but the vocabulary is fragmented, the practical question is how anyone, practitioner or buyer or observer, recognizes real methodology-layer work without getting fooled by claims wearing borrowed vocabulary. I use four diagnostics.

First, the model-replacement test. When the underlying model changes, does the work survive or collapse? GPT-4 to GPT-5. Claude Sonnet to Claude Opus. Gemini to whatever Google ships next quarter. Work that survives the swap lives in the methodology layer. Work that collapses lived in the model, and the practitioner mistook the model's capability for their own structural contribution. This is the cleanest diagnostic because it can't be faked. Either you swap the model and the work continues, or you swap it and the seams show immediately.

Second, the envelope test. Strip the packaging format, Agent Skills, custom GPTs, plugins, whatever the wrapper is this quarter, and ask whether the methodology survives as plain prose. Real work passes. The methodology can be described, taught, and applied without the wrapper. Fashionable wrappers fail it: what looked like a sophisticated skill turns out to be system prompts and tool calls with no architectural coherence outside the format that held them together.

Third, the translation test. Can the practitioner describe the same work using three of the six cluster vocabularies and have each description point to the same architectural object? Someone who can describe their work as a framework, an implementation layer, a harness, and a cognitive scaffold, and have each hold up under scrutiny, is doing real methodology-layer work. Someone who can only describe it in one cluster's vocabulary is probably in that cluster, not in the layer above it.

Fourth, the compounding test. This one comes from Karpathy directly. Does the work compound over time, or does it evaporate between sessions? Methodology compounds. Each application teaches the next. The library grows. The patterns refine. The architecture absorbs new domains without losing prior coverage. Prompts don't compound this way. Configurations don't. Skills, plugins, and GPTs don't compound by themselves. This is the most demanding test, because it requires the work to have been deployed long enough to show whether it accumulates value or just produces new versions of the same artifact.

These four aren't exhaustive. Other diagnostics exist. But they filter for the difference between real methodology-layer work and claims wearing borrowed vocabulary, and they survive the swap of the vocabulary itself.

Step back from the specific failures and the pattern itself starts to teach.

The vocabulary tracks practitioner-community membership, not conceptual difference. Engineers reach for harness because they came up through engineering. Compliance officers reach for governance framework because they came up through compliance. Strategists reach for playbook because the McKinsey lineage runs through their training. Consultants reach for implementation layer because PE-financed deployment companies are the buyers who pay them. Academics reach for cognitive scaffold because Vygotsky is in their footnotes. Methodology architects reach for framework because that tradition predates all of the above and has always called the unit of work a framework.

The adjacent clusters get confused with the methodology layer more often than the distant ones. Prompt engineering and methodology get conflated constantly because they live next door. Packaging formats and methodology are conflating in real time right now, because Agent Skills made the wrapper ubiquitous and the wrapper gets mistaken for the content. Infrastructure work, context engineering and RAG and memory layers, gets confused with methodology because the boundary between what context the agent should have and how the context gets there's genuinely blurry.

Governance and orchestration confuse with methodology less often, because they have their own professional bodies, certifications, and training pipelines. Someone with ISO 42001 audit experience doesn't usually think they're doing methodology work, because they know exactly what ISO 42001 audit work is. The risk of conflation rises in proportion to the absence of established professional boundaries.

Even the recognition vocabulary is still forming. No one has settled on a clean term for the work of noticing that different vocabularies name the same architecture. Mick Smith named the meta-problem. "Vocabulary cartography" is one candidate for the activity. The fact that the meta-vocabulary hasn't stabilized is itself a sign of how new this conversation is.

For practitioners doing methodology-layer work: use the vocabulary the listener already knows. An engineer hears harness. A compliance officer hears governance framework. A strategist hears playbook. A buyer reading analyst reports hears implementation layer. An AI researcher hears compiled artifact. Code-switching isn't dishonest. It's the recognition failure working in your favor instead of against you. The architecture is the same whichever word you put on it, and you serve the listener better by meeting them where their training is than by insisting they learn yours.

For buyers evaluating what they're paying for: run the four diagnostics. Model-replacement, envelope, translation, compounding. Most of what is sold as AI methodology will fail at least two of them. Some of what is sold as prompt engineering or implementation will pass all four. The vocabulary on the invoice tells you less than the architecture under it.

For the field as a whole: the synthesis vocabulary isn't going to form on its own. The clusters have been visible for two years. The recognition failures have been written about inside individual communities. The convergence is happening. None of that has produced a shared vocabulary, and there's no reason to expect more of the same to produce one.

Someone has to deliberately architect the synthesis. Map the clusters, name the boundaries, articulate the recognition failures, build the diagnostic toolkit, and publish the map publicly so practitioners across the six communities can find their way back to the same conversation.