Ask anyone building an AI agent what they're working on, and they'll tell you about the model. Which one, which version, the prompt, the benchmark. The model gets all the attention.

It's the smallest part of the system.

I've built a few agentic systems now, and every time, the model was the part I touched least. I called it through an API and moved on. The real engineering—the debugging, the failures, and the decisions that determined whether the system actually worked—lived everywhere else: context assembly, retrieval, orchestration, memory, and output handling.

So I started counting. Not mathematically. Architecturally.

The count

The model is about 10% of an agent. The other 90% is data engineering.

Walk through a single turn.

A request comes in. Before the model sees anything, you assemble its context: load the conversation history, retrieve what's relevant, rank it, select what fits the context window, build the prompt, and attach the tools. Retrieval itself may call a small embedding model that you rent, but the storing, indexing, searching, and ranking around it—that's your engineering.

Diagram: the anatomy of one agentic turn. Two small rented model forward passes—an embedding model inside context assembly and the generative LLM—are wrapped in data-engineering steps you build: retrieve and rank, output handling, memory, and compaction when context grows. A bar at the bottom shows roughly 90% data engineering to 10% rented inference.
The anatomy of one agentic turn—two rented model calls (gold), everything else built.

Then comes the one call to the model.

It returns text. Now you're back to engineering. You parse the response, validate it, decide whether it's an answer or a tool call, execute the tool, capture the result, format it, write it back to state, update memory, and when the conversation outgrows the context window, you summarise, evict, re-index, and reassemble.

One rented call. Wrapped in everything you built.

Now look at what all of that work has in common. Loading, retrieving, ranking, selecting, routing, storing, compacting—every step is data moving from one place to another, reshaped along the way. What looks like AI engineering is, for the most part, the engineering of data.

Here's what that means. The forward pass is the one part you can't improve. You rent it, and it gets better on its own as providers ship new versions. Everything people call "getting better results"—better prompts, better context, better retrieval, even fine-tuning on your own data—is the 90% you build. Model selection just chooses which 10% you rent.

So most teams are optimising the one part they can least change—the part that improves without them anyway.

The hardest part of AI is rarely the model. It's the system around it—and that system is data engineering.