Context Engineering vs Prompt Engineering: What Changed and Why Your Content Is Now the Context

A support agent tells a customer that returns are accepted within 45 days. The help center says 30. Nobody touched the prompt. The agent retrieved an outdated product page and trusted it. That is a context failure, not a prompt failure. It also answers the question many teams now ask. You use CMS content as a knowledge source for LLMs by controlling exactly which governed, structured content reaches the model at each step. In Sanity, agents query the Content Lake with GROQ through the Sanity Context MCP endpoint. They read the current published document, filtered by schema, instead of a scraped copy.

The cost of a context failure goes beyond one wrong answer. Each bad turn reduces trust in the agent. The usual fixes are another paragraph of instructions, a bigger model, or a longer context window. They make each turn slower and more expensive and leave the cause in place. Prompt engineering adjusted the wording. Context engineering, popularized in 2025, governs everything the model sees: instructions, retrieved knowledge, tool results, memory, and structured state.

This guide compares the two disciplines, breaks context into its parts, and ends with a checklist for auditing what your agent receives. The argument is that your content is now the context, so the system that runs your content sets the limit on how well your agent works.

What is context engineering, and how is it different from prompt engineering?

Context engineering is the practice of deciding what an AI agent sees at every step. That includes the instructions, retrieved content, tool results, memory, and structured state that fill its context window on each turn. Prompt engineering is the older practice of writing one better instruction string and expecting the model to generalize from it. The two differ in scope. A prompt is a single input. Context is assembled again on every turn, as the agent calls tools and pulls documents.

The term was popularized in 2025, and Anthropic's essay "Effective context engineering for AI agents" helped set the vocabulary. Sanity's field guidance on production agents describes context engineering as orchestrating what the model knows at every turn. That work needs programming logic: which retrieval runs, which tools load, which session state gets injected, and what gets left out. Writing the instruction text is a separate discipline the same guidance calls agent authoring. It has more in common with editing than with engineering, and people who don't program can own it. Examples include the person who owns brand voice, the support lead who owns escalation, and the product manager who decides what the agent may promise.

Prompt engineering worked when a model answered from its training data in a single chat box. It breaks down for agents because most of their failures have nothing to do with phrasing. When an agent invents a spec or quotes an old policy, rewriting the prompt rarely helps, because the model never received the correct fact. No instruction can make up for a retrieval that came back empty or wrong.

The practical change is ownership. Prompt engineering sat with whoever held the API key. Context engineering is spread across teams. Engineers own the retrieval path and runtime state, content teams own the knowledge, and brand, support, and compliance teams own the instructions. Each of those parts needs a home, a reviewer, and a release process. That is why the content system underneath an agent matters as much as the model on top of it.

What are the parts of an agent's context, and what goes wrong in each?

An agent's context has five parts: system instructions, retrieved knowledge, tool results, memory, and structured state. Each part fails in a different way.

System instructions are a stack of prompts included on every turn. The stack holds the model provider's prompt, the tool descriptions from every connected MCP server, your application prompt, and any per-customer layer. Instructions fail through drift, when someone edits a string in the codebase without an evaluation gate. They also fail through bloat, because tool descriptions use tokens on every request. Ten focused tools beat fifty overlapping ones.

Retrieved knowledge is what most teams mean by context: product catalogs, documentation, policies, and help articles. It fails in two ways. The first is stale content, when the index falls behind the source and the agent quotes last quarter's price. The second is empty retrieval. The search returns nothing useful and the model fills the gap.

Tool results are the outputs of calls the agent makes during a task. They fail through noise, when a tool returns a full record where three fields would do. They also fail through misuse, when overlapping tools leave the model unsure which one to call.

Memory is the notes an agent writes for itself across sessions. Memory fails when old notes outlive the facts they recorded.

Structured state is the per-turn runtime data your application injects, such as who the user is, which plan they are on, and what is in their cart. Engineers most often underbuild this layer, and it is where missing permissions show up. An agent acting under the wrong identity, or without the logged-in user's data, gives a generic answer or exposes something it should not.

All five parts share one failure: too much volume. Even a million-token window doesn't mean you should fill it. Overfilling causes semantic collapse and misdirection, where the model loses track of its task, and it makes every turn slower and more expensive for you and your customers. Most of the work in context engineering is removing things.

Why is structured content easier to turn into precise context than HTML or PDFs?

Structured, schema-defined content is easier to turn into precise context because every fact sits in a named field that the retrieval step can filter on. HTML blobs and chunked PDFs make the agent guess which fragment holds the answer. Take a request like "size L latex gloves, under $200 a pallet." Against a product schema, that request is a filter: size is L, material is latex, and price is under 200. Against a scraped product page, it becomes a similarity search over text chunks, and the size table and the price may land in different chunks.

