What is context engineering for AI agents? (And who should actually do it)

The short answer

Context engineering for AI agents is the discipline of deciding what an agent needs to know, sourcing that knowledge, testing it, keeping it current, and delivering the right slice of it at the moment the agent acts. Prompt engineering is one instruction for one task. Context engineering is everything else the model sees.

The term covers two kinds of work. For the engineers building an agent, it means managing the context window: retrieval, memory, compaction, and tool results. For the organization deploying that agent, it means managing the knowledge that goes into the window. This guide concentrates on the second, because for AI data agents that knowledge is your metric definitions, business rules, table relationships, and what your senior analysts carry in their heads, and it is the half that fails most often.

The work is substantial and it never ends, because context has to keep pace with a business that keeps changing (and businesses are changing faster than ever). That leaves most data teams asking the same question: who does it? A common recommendation is to hire context engineers or stand up a dedicated team. We agree that context needs an owner. We disagree that the owner should write it by hand, because hand-written context falls behind the business within a quarter. Our position is that context engineering on enterprise data should be done mostly by agents that build, test, and maintain context from real usage, with your data team as the primary reviewer who approves each change.

What is context engineering for AI agents?

Context engineering for AI agents is the practice of designing, sourcing, validating, and maintaining the information an agent has available when it reasons and acts. The prompt is one input. The context is everything around it: instructions, retrieved documents, tool definitions, memory, examples, and the business knowledge specific to your company.

The term took hold in mid-2025, when practitioners including Shopify's Tobi Lütke and AI researcher Andrej Karpathy argued that "prompt engineering" undersold the real skill, which is filling the model's context window with the right information for the next step. Two definitions are now widely cited:

• Anthropic describes context engineering as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts."
• Gartner defines context engineering as "designing and structuring the relevant data, workflows and environment so AI systems can understand intent, make better decisions and deliver contextual, enterprise-aligned outcomes — without relying on manual prompts."

The two definitions point at different halves of the same job. Anthropic's is about the context window: what goes into the model on each call, and how to keep it small and high-signal. Gartner's is about the organization: where the knowledge comes from, who governs it, and how it stays aligned with the business. An enterprise needs both halves. The second half is the one that fails most often.

What's the difference between context engineering and prompt engineering?

Prompt engineering is writing the instruction for a single task; context engineering is building and maintaining the system that supplies everything else the model needs to do that task correctly. A better prompt improves one answer. Better context improves every answer that depends on it.

That last row is the one that matters on enterprise data. A weak prompt usually fails in a way you can see. Stale context fails quietly: the SQL runs, the chart renders, and the number is wrong.

What does context engineering involve for AI data agents?

Context engineering for AI data agents involves five jobs: collecting business knowledge from the systems where it lives, structuring it so an agent can retrieve it, testing it against answers your experts trust, keeping it current as the data changes, and governing who can see and change it.

The reason it is harder for data than for documents is that a wrong answer looks exactly like a right one. A model pointed at a raw warehouse can write valid SQL against the wrong revenue column all day. As we covered in why AI data agents hallucinate, the schema tells the model what columns exist. It says nothing about which one finance reports on.

Each of the five jobs has a concrete output:

• Collection produces a knowledge base. Table and column documentation, metric definitions, join paths, and business rules, drawn from the warehouse, query history, dbt models, BI tools, wikis, and Slack.
• Structuring produces retrievable units. Knowledge organized by domain, table, metric, and rule, so the agent loads what the question needs and nothing else.
• Testing produces evals. Questions with expected answers, generated from the knowledge base and the dashboards your team already trusts, then scored on a schedule.
• Maintenance produces a queue of fixes. Schema drift, broken metric SQL, conflicting definitions, and gaps the agent hits in real questions, each one routed to someone who can resolve it.
• Governance produces a boundary. Read-only credentials, per-user permissions, and a record of which knowledge supported which answer.

The labs that build the models reached the same structure for their own analytics. OpenAI's write-up of its in-house data agent describes layers of context above the warehouse and continuous evals. Anthropic's post on self-service analytics with Claude frames analytics accuracy as a context and verification problem. The output of all this work is usually called a context layer.

Why does hand-built context decay?

Hand-built context decays because the business changes faster than people can document it, and nobody's job is to keep up. New tables ship, metrics get redefined, a reorg moves ownership, and the analyst who knew why Q3 was restated takes another job. The documentation was accurate on the day it was written.

Our co-founders described the pattern in the data context trap. Teams that build a context layer by hand tend to move through seven stages:

1. Enthusiasm. The top 20 metrics are documented in a repo and accuracy jumps.
2. The long tail. Real questions need context nobody wrote down.
3. The quality crisis. A subtly wrong definition produces a plausible number that reaches a leadership meeting.
4. The security crisis. The context was built from one over-privileged user's access.
5. The maintenance problem. The warehouse keeps changing and the context does not.
6. The political problem. Finance, product, and operations each have a correct definition, and nobody owns which applies when.
7. Quiet abandonment. The project is partly complete, partly stale, and nobody's job.

