Context Engineering Is the New Analytics Engineering

There is a quiet role change moving through data teams right now, and most org charts have not caught up to it. The people who used to sit under the label analytics engineer — the ones who took raw source tables, modeled them in dbt, curated dimensions and metrics, and shipped a semantic layer that the rest of the business could trust — are increasingly being asked to do the same job for AI systems. Some of them are being retitled. Many are not. Either way, the substance of the work has already moved.

Practitioners close to the origin of analytics engineering have started pointing at this shift publicly — noting that some of the strongest analytics engineers they know are already doing the same underlying work under a new title, translating business meaning into artifacts an AI system can consume. That is not a marketing rebrand. It is an accurate description of what is happening on the ground in serious AI teams. The underlying craft is unchanged: take business knowledge that lives in senior heads, tribal Slack threads, and undocumented SQL, and turn it into something versioned, tested, and shared. What has changed is the shape of the output. Alongside curated tables and metric definitions, the deliverables now include markdown packs, prompt templates, retrieval corpora, tool schemas, and grounded, cited answers.

The whole of Part 6 of The Context Advantage — the Career part — argues that this transition is the single biggest career opportunity in data since the arrival of the modern data stack. This essay is the concentrated form of that argument, aimed squarely at the analytics engineer, the data engineer, and the BI developer who is quietly wondering whether their skills transfer to the agentic era. They do. In fact, they are exactly the skills the agentic era is starving for.

Before we can talk about what context engineering inherits, it helps to say plainly what analytics engineering actually was — beneath the tooling and the memes.

Analytics engineering was the discipline of taking raw data and turning it into a shared, governed, well-named model of the business. It insisted that a customer meant the same thing in every dashboard. That revenue was defined once and reused everywhere. That a metric had an owner, a definition, and a test. It was not glamorous. It was the difference between an organization that argued about numbers every Monday and one that argued about decisions. The craft was half SQL and half diplomacy — walking into a room where marketing, finance, and product each had a private definition of active user, and walking out with one definition, in code, that survived turnover.

That work built the modern data stack's most valuable and least visible asset: a semantic layer the business trusted. The tools were dbt, the warehouse, a BI layer on top, and a lot of pull requests. The output looked like tables. The real product was shared meaning.

Context engineering does the same job for a different consumer. Instead of a human opening a dashboard, the consumer is an LLM being handed a prompt, a set of retrieved passages, a tool schema, and a policy about what it may act on. The question the analytics engineer used to answer — what does this business actually mean by revenue — is the same question the context engineer answers now, except the answer has to be legible to a model at inference time, not only to a person on a Monday.

Four things stay the same. Sources are still messy and need curation. Definitions are still contested and need owners. Tests are still non-negotiable, because a wrong number that ships is worse than a slow number that does not. And documentation is still the actual deliverable, not the byproduct — the difference between a system people trust and a system people quietly route around.

Three things change. The output surface expands from tables and metrics to include markdown files, prompt templates, retrieval indexes, tool descriptions, and evaluation suites. The consumer expands from humans to include models and agents, which read differently, fail differently, and need different kinds of hand-holding. And the failure mode changes from a wrong number in a dashboard — visible, embarrassing, correctable — to a confident, fluent, wrong sentence in an assistant, which is far harder to notice and far more expensive when it slips through.

That last change is the reason context engineering is not a rebrand. The consumer changed. Everything about how you build for it changes with it.

One of the most underestimated shifts of the last two years is that a growing share of the enterprise semantic layer is being written in markdown and plain files, versioned in git, reviewed like code, and consumed by models. That sentence would have sounded absurd in 2022. In 2026 it is a boring engineering fact.

Why markdown. Because models read it fluently, humans read it fluently, diffs render cleanly, ownership is trackable, and the file boundary is a natural unit of governance. A markdown file that defines what churn means at this company — with the SQL that computes it, the exceptions that apply, the owner who last approved it, and the examples that make it concrete — is a semantic artifact that both a data analyst and an LLM can use without translation. That is a genuinely new capability. For twenty years the semantic layer lived inside a BI tool that a model could not read. Now it lives in files a model can read, and the analytics engineer's craft compounds instead of stopping at the dashboard.