Pure vector retrieval can't enforce structural constraints like a version number, a category, or "in stock," because vector similarity ignores all of them. The query comes back empty or wrong, and the model either hallucinates or hedges, depending on its instructions. A better model doesn't fix this. The fix is to give the retrieval step the shape of the data as well as its text.

Chunking makes the problem worse. A PDF cut into fixed-size windows loses its headings, its tables, and the link between a policy and the product it applies to. An HTML page brings navigation, footers, and marketing copy that take up room in the window next to the fact you need. The model has to reason past every irrelevant token you retrieve.

Schema-defined content keeps relationships intact. A product document links to its category, its variants, and its warranty policy as typed references. An agent can follow that chain of references instead of hoping two chunks land in the same result set. A schema explorer can also show what fields mean: which field holds the customer-facing name, which holds an internal code, and which values are deprecated.

Prose still matters. Descriptions, guides, and support articles hold details that no filter captures, and semantic ranking is useful there. What matters is the order of operations. Filter on structure first so the candidate set is correct, then rank the remaining prose by meaning. Content modeled as data supports both steps. A blob supports only the second.

How do you use CMS content as a knowledge source for LLMs?

You use CMS content as a knowledge source for LLMs by giving the agent a governed query interface. That interface reads the live content store, filters on schema, and ranks prose by meaning, with no export to a separate index. In Sanity Context, agents connect to the Sanity Context MCP endpoint. It is a hosted, read-only endpoint with three tools: `initial_context`, `groq_query`, and `schema_explorer`. The agent learns the shape of the data from the deployed schema, then writes GROQ against the Content Lake.

GROQ mode queries the dataset at request time. It requires a deployed schema (`sanity schema deploy`, Studio v5.1.0 or later). In return there is no build step and nothing to keep in sync. Some catalogs keep useful detail in prose fields. For those, dataset embeddings let a single GROQ query combine hard filters with semantic similarity:

*[_type == "product" && category == $category && price < $maxPrice && stockLocation == $warehouse] | score(boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText)) | order(_score desc)[0...10]

The predicates do the filtering that has to hold. The `score()` pipeline blends a BM25 keyword `match()` on the title, weighted 2x with `boost()`, with `text::semanticSimilarity()` across the whole document. Embeddings are tied to the content, so an edit reaches retrieval without a separate re-embedding pipeline. Dataset embeddings are opt-in and off by default.

Some knowledge lives outside any dataset. Knowledge Bases (in beta) build an index ahead of time over datasets, website subfolders, and PDFs. They reconcile those sources into entries with citations and serve them through the same Context MCP. Watch for one configuration trap. If a single MCP has both a dataset source and Knowledge Base sources, the dataset source wins without any warning. Add `?mode=groq` or `?mode=knowledge_base` to choose the mode explicitly.

Who should own an agent's instructions, and how should changes ship?

The people accountable for an agent's behavior should own its instructions. Changes should go through the same review, staging, and release process as the rest of your customer-facing content. In most teams today the application prompt is a string in the codebase. Marketing can't read it, compliance can't review it, and every wording change waits for a deploy.

Engineers often object that a system prompt is behavior, not content, and the objection is fair. Taken seriously, though, it calls for versioning, review, validation, and a test gate. A content backend provides the first three natively, and evaluations in CI provide the fourth. The working rule is to author it like content and gate it like code, in the same system.

In Sanity, the application prompt is a document of type `agentPrompt` with fields for role, voice, userContext, escalation, and mustNotSay. Each field has an owner. Brand owns voice, Product owns how the agent uses user context, Support owns escalation, and Compliance owns the never-say list. Splitting the prompt into fields is a form of access control. None of those owners files a pull request or waits for a deploy.

Because the prompt is content in the Studio, it gets real-time collaboration, version history, scheduled publishing, and rollback. With Content Releases, a team stages agent behavior the same way it stages a website launch. It previews the change, then ships knowledge and instructions together.

Sanity is the AI Content Operating System, the intelligent backend for companies building AI content operations at scale. A CMS with AI bolted on keeps the agent's instructions somewhere else. In Sanity, the agent's knowledge and its instructions live in one governed system. Legacy CMSes stop at publishing. Sanity operates content end-to-end, including the content that tells an agent how to behave.

What does it cost to keep agent context fresh with a vector database versus a content backend?

