What is context engineering?

A large language model is a function of its input. The weights are fixed at training time; the only thing you control at run time is the context. That makes context the entire interface between your world and the model's capabilities — and engineering it well is the difference between an assistant that knows your project and one that produces plausible generalities.

From prompt engineering to context engineering

In 2023, "prompt engineering" meant hand-crafting magic words: role-play framings, chain-of-thought incantations, exotic formatting. Some of it worked, much of it was folklore, and nearly all of it aged badly as models improved. What didn't age is a simpler observation: models answer better when the right information is in front of them.

Context engineering generalizes the prompt into a pipeline. Instead of asking "what should I type?", it asks:

• What stable instructions should govern this task?
• Which documents should be retrievable, and how should they be chunked and indexed?
• What memories — durable facts about the user or project — should be recallable?
• Which tools can the model call to fetch what it doesn't have?
• What doesn't belong in context, because it dilutes attention or leaks information?

The shift matters because context is a scarce resource. Even huge context windows degrade in practice — models attend unevenly across very long inputs, and every irrelevant token you include competes with the relevant ones (see AI context windows explained). Good context engineering is as much about exclusion as inclusion.

The four pillars

1. Instructions

Standing guidance: who the assistant is, what conventions to follow, what a good answer looks like. The failure mode is bloat — pasting an ever-growing "system prompt" into every conversation. The engineering move is to store procedures separately and load them on demand: a deployment checklist when deploying, a style guide when writing, nothing when neither applies.

2. Knowledge

The documents that define your world: specs, reports, research, manuals. Models can't know them, so systems retrieve them — chunked, embedded, and searched by semantic similarity at query time. This is retrieval-augmented generation, and the retrieval quality ceiling is set by corpus curation: what you uploaded, how current it is, and whether near-duplicates are polluting results (how retrieval works).

3. Memory

Discrete facts that accumulate over time: decisions, preferences, names, constraints. Unlike knowledge, memory is written by the AI itself during use — "remember that we chose PostgreSQL" — and recalled semantically later. Memory answers "what do we know about us?" where knowledge answers "what do the documents say?" The distinction is worth internalizing: we compare them fully in AI memory vs RAG.

4. Tool results

Live context fetched during the conversation: search results, database rows, API responses. The engineering questions are which tools to expose, how to describe them so the model calls them appropriately, and how much of their output to admit into the window.

Why it decides output quality

Consider the same question — "Should we support SSO in the beta?" — posed to two assistants. The first has generic context and answers with a balanced essay about SSO trade-offs. The second retrieves your product spec (knowledge), recalls that enterprise deals were deprioritized in May (memory), and loads your decision-log template (instructions). Its answer cites the spec, references the May decision, and formats the recommendation the way your team records decisions. Same model. Different context. Only one of the answers is useful.

This is the general pattern: hallucination is usually a context deficit. Models guess when they lack grounding. Fill the gap with retrievable facts and the guessing largely stops — along with the re-explaining, the generic advice, and the "as an AI, I don't have access to..." dead ends.

Context engineering without infrastructure

Historically, practicing this meant building: a vector database, an embedding pipeline, chunking heuristics, a retrieval API, and integration code per AI client. That's a real engineering project, which is why context engineering stayed the domain of AI teams.

The Model Context Protocol (MCP) changed the integration half: any compliant client can consume any compliant tool server. Hosted context layers changed the pipeline half. VeelIQ Context, for example, packages the whole stack — upload, chunking, embeddings, semantic search, memory, instructions — behind one personal MCP URL. Curating context becomes an editorial act: upload the right documents, save the right facts, organize workspaces that keep contexts from bleeding into each other.

A starter practice

1. Inventory — list the 10 documents you reference most and the 20 facts you keep re-explaining to AI tools.
2. Load — upload the documents to a knowledge layer; save the facts as memories.
3. Separate — split contexts that shouldn't mix (clients, projects, personal) into workspaces.
4. Observe — watch whether answers start citing your sources. Grounded citations are the success signal.
5. Prune — remove stale documents and dead facts monthly. Retrieval quality is corpus hygiene.

Key takeaways

• Context engineering is the run-time discipline of deciding what a model sees; it has largely superseded prompt tricks as the quality lever.
• Its four pillars are instructions, knowledge, memory, and tool results — each with distinct storage and retrieval patterns.
• Exclusion matters as much as inclusion: irrelevant context degrades attention and wastes tokens.
• MCP and hosted context layers have made the practice accessible without building retrieval infrastructure.

Related reading