Master the Model Before You Master the Agent

Andrej Karpathy said something last week that most of the AI industry is not ready to hear. He said the biggest mistake in AI right now is that people are forcing agents to work instead of mastering the model first. Then he added a line that is easy to skim past and impossible to unsee: we made that mistake in 2016 at OpenAI, and it cost us five years.

Five years. From one of the people who built the field, about the company that arguably launched it. That is not a hot take. That is a scar.

If you have been in an enterprise AI meeting in the last six months, you already know exactly what he is describing. Someone shows a demo where an agent books a flight, refactors a repo, or answers a boardroom question. The room applauds. A roadmap appears. A budget follows. And then, quietly, over the next two quarters, the agent stops working the moment a real customer touches it — and no one on the team can say precisely why.

Karpathy's sentence names the reason. The team fell in love with the agent before they understood the model. They built the roof before they poured the foundation. And now they are trying to hold up a house with a demo.

This essay is a slow read of what he actually meant, why it matters more inside the enterprise than inside a lab, and what a data or AI professional should do differently on Monday morning. It is the argument at the center of the book we have been writing all year — that in the agentic era, the foundation is the product, and everything else is theatre.

Forcing an agent to work looks, from the outside, like engineering. It has commits. It has evals. It has a Slack channel with a rocket emoji. But if you watch it long enough, you notice the shape of it: every failure is answered by adding another tool, another retry, another prompt guardrail, another fallback model, another human in the loop. The scaffolding grows faster than the capability.

That is not a bug in your team. It is the natural gravity of demos. A demo is a promise you make to your future self. Once you have made the promise publicly — to a customer, a CFO, a board — you cannot easily walk it back. So you patch. And patch. And patch. Until the agent is less a system and more a life-support machine keeping a compelling three-minute video alive in production.

The enterprise version of this is even more expensive, because the patches are political. Every new retry is a compliance review. Every new tool is a procurement cycle. Every human-in-the-loop is a headcount conversation. The scaffolding does not just cost engineering time — it consumes the organisation's attention, which is the one resource an AI program cannot afford to burn.

Karpathy's point is that this whole loop is downstream of one earlier mistake: you started building the agent before you had an honest, boring, gridded-paper understanding of what the model underneath can and cannot do. Every patch after that is you rediscovering the model's real shape through pain.

'Master the model' is not a call to train your own foundation model. It is a call to know, in your bones, three things: the model's capability envelope, its failure surface, and its behaviour under real-world load.

The capability envelope is what the model can reliably do on your data, not on a benchmark. It is the difference between 'GPT can summarise legal text' and 'this model summarises our lease agreements at 94% faithfulness when the clause is under 400 tokens and drops to 71% above that.' One is a marketing claim. The other is a foundation you can build a product on.

The failure surface is how the model breaks. Does it confabulate quietly, or refuse loudly? Does it lose the plot at 8k tokens or at 40k? Does it get worse when you add tool descriptions, or better? Does it degrade on jargon from your specific vertical? Every one of these is a load-bearing fact. Skip them, and your agent is a beautifully painted door hung on nothing.

Behaviour under load is the part everyone forgets. A model that is brilliant at 20 requests per hour can be unusable at 20 per second — different latency, different cost curve, different rate-limit behaviour, different quality under batching. The model you demoed and the model you shipped are, functionally, two different models. Karpathy's five lost years at OpenAI were, in part, the industry learning this the hard way.

Chapter 3 of The Context Advantage — Smart Models Still Need Smart Systems — is our long-form version of this argument. Intelligence alone is never enough at enterprise scale. What you need is a tested, characterised, understood model sitting inside a system that respects what it is actually good at.

Karpathy's second line — demos are easy, products take a decade, self-driving proved it — is the one that should be printed on the wall of every AI team in every enterprise on earth.

The first credible self-driving demo was in 2009. Sixteen years later, a small number of companies operate limited robotaxi services in a handful of cities. Not because the demo was fake. Because the demo was the easy 90%. The remaining 10% — the long tail of weather, construction cones, cyclists at dusk, kids on scooters, a plastic bag in the wind that looks like a dog — is where a decade of foundation work lives.