Context engineering is three problems stacked: collection, validation, and maintenance. Solving one or two of them is not enough. A team that collects context without testing it ships wrong answers with more confidence. A team that tests context without maintaining it watches its pass rate fall every month.

Do you need to hire a context engineer?

Most data teams do not need to hire a context engineer; they need context engineering to get done, and most of it can be done by agents with the data team approving the results. The distinction matters because "context engineer" is quickly becoming a job title, with open roles, vendor certifications, and analyst guidance recommending a dedicated lead or team.

Part of that guidance is right. Someone has to be accountable for what the AI believes about the business. Gartner's recommendation to assign clear ownership for context is sound, and the data team is the natural owner.

The part we disagree with is the assumption that ownership means authorship. A role built around writing and updating context by hand has the same flaw as the hand-built semantic layer before it: output scales with headcount, and the backlog grows with every new table and every new question. Hiring three context engineers makes the data context trap arrive more slowly. It still arrives.

Consider what the daily work of that role would be: noticing that the agent was unsure, finding which table and which definition were involved, searching dbt, the BI tool, and the wiki for an answer, asking the person who knows, writing the update, and adding a test so it does not regress. Every step except "the person who knows confirms it" is work an agent can do.

So the useful question is how much of the context engineering can be automated, and how little expert time the remainder takes. A dedicated team makes sense in a narrow set of cases, which match the conditions for building in-house at all: engineers who are free for six months or more, a decision to run context as a product with its own roadmap, and metric definitions already aligned across functions.

How do you manage AI agent context at enterprise scale?

Managing AI agent context at enterprise scale means letting real questions drive what gets built, having agents do the investigation and drafting, and reserving human time for approval. Trying to model everything up front does not scale, because nobody knows in advance which context will matter.

This is the model Delphina is built on, and the one we would argue for. The alternative is model-first: the data team documents the business before anyone can trust an answer. It takes quarters, and it guesses at demand. A demand-driven approach starts from a baseline built automatically from what already exists, then improves wherever real questions expose a gap:

1. Someone asks. A question arrives in the app, in Slack, or from another agent.
2. The gap is identified. When the agent lacks a definition or finds two that conflict, it says so instead of guessing.
3. An agent investigates. It searches dbt, BI, and documentation, and identifies the person most likely to know.
4. An expert confirms. The owner approves or corrects a drafted answer. This takes seconds, and it happens where they already work.
5. The fix becomes a test. The knowledge is updated and an eval is saved to guard it.
6. The answer is served. It goes back to the person who asked, and it is right for everyone who asks after them.

The two operating models compare like this:

Automation of this kind only works if the humans keep control. AI-managed context needs to come with simple tools for reviewing, editing, and overriding what the agents propose, so that a finance partner can correct a revenue definition without filing a request to the data platform team.

How does LLM memory fit into context engineering?

LLM memory is one input to context engineering, and for enterprise data it has to be governed like any other knowledge. Memory lets an agent retain what it learned in earlier sessions, which removes the need to re-teach it the same definition every week.

Three properties separate enterprise-grade memory from a personal assistant remembering your preferences:

• Shared memory beats personal memory. A definition one user taught the agent should improve answers for everyone, after review. Memory that stays private to each user produces a different answer for each user.
• Reviewed memory beats automatic memory. An agent that silently memorizes whatever a user tells it will memorize mistakes. Corrections should pass through the owner of that metric before they become shared knowledge.
• Tested memory beats trusted memory. Each remembered rule should be backed by an eval, so a later change that breaks it is caught.

Memory that meets those three conditions is no longer a separate feature. It is the maintenance loop of the context layer.

What should the data team own?

The data team should own the decisions that require judgment: which definition is canonical, who is allowed to see what, what counts as a correct answer, and whether a proposed change is approved. Those are the parts of context engineering that cannot be delegated to an agent.

In practice that comes down to four responsibilities:

• Approving changes. The data team is the primary reviewer of what the agents propose. Analysts can see every answer and step in on any of them, without having to approve each one.
• Settling conflicts. When finance and product define "active customer" differently, a person decides which applies in which setting, and the context records that decision.
• Setting the boundary. Permissions, sensitive data rules, and the sources agents may read are policy decisions.
• Reading the evals. A falling pass rate is the earliest signal that the business has moved and the context has not.

This is a larger job than writing documentation. The data team stops being the group that answers every question and becomes the group that owns what the company's AI knows.

How Delphina approaches context engineering

Delphina is the AI Context Factory: the fastest way to build, validate, and maintain an enterprise context layer for agentic analytics. We built it on the position argued above. Instead of asking your team to write and maintain context, Delphina puts knowledge agents to work.