The pattern is spreading well beyond metric definitions. Runbooks, decision policies, glossaries, escalation trees, exception logs, product taxonomies, sales-play definitions, compliance guardrails — the tacit knowledge that used to live in a senior person's head or a Confluence page nobody trusted is being rewritten as structured markdown, tested, owned, and served to agents. The person doing that rewriting is doing analytics engineering. They may or may not be called that.

The clearest way to see the continuity is to walk through a day. Consider an analytics engineer at a mid-sized SaaS company in 2022 versus a context engineer at the same company in 2026.

The 2022 day. A finance leader asks why net revenue retention looks different in two dashboards. The engineer traces the definition, finds that one dashboard uses a legacy formula that excludes a specific product line, files a pull request against the dbt model, adds a test, updates the metric definition, notifies the affected teams, and closes the ticket. Ninety minutes of work. The output is a corrected number that everyone will now see. The real output is a repaired piece of shared meaning.

The 2026 day. A sales assistant powered by an internal agent gives conflicting answers about a customer's contract status to two different reps. The context engineer traces the retrieval path, finds that the contracts corpus has two conflicting versions of the same MSA and no freshness policy, opens a pull request against the contracts context pack (a set of markdown files with the current MSA, the last three amendments, the effective dates, and the approved definitions of terms like renewal window), adds an evaluation case that would have caught the divergence, updates the retrieval filter to exclude superseded versions, and closes the ticket. Ninety minutes of work. The output is a corrected agent answer that every rep will now see. The real output is a repaired piece of shared meaning.

Same job. Same instincts. Different medium. Different consumer. Anyone who has done the 2022 day well will do the 2026 day well — provided they are given the tools, the mandate, and the title.

The tooling picture is less dramatic than the vendor slides suggest. Most of the modern data stack survives, and a few new layers slot in above it.

The warehouse or lakehouse stays. It is still the source of truth for structured business data. dbt, or its equivalent, stays. It is still where metrics and models live, and those metrics are now doubly important because they are the numeric backbone that grounds AI answers. The BI layer stays, and quietly gets a second job: it becomes one of the retrieval sources agents can query when a user asks a numeric question, so the answer comes from the same semantic layer that produced the dashboard rather than a re-derivation in a prompt.

The new layers sit on top. A context repository — usually markdown files in git, sometimes a purpose-built store — that holds definitions, policies, examples, runbooks, and glossaries in a form models can consume. A retrieval layer that indexes the context repository together with unstructured sources, with hybrid retrieval, reranking, and freshness policies. A prompt and tool layer where prompt templates and tool descriptions are versioned artifacts, reviewed like code and evaluated like code. An evaluation layer that treats accuracy, attribution, and refusal behavior as first-class tests rather than vibes.

None of that is exotic. All of it is analytics-engineering values applied to a new surface. The engineer who insisted on tests in dbt is the same engineer who will insist on evaluations for prompts. The engineer who fought for a single definition of revenue is the same engineer who will fight for a single definition of what an agent is authorized to do on a customer record. The habits transfer intact.

For analytics engineers, data engineers, and BI developers who want to make the transition deliberate rather than accidental, there is a short list of skills worth investing in this year.

Retrieval literacy. You do not need to build a vector database. You do need to understand chunking, hybrid retrieval, reranking, freshness, and negative retrieval well enough to argue about them in a design review. Chapter 6 of the book is a compact grounding in this.

Grounding and citation design. Understand how to force a model to answer only from provided material, how to require attribution per claim, and how to design a verifier that catches unsupported sentences. This is the direct equivalent of writing tests in dbt — and it is where most current AI products are quietly failing.

Prompt and tool schema as code. Treat prompt templates and tool descriptions like models: named, versioned, owned, tested, reviewed in pull requests. If a prompt lives in a Notion page nobody has opened in three months, it is not a prompt. It is a liability.

Evaluation. Learn to build small, honest evaluation sets that reflect real production traffic, not synthetic benchmarks. An evaluation suite is to a prompt what a test suite is to a dbt model. The team that has one ships confidently. The team that does not ships and hopes.

Governance fluency. Understand the policy questions that live in the retrieval layer — who can see what, for which task, under which role. This is not a lawyer's job. It is a context engineer's job, informed by legal. If you have ever fought for row-level security in a warehouse, you already have the instinct.

Written communication. The output surface of the job is now largely prose. The engineer who can write a clear, testable definition of a business concept in one page of markdown will be more valuable than the engineer who can write a clever query. Both are useful. Only one is scarce.

The good news is that most teams do not need a reorganization. They need a relabeling and a mandate.

Give the analytics engineering function explicit ownership of the context repository. Not the prompts a product team scribbles into a config file — the shared, governed, versioned context that every AI feature is expected to draw from. That is the same asset the analytics engineering function already owns for dashboards, in a new file format.

Give the BI function a second charter as the numeric retrieval layer for agents. When a user asks an assistant a question that has a real answer in the warehouse, the assistant should reach into the semantic layer, not into free text. The BI team already curates that layer. They should be the ones who wire it up.

Give the data engineering function ownership of the metadata and lineage that makes retrieval trustworthy — versioning, freshness, ownership, approval state, sensitivity classification. These are the same primitives that make a data warehouse governable. They are now the primitives that make an agent explainable.

The AI engineering team, wherever it sits, becomes a consumer of this layer rather than a re-implementer of it. That single organizational move — treating context as a platform, not as each product team's improvisation — is what separates the enterprises where AI compounds from the ones where it fragments. Chapter 23 of the book is our long-form argument for this shape.

It is worth being direct about the economics. Analytics engineering was a well-paid, well-respected specialty inside data teams. Context engineering, as the same craft applied to the fastest-moving surface in enterprise software, is on track to be materially more valuable — because the number of business problems that route through it has multiplied.

In 2022, the semantic layer served dashboards and a handful of embedded analytics. In 2026, the semantic layer serves dashboards, embedded analytics, internal copilots, customer-facing assistants, agent-driven workflows, and an expanding set of automated decisions in operations, finance, sales, and support. Same layer. Ten times the surface area. The people who own that layer are, quietly, some of the most leveraged individuals in their organizations.

None of this requires abandoning the identity. If you are proud of being an analytics engineer, keep being one. Just notice that the frontier of the craft has moved from BI to AI, and the tools have expanded to include markdown, retrieval, and evaluation. The instincts that made you good at the first job are exactly the instincts that make you rare at the second.

If you want to make this real inside your own org before the quarter ends, there is a small, credible starting move.

Pick one business concept that shows up in both a dashboard and an AI feature — customer, account, order, subscription, ticket, product. Write a one-page markdown definition: what it means, how it is computed, which fields it depends on, who owns it, which exceptions apply, and three worked examples. Put it in git. Wire it into your most-used AI feature as a retrieved source. Add one evaluation case that checks the feature uses it correctly. Ship it.

You will have built, in a week, a working prototype of the pattern the rest of the enterprise will need in the next twelve months. You will also have generated the single most persuasive artifact in a promotion or budget conversation: a demonstration that the analytics-engineering craft, in this new medium, ships wins other teams cannot.

Where this lives in the book — direct links:

→ Chapter 4 — What Context Actually Means in AI Systems: /context-advantage/book/chapter-4

→ Chapter 6 — Retrieval, Grounding, and the Semantic Layer: /context-advantage/book/chapter-6

→ Chapter 22 — The New Data Professional: /context-advantage/book/chapter-22

→ Chapter 23 — Context as a Platform, Not a Project: /context-advantage/book/chapter-23

→ Chapter 26 — Careers in the Agentic Era: /context-advantage/book/chapter-26