Every enterprise AI program is, right now, standing at the equivalent of 2010 self-driving. The demo works. The pilot works. The controlled-environment version works. And the team is being asked to skip the decade of foundation work and go straight to production, because a competitor tweeted a screenshot.

The teams that will still be here in 2030 are the ones who, quietly, in the middle of the hype cycle, choose to spend their next quarter on the foundation the demo skipped. Data contracts. Semantic layer. Retrieval quality. Evals that reflect real users. Governance that a regulator can read. Cost models that survive a scale event. None of it is glamorous. All of it is the product.

This is the sentence that sits under everything Karpathy said, and it is the sentence that sits under everything we wrote in The Context Advantage. In the agentic era, the agent is not the product. The foundation is. Build that, and agents emerge on their own — often as a thin surface on top of a very deep stack.

That reframing changes what a roadmap looks like. Instead of 'ship an agent for support in Q3, an agent for sales in Q4, an agent for finance in Q1', you get 'in Q3 we finish the entity resolution and the semantic layer that all three agents will depend on; in Q4 we harden retrieval and evals; in Q1 the first agent lights up on top of a foundation that will support the next twenty.' Slower on the outside. Compounding on the inside.

This is the argument of Chapter 4 — The 4 C's Framework — which is the operating system of the book. Context, Control, Cost, Choice. Four foundations, in that order. Skip any of them and you are building the agent Karpathy is warning you about. Sequence them properly and the agents almost design themselves.

The teams we see winning in the field are boringly disciplined about this. They do not ship an agent until the foundation under it can answer four questions without a human present: does it have the right meaning, is it safe to act, can we afford it at scale, and can we move it if we need to. Four yeses, then agent. Anything less, then more foundation.

Of the four foundations, context is the one most enterprises are still pretending they have. They point at a vector database and call it context. They point at a RAG pipeline and call it meaning. They point at a data catalogue that has not been updated in six months and call it a semantic layer.

Karpathy's point applies here too. The model does not fail because it is dumb. It fails because the meaning around it is thin. When a support agent hallucinates a refund policy, the model did what models do — it predicted a plausible answer from the shape of the question. The failure was upstream, in the layer that was supposed to hand the model the actual policy, the actual customer, the actual entitlement, the actual history, in a form the model could reason over.

Chapter 5 — Context Is the New Data Layer — makes the case that meaning now sits above storage and compute in the enterprise stack, and that the professionals who own that layer will own the next decade of AI work. Chapter 6 — Business Meaning Beats Raw Retrieval — is the corollary: naive RAG is not a context strategy, it is a demo dressed up as one.

If you take one action from this essay, make it this. Before you add another tool to your agent, spend a week characterising your context layer with the same rigor you would spend on a database migration. What does it know? What does it not know? Where does meaning live? Where is it stale? Who owns it? What breaks when a schema changes? This is unsexy work. It is also the work that decides whether your agent is a product or a puppet.

The second foundation is the one legal will bring up in month three, and by then it will be too late to add cheaply. Control is what turns an agent from a science project into something a regulated enterprise can actually run.

Governance for humans is a solved-ish problem — roles, permissions, audit logs, approvals. Governance for agents is a mostly-unsolved problem, because agents do not just read data, they act. They send emails, refund customers, close tickets, kick off workflows, and increasingly, call other agents. Every one of those actions needs a policy, an audit trail, a kill switch, and a story you can tell a regulator with a straight face.

The Control chapters in Part 3 of the book argue that this layer must be designed before the first agent ships, not retrofitted after the first incident. The organisations getting this right are treating agents as a new class of principal in their identity system, with their own permissions, their own rate limits, their own approval workflows, and their own incident playbooks.

If Karpathy's line is 'master the model first', the enterprise addendum is 'master the boundary the model acts through, second'. An unbounded agent is not a product. It is a liability with a UI.

The last two foundations are the ones that decide whether your AI program survives its first budget review. Cost is not a finance problem. It is an architecture problem. Choice is not a procurement problem. It is a survival problem.

On cost: the moment your agent goes from 100 users to 100,000, the token bill stops being a rounding error and starts being a line item the CFO can see from space. Teams that did not design for cost end up doing an emergency migration to a cheaper model, which — because they never characterised the original model in the first place — silently regresses quality in ways nobody can debug. Part 4 of the book is a long, practical argument for putting cost on the same dashboard as latency, from day one, and treating every AI feature as having both an engineering owner and a cost owner.

On choice: the model market will keep moving. The pricing will keep moving. The regulation will keep moving. The team that welded itself to a single provider in 2025 will spend 2027 rewriting instead of shipping. Part 5 of the book is our argument for portability as a discipline — open formats, provider-agnostic abstractions, a 'portability percentage' budgeted into every project. Not because any one vendor is bad, but because optionality is the only real hedge in a market moving this fast.

Together, Cost and Choice are the foundations that turn a spectacular pilot into a business that still exists in three years. They are the least fashionable of the four Cs, and they are the ones you will be most grateful for.

Karpathy closed with a line that most people missed, and it is the one that should stay with you longest. He said: you building agents right now — you are at the forefront. Not OpenAI. Not DeepMind. You.

That sentence is not a compliment. It is a transfer of responsibility. The frontier of AI, right now, is not being set in a research lab. It is being set in the messy middle — in enterprises, in mid-sized teams, in the engineer who is trying to make a support agent work on a Tuesday afternoon with a data model that was designed in 2014. That is where the real integration is happening. That is where the real failure modes are being discovered. That is where the next decade of the field is being written.

Part 6 of the book — The Data Professional's Future — is our long-form response to this idea. The agentic data professional is not a new job title. It is a new posture. It is the person who has stopped waiting for a vendor roadmap and started designing the foundation their organisation will run on for the next ten years. It is the person who reads a Karpathy tweet and, instead of retweeting, opens their laptop and audits their context layer.

If that is you, this book is for you. And if that is not yet you, this essay is our invitation to become that person, starting now.

Here is the shape of the shift, distilled from Part 7 of the book — the Implementation Playbook — into something you can act on this week.

First, name the demo. Every AI project in your organisation has a demo somewhere in its DNA. Find it. Write down the exact promise it made. Then write down, honestly, which parts of that promise the current foundation can actually keep. The gap between those two lists is your real roadmap.

Second, characterise the model. Not the marketing model. Your model, on your data, at your load, on your worst inputs. Publish the results internally. Make it normal to say 'the model degrades above 8k tokens on contract text' the way it is normal to say 'the API 500s above 2k RPS'. This is the single highest-leverage change most teams can make, and it costs almost nothing except honesty.

Third, invest in the foundation the demo skipped. Pick one of the four Cs — the one your organisation is weakest at — and give it a real quarter. Not a task force. A quarter. Context, Control, Cost, or Choice. One of them is quietly killing every agent you ship. Fix that one before you ship the next.

Fourth, treat every new agent as an emergent property of the foundation, not a project of its own. If the foundation is right, the second agent takes a fraction of the time the first one did. If the foundation is wrong, every new agent costs more than the last. Watch that ratio. It is the single cleanest signal of whether you are following Karpathy's advice or repeating his mistake.

Where this lives in the book — the direct links, so you can go deeper on any pillar:

→ Chapter 3 — Smart Models Still Need Smart Systems: /context-advantage/book/chapter-3

→ Chapter 4 — The 4 C's Framework: /context-advantage/book/chapter-4

→ Chapter 5 — Context Is the New Data Layer: /context-advantage/book/chapter-5

→ Chapter 6 — Business Meaning Beats Raw Retrieval: /context-advantage/book/chapter-6

→ Part 3 (Control), Part 4 (Cost), Part 5 (Choice), Part 6 (The Data Professional's Future), Part 7 (The Implementation Playbook): browse from /context-advantage/table-of-contents