• Build. Agents distill a baseline from what you already have, including your warehouse, query history, and existing documentation. Baseline context is ready in a day.
• Test. Evals are generated from your knowledge base and scored on a schedule, and a Critic reviews every answer in the background for clear questions, grounded context, sound logic, and safe assumptions.
• Investigate. When the agent is unsure, knowledge agents trace the gap to the upstream assets and to the expert who knows the answer.
• Approve. Your data team approves the fix. Easy editing tools keep people in control of what the agents propose.
• Ship. The knowledge is updated, the fix is guarded by a test, and every later answer improves. This is the knowledge flywheel: context gets better every time someone asks a question.

People use Delphina in the Delphina app and in Slack, asking questions in plain language and getting the chart, the table, and the SQL behind each answer. Workflows and Data Apps let agents and users without any code create automated reports, generative dashboards, and high-impact analysis on demand or pushed when there are updates. An MCP server (Model Context Protocol, the standard for connecting agents to tools and data) plays two supporting roles: connecting Delphina to additional sources, and giving Claude Code, Cursor, Codex, and custom internal agents access to the same approved context.

Delphina powers AI analytics up to the CEO at data-forward companies from Substack to LATAM Airlines, serving data teams, non-technical business users, and even CEO power users. Across our customers, 73% of active users are outside the data team. Queries are read-only, analysis runs in an isolated sandbox with no internet access, and Delphina deploys as SaaS or inside your own AWS account.

The bottom line

Context engineering is the right name for the work that makes AI agents accurate on enterprise data, and it is permanent work. Treating it as a new hand-authoring job repeats what happened to many hand-maintained documentation projects, which were accurate at launch and behind the business a few quarters later.

The teams that get this right keep the judgment and hand off the labor. Agents build the context, test it, find the gaps, and locate the person who knows. The data team approves. That is how context stays current when the business changes every week.

Delphina is the AI Context Factory for the data team. Knowledge agents build, test, and maintain the context your AI needs, and your data team approves every change. Book a demo with your data to see the factory run on your own questions.

Frequently asked questions

What is context engineering for AI agents?

Context engineering for AI agents is the discipline of deciding what an agent needs to know, sourcing that knowledge, testing it, keeping it current, and delivering the right part of it when the agent acts. Context engineering covers everything the model sees beyond the prompt, including instructions, retrieved knowledge, tool definitions, and memory. For AI data agents, context engineering centers on metric definitions, business rules, table relationships, and the knowledge experienced analysts hold.

What's the difference between context engineering and prompt engineering?

Context engineering builds and maintains the system that supplies an AI agent with knowledge, while prompt engineering writes the instruction for a single task. Prompt engineering improves one answer at a time. Context engineering improves every answer that draws on the same definitions, and it is never finished, because the underlying business and data keep changing.

Do I need to hire a context engineer?

Most data teams do not need to hire a context engineer. Context engineering needs a clear owner, and the data team is the natural one, but most of the labor (finding gaps, searching existing assets, drafting updates, writing tests) can be done by agents. A dedicated context engineering team makes sense mainly for organizations that have decided to build their context layer in-house and can staff it for six months or more.

How do I manage AI agent context at enterprise scale?

Managing AI agent context at enterprise scale works best as a demand-driven loop. Agents build a baseline from existing assets, real questions expose the gaps, agents investigate and draft fixes, experts approve them, and each approved fix becomes a test. Modeling everything up front does not scale, because it takes quarters and guesses at which context will matter.

How do you maintain context for AI agents over time?

Maintaining context for AI agents over time requires three mechanisms working together: detection of change (schema drift, broken metric SQL, conflicting definitions), evals that run on a schedule to catch regressions, and a short path from a detected gap to an approved fix. Context that depends on someone remembering to update a document goes stale quickly: within days at a fast-moving organization, and within a quarter at most others.

How does LLM memory management work for enterprise data?

LLM memory management for enterprise data works by turning what an agent learns into shared, reviewed, tested knowledge. Enterprise memory differs from personal assistant memory in three ways: a correction should benefit every user, the owner of a metric should approve a correction before it is shared, and each remembered rule should be backed by an eval that catches later breakage.

Is context engineering the same as building a context layer?

Context engineering is the ongoing work, and a context layer is what that work produces. A context layer is the maintained body of definitions, rules, relationships, and tests that AI agents reason against. Context engineering is how the context layer gets built and kept current, whether by a team writing it by hand or by agents with human approval.

What is a context factory?

A context factory is a system in which agents help do the context engineering and people focus more on approving the results. Agents build context from existing assets, test it with evals, investigate gaps when a question exposes one, and ship the update once an expert confirms it. Delphina is the AI Context Factory, and it delivers baseline context in a day.