Keeping agent context fresh costs the most when content and its search index live in separate systems. Every edit, deletion, and schema change then has to travel through a pipeline your team builds and runs. Hybrid retrieval itself is widely available. PostgreSQL with pgvector and full-text search, Elasticsearch, Algolia, and Pinecone with a metadata filter layer can all blend keyword and semantic ranking. The difference is who maintains the plumbing.

With a separate vector database, the team owns incremental indexing, re-embedding on change, deletion handling, and backfills whenever the schema changes. Each task is solvable on its own. Together they make freshness a permanent line item on your roadmap. A lag in any one of them produces the stale-content failure, where the agent confidently cites a price or policy that changed last week.

Content backends with AI add-ons fall in between. Contentful provides structured models and APIs, and teams usually connect retrieval to an external search or vector service through the App Framework. Strapi teams often follow LangChain.js tutorials to do the same. The content is structured, but retrieval lives in another system, so the sync problem comes back.

Agent platforms that handle retrieval for you remove the pipeline work by crawling your site and indexing pages. The cost is accuracy. A crawler sees rendered HTML, not your schema, and it rarely sees the logged-in user's data. That data is the per-turn state layer teams most often underbuild.

Lock-in cuts both ways. A proprietary agent platform holds your retrieval logic, and a hand-built pipeline consumes your engineers' time. In Sanity Context, retrieval runs where the content already lives. GROQ predicates and `text::semanticSimilarity()` run inside the Content Lake against dataset embeddings tied to the documents, so there is no second store to reconcile. The cost question shifts from which sync job broke overnight to which content is worth modeling well.

When is prompt engineering enough, and when do you need context engineering?

Prompt engineering is enough when the model can answer from general knowledge, the task takes a single turn, and a wrong answer costs little. Drafting a subject line, summarizing a pasted document, and rewriting a paragraph in a set tone all fit. The context is whatever the user supplies, and a well-written instruction does most of the work.

You need context engineering when any of four conditions applies:

- The agent answers questions about your products, policies, or documentation, so it depends on retrieved knowledge.
- The right answer depends on who is asking, which brings in per-turn state and permissions.
- The agent calls tools, so tool descriptions and results compete for space in the window.
- More than one team needs a say in how the agent behaves, so the instructions need owners and a release process.

Those conditions also help you choose a setup. Suppose only the first one applies, and your content is small and rarely changes. A vector index with a careful sync job can work. If the content changes weekly, carries structural constraints, or spans many sources, the sync job turns into a product you have to maintain. If the instructions change faster than engineering can ship them, move them out of the codebase.

When several of these conditions apply, the content system decides the outcome. Rigid CMSes force you to scale people by adding engineers to keep indexes and prompts current. Sanity scales output instead. The Content Lake holds the knowledge. GROQ retrieves it precisely, with filters and semantic ranking in one query. The Studio gives each instruction field an owner, and Content Releases ship knowledge and behavior together. Sanity Context connects all of it to agents through the MCP endpoint.

Moving from prompt engineering to context engineering means recognizing that your content is now the context. The system that governs that content sets the upper limit on what your agent can do.

How do you audit an agent's context window?

To audit an agent's context window, capture exactly what the model received on real turns. Then go layer by layer and decide what to cut, filter, or add. Pull a sample of production traces that includes failed conversations, and work through this checklist.

1. Measure the fixed cost. Count the tokens used by the provider prompt, the MCP tool descriptions, and the application prompt before the user says anything. If tool descriptions dominate, consolidate them, because ten focused tools beat fifty overlapping ones.
2. Find empty retrievals. For every hallucinated answer, check whether retrieval returned anything relevant. If it didn't, fix the query or the content model, not the prompt.
3. Check structural constraints. Flag questions that include a version, category, price, or stock condition. These need filters, not similarity search alone.
4. Cut noise from tool results. If a tool returns whole documents, project only the fields the task needs. In GROQ, that means an explicit projection instead of the full record.
5. Verify freshness. Edit a test document and time how long it takes for the agent's answer to change. If it takes hours, your index is a separate system with its own sync lag.
6. Look for conflicting sources. When two documents disagree, decide which one is ground truth and record that decision. Knowledge Bases (in beta) flag these conflicts as Issues, showing the claims side by side with their sources.
7. Confirm identity and permissions. Check that per-turn state carries the right user, and that the agent never acts with broader permissions than the person asking.
8. Assign owners. Every instruction field should have a named team, a review step, and an eval gate before release.
9. Prune memory. Expire agent notes that refer to facts that have since changed.

Failures at steps 2, 3, 5, or 6 point to a problem in the content system. Failures at steps 1, 4, or 8 point to a problem in orchestration. Empty retrieval is the most common cause of hallucination, so expect most of your findings to come from the content system.