The Rise of the Context Engineer

A few months ago I watched an agent do, in about twenty minutes, something that would have taken a week for a competent analyst to do. Pull the data, write the queries, run the analysis, build the dashboard, draft the write-up. All of it. And it was good. Not "impressive for AI" good, actually good.

Then I watched a human spend the next two hours fixing it. Not the math. The math was fine. The problem was that the agent had quietly picked one definition of net sales, and there were three. Retail counted it one way, wholesale another, and the DTC channel did its own thing entirely.

The agent didn't know that, because nobody had ever written it down. It wasn’t in the semantic layer, it certainly wasn’t in the training data, it lived entirely in one person's head.

That gap, between an analysis that is technically correct and one that is actually true for your business, is the whole story I want to tell here. Because I think it's where the job of analysts is moving.

The bottleneck moved

For a long time the most valuable thing an analyst did was the analysis itself. Writing the SQL, wrangling the tables, getting the chart to actually say something. That was the craft, and that was the bottleneck, not because it was slow, but because it took a kind of skill not everyone had.

That bottleneck is mostly gone. Agents write queries well. They interpret a vague request and run the analysis well. And now they produce the artifact too, the dashboard, the deck, the PDF, whatever shape you need the answer in. The part that used to take a week takes an afternoon.So what's left?

What's left is everything the model can't see. And it can't see a lot.

Here's the thing people forget about LLMs: they are only ever as smart as the text you put in front of them. Sure, the frontier models can "think" and reason better than ever before.

But in reality there's a limit. If a fact doesn't exist in the training data, doesn't exist in your prompt, doesn't exist in the tables, and doesn't exist in your semantic layer, the model will not know it. Let alone multiple, conflicting definitions.

Instead, it will make an assumption. Sometimes a reasonable one. Sometimes the net-sales-three-ways one. To a trained-eye, someone who “knows their stuff” and has spent a lot of time collecting their domain expertise, these assumptions are glaringly obvious. But to others, these assumptions can be subtle.

This is the new crux in AI-driven analytics. The bottleneck has since moved from generating the analysis to grounding it in business reality. And grounding it is a human job, at least the part that decides what's true.

A semantic layer gets you 70% there

This was actually our founding bet at Gravity. If you want an agent to do real analytics on your data, a well-built (hard to come by!) semantic layer should get you most of the way, call it 70% to 80%. The model knows where to look and how to handle the numbers. It solves a whole class of dumb, early problems that otherwise sink people the moment they point an AI at their warehouse.

But "most of the way" is not "all the way," and the last stretch is the stretch that matters. Semantic layers are rigid. They're expensive to maintain, they eat tokens, and they were never designed to hold the messy, narrative, why-does-this-matter context that actually shapes a decision. The strategy doc. The reason Q3 looked weird. The fact that one region's numbers are always two weeks late.

That stuff doesn't live in a semantic model. It lives in documents, in Slack, in people's heads. So we built a place to put it: a structured knowledge base with a real folder-and-file shape, so you can import the context you already have, scope it to the right project, and let the agent search it.

The scoping turns out to be the quiet hero. When you've got five people testing, a single pile of context is fine. When you've got two hundred, and half of them define "active customer" differently, that pile becomes a minefield. The agent will happily grab a definition from the wrong corner of the org and never tell you. Routing context to the right domain is what keeps the answers trustworthy as you scale. Without it, more context just means more ways to be confidently wrong.

So what does a Context Engineer actually do?

Not "put some text in a Google Doc and call it a day." It's more technical and more thankless than that, which is exactly why I think it becomes a real role.

Day to day, it looks like governing meaning. Deciding what's true when two definitions clash. Encoding the tribal knowledge that's currently trapped in one senior person's head into something an agent can read. Watching where the agent stumbles, because it will stumble, and patching the gap, ideally right when a business user notices it. Putting change control around all of that so the context only shifts when the right people sign off.

The payoff is that the business stops being a thing one person holds in their head. Today, how fast an org can move is capped by how fast knowledge transfers between people. The Context Engineer breaks that cap. They take proprietary expertise out of individual skulls and distribute it across the org, to humans and agents both, so it shows up in the right place at the right moment. You start to get something like a live picture of the company instead of a stale one.

Storyteller or stage builder?

I don't think the Context Engineer is necessarily the storyteller. The end goal of all this is still a narrative, the thing you put in front of an exec or a customer that says here's what happened, here's why, here's what we do next. But the person who understands the implications of the full narrative is usually the business owner, not the technical one.

What the Context Engineer does is build the stage that the stories get told on. They make sure the numbers are real and the definitions don't fight each other, so that when someone steps up to tell the story, the ground under them is solid. They're not building the data pipeline. They're building the context pipeline that feeds it.

And honestly, that stage is also what lets a more technical person finally tell a great story themselves, because now they've got an agent that can shape the narrative for them, on top of context they trust.

Why I'm optimistic

I get that watching an agent do a week of your work in twenty minutes is a genuinely strange feeling. An exciting feeling if it's augmenting the tedious work you’re happy to outsource. Terrifying if you can't see your seat at the table a year out.

So let me be clear about which one I think this is. The role isn't disappearing, it's leveling up. The person who can gather scattered context, organize it so both humans and agents can grip it, and keep it honest as the business changes, that person is more valuable than the one who used to just write the fastest query. It's harder work, it carries more responsibility, and it's a lot more strategic.

The analysis was never really the point. The truth was. That part still needs you.