The 2025 AI stack and the architecture it's missing

AI architecture metaobjects

I. The follow-up I promised

Last essay I argued that AI drift is the architectural problem MetaObjects exists to solve. I gestured at the rest of the industry — context engineering, schema-driven agent design, knowledge-graph grounding, the Model Context Protocol — and promised a follow-up that actually engages with what each of those approaches does and where it fits. This is that follow-up. None of those approaches is the enemy. None of them, on its own, is the architecture either.

II. What the industry has been building

The 2025–2026 conversation around AI consistency has produced four distinct architectural ideas. Each is real. Each does something useful. None of them, on its own, is the architectural layer the problem actually needs.

Context engineering

A 2025 discipline focused on the prompt-time problem: keeping AI agents on-task and grounded across a session by carefully constructing the context window — system prompts, retrieved documents, conversation memory, tool descriptions, recent decisions. The framing emerged in mid-2025 as a counter-discipline to "prompt engineering," and is now treated as best-practice by tooling vendors and consultancies alike (Packmind, Lumenalta, Atlan, and many others have written it down).

Context engineering is the right discipline at the prompt layer. If you're going to send a model out to do work in your system, the prompt it sees needs to be deliberate — the right system instructions, the right retrieved documents, the right history. Teams that take this seriously ship better agents than teams that don't.

But what context engineering can't do is outlive the session. The careful work you put into one prompt evaporates when a different prompt fires for the same task next week. Context is a session-scoped artifact. Architecture is what survives the session — and your system needs both.

Schema-driven agent design

The practice of constraining AI agent outputs through formal schemas at tool boundaries — JSON Schema for structured outputs, OpenAPI for tool descriptions, strict typed responses. The argument: if you give the model a schema to fill in, it can't hallucinate fields or invent arguments that don't exist. Widely adopted by 2025 as a primary defense against AI-generated nonsense reaching production.

Schemas at the tool boundary are genuinely useful. A model that's been told "return an object with these specific fields" can't invent a field that's not on the list. Hallucinated structures get caught before they leave the agent's mouth.

The problem isn't the schema; it's where the schema lives. A schema attached to one tool doesn't agree with a schema attached to another tool in the next service. Each tool's schema is locally correct; the system that uses both ends up with two definitions of the same business concept. The fix isn't fewer schemas — it's a schema that lives above the tools, not inside each one.

Knowledge-graph grounding

Feeding structured domain knowledge — typically a knowledge graph of entities, relationships, and facts — to AI agents as grounding data, so they reason from your domain rather than hallucinating from priors. Long-established in regulated industries; accelerated in 2024–2025 as enterprises sought guardrails for LLM-powered agents.

Knowledge graphs are how regulated industries grounded AI long before it was fashionable. If you're letting an agent reason about your domain, a graph of what's true gives it something to point at instead of priors learned from the internet. Hallucination rates drop. Audit trails get cleaner.

But a knowledge graph describes the world; it doesn't describe the code. Generating a coherent service or a correct API requires shape, type, and behavior — the structural facts of how the software is built — and those don't live naturally in a domain knowledge graph. KGs solve grounding. They don't solve codegen.

The Model Context Protocol (MCP)

A standardized protocol introduced by Anthropic on November 25, 2024, for connecting AI agents to tools and context sources. By late 2025, MCP was adopted across the industry as the de-facto standard for letting agents reach into systems — file stores, databases, APIs, internal tools — in a uniform way.

MCP is necessary infrastructure. Before it existed, every agent-to-system connection was a custom integration. After it landed, the connection layer had a standard. That's a real win.

But MCP is the pipe. It defines how an agent reaches into a system; it doesn't define what shape the system has on the other end. You can stand up ten MCP servers in front of your stack and still have ten slightly different shapes of the same concept on the other end. The protocol is honest about this — it transports context, it doesn't author it. The thing being transported still has to come from somewhere.

III. What none of them solve

The architectural axis all four approaches miss. Look at where each of the four lives in the stack:

  • Context engineering sits above the application, at the prompt layer.
  • Schema-driven agent design sits above the application, at the tool-call contract.
  • Knowledge-graph grounding sits above the application, at the knowledge layer.
  • MCP sits above the application, at the transport layer.

None of them is runtime substrate inside the application. They're all external to the running system. They make the agent talking to the system more disciplined; they don't change what's in the system. That's the architectural axis the conversation keeps missing.

This matters because the failures that show up in production are application-level failures. The refactor that took an afternoon now takes a sprint because AI tools can't see beyond the file they're editing. The integration that worked in staging breaks when the second service's AI-generated client doesn't quite match the first service's AI-generated server. The multi-agent system that was supposed to compose its own pipeline drifts further apart with every commit. None of those failures get fixed by a better prompt or a tighter tool schema. They're architecture problems.

Forrester named the symptom in 2025: agent drift, the silent killer of AI-accelerated development. The empirical work backs them up — recent studies of agentic refactoring (arxiv 2511.04824) found that AI coding agents overwhelmingly prefer local, consistency-oriented edits over the system-level refactors humans actually do. The academics are converging on the same shape of answer: software models need to be a first-class part of AI codegen (arxiv 2511.02475, Lost in Code Generation).

What none of the industry approaches gives you is the substrate — the thing inside the application that every actor (the agent, the codegen tool, the type checker, the next engineer) reads from. The architectural layer. And it has to live inside the application, not above it.

IV. Where the metadata layer fits

Three pillars that make this not-just-codegen

MetaObjects isn't another codegen tool sitting next to Protocol Buffers, OpenAPI Generator, Smithy, or TypeSpec. Three properties separate it from anything in that category:

Whole-stack scope, not just API surfaces. Protocol Buffers, OpenAPI Generator, Smithy, and TypeSpec generate API surfaces — wire formats, client stubs, server stubs. MetaObjects generates the entire application stack from one metadata model: persistence (ORM, DAOs, DTOs), UI form bindings, validation rules, MVC scaffolding, business-logic seams. The codegen scope is much wider, which means much more of the codebase derives directly from the architectural source of truth — and any compile-time safety those generated types provide covers the whole system, not just the API edge.

Runtime metadata, not just build-time output. The other codegen tools stop at "produce code at build time." MetaObjects also interprets metadata at runtime. That means a substantial portion of what would otherwise be hand-written code stops needing to exist at all. Less code in the repo, less surface area for AI to drift on, less code for humans to maintain.

Customization by augmenting metadata, not by writing more code. Multi-tenant configurations, regulatory variants, scenario-specific behavior: overlay metadata on the base model and the system adapts at runtime — no recompile, no redeploy, no fork. This is the pattern Liquent's pharmaceutical platform used twenty years ago, and it scales now to AI-era systems where requirements shift faster than compile cycles.

Pull these three together and the math gets interesting. Less code in the repo means less code for AI to drift on. Less code means fewer places to introduce bugs. Less code means refactors propagate from one place instead of a hundred. The equation I keep coming back to: less code = less drift = less bugs = faster dev. That's not a marketing line; it's an architectural consequence of moving work from build-time generation into runtime interpretation.

Compatibility with the four industry approaches — not competition

The four industry approaches above are real, useful pieces of the stack. The MetaObjects bet isn't that you should abandon them; it's that they all need something to read from, and that something is the metadata layer. The integration matters more than the comparison:

  • With context engineering. Your context pipelines need a stable source of truth for what the system is. MetaObjects is what they point at. Instead of curating context per agent per session, the agent reads metadata and the context is consistent by construction.

  • With schema-driven agent design. Per-tool JSON Schemas and OpenAPI specs are valuable at the contract boundary — but they shouldn't be hand-maintained per tool. Generate them from MetaObjects metadata, and every tool's schema is consistent with the architectural source of truth.

  • With knowledge graphs. MetaObjects metadata, extended beyond entities to systems, applications, APIs, payloads, and integration boundaries, is a knowledge graph of your estate. You don't need a separate KG pipeline if your metadata layer is already producing the graph.

  • With MCP. Expose the MetaObjects metadata graph through Model Context Protocol servers and your agents stop guessing — they navigate. MCP is the protocol; MetaObjects is what flows through it at the system level.

None of this requires you to pick. The teams that have invested in context engineering can keep doing it — and have a stable source of truth for the context to point at. The teams that have schema-driven tool definitions can keep them — and generate them from one architectural model. The teams running MCP servers can keep them — and now have a metadata graph worth actually exposing. MetaObjects compounds with everything already on your roadmap; it competes with nothing.

V. The architectural picture

The four approaches above don't compete with the metadata layer; they sit on top of it. Roughly:

┌────────────────────────────────────────────────────────────────┐
│  AI Agents · Codegen Copilots · Code Reviewers                 │  (consumers)
└──────────────────────────────┬─────────────────────────────────┘
                               │ reads from
┌──────────────────────────────▼─────────────────────────────────┐
│  Tool & Context Protocols                                       │
│  MCP · OpenAPI · JSON Schema · context engineering pipelines    │  (transport)
└──────────────────────────────┬─────────────────────────────────┘
                               │ consumes
┌──────────────────────────────▼─────────────────────────────────┐
│  MetaObjects Metadata Graph                                     │
│  Entities · Systems · APIs · Payloads · Workflows · Roles       │  (ARCHITECTURE)
└──────────────────────────────┬─────────────────────────────────┘
                               │ generates / interprets
┌──────────────────────────────▼─────────────────────────────────┐
│  Generated Application Code (zero runtime dep on MetaObjects)   │
│  Persistence · DAOs · DTOs · UI bindings · MVC · Validation     │  (output)
└────────────────────────────────────────────────────────────────┘

The diagram makes the point the comparison-essays usually miss. Every approach the industry is rallying around — context engineering at the top, protocols and contracts in the middle, agents consuming all of it — needs the metadata layer underneath. Without it, each of those layers is improvising its own answer to what shape the system has, and the answers keep diverging.

This is also where the commercial direction of MetaObjects lives. Once metadata extends beyond entity definitions to systems, applications, APIs, payloads, and integration boundaries, the metadata layer naturally constructs a graph of the entire estate. Expose that graph through MCP servers, and your AI agents stop guessing — they navigate the architecture itself. The same metadata that drives codegen at build time and behavior at runtime now drives agent reasoning at inference time. Three uses, one source.

The open-source platform gives you the architectural pattern and the working generators. The commercial side will be where the graph and the MCP exposure live, for enterprises that need it stitched together at scale.

VI. Where to start

If you're shipping AI-generated code at scale and you don't have a canonical metadata layer, you have three real choices.

Build it yourself. Plenty of teams have, in pieces — a shared types package, a common contracts library, a homegrown schema registry. It works until the next service team decides their needs are different enough to fork. The discipline is hard to hold without a generator behind it.

Adopt the pattern. The architectural pattern matters more than any specific tool. MetaObjects is one expression. Smithy and TypeSpec are narrower expressions at the API layer. OMG MDA is a broader expression at the modeling-language layer. Salesforce's metadata-driven platform is a commercial expression at the multi-tenant SaaS layer. Pick one. Stay disciplined.

Or ignore it and pay later. Drift compounds. Refactors get harder. You spend more time reconciling AI-generated code than you saved generating it. Eventually you build the layer anyway, only with technical debt as the foundation. I've watched it happen at scale; I'm not interested in watching it happen again.

If you're thinking through this for your own organization, I'm always up for a conversation — drop me a note.

VII. What's next

This essay is the second in a series. The first laid out the problem and what I'm building. This one positions the work in the broader industry conversation. The next will dig into what AI-first development actually looks like inside an enterprise stack — the work, not the rhetoric.

If you want to follow along, my writing lives at dougmealing.com/writing.