Context Engineering

An agent can have access to the right information and still fail to use it. A decision gets buried in a long conversation. A search brings back an outdated document. A new session starts without the correction you made yesterday. The person using the product has to notice the mistake, repeat the missing context, and check the answer again.

Context engineering is the work of deciding what information reaches the model, when it reaches it, and what should carry forward. The prompt is part of that work. So are the tools, retrieved documents, conversation history, skills, and memory that shape each response.

This is one of the areas of AI engineering I'm most interested in because it connects system design to everyday usefulness. An agent needs to follow the task at hand, build on previous work, and accept a correction without losing other constraints.

Context changes as the agent works

Imagine asking an agent to investigate a bug. It starts with your description, reads the relevant code, runs a test, and inspects the failure. Each step produces information that can change what it should do next. By the time it proposes a fix, its answer depends on much more than your original request.

Anthropic's explanation of context engineering treats this as an ongoing process of selecting and maintaining the information available to the model. Vercel's guide makes the practical scope clear: instructions, tool definitions, history, tool results, and retrieved documents all contribute to that context.

The challenge is deciding what remains useful. The failing test may be essential. Hundreds of lines from an unrelated search probably aren't. Two conflicting versions of a requirement need to be resolved, even if both fit comfortably in the context window. A larger window gives us room to work; we still have to organize what goes into it.

The harness orchestrates context

The model needs software around it to keep this process moving. That software is the harness: it assembles the model's input, handles its requests to use tools, and brings the results back for the next step. Depending on the implementation, it also manages session state, loads skills, retrieves memory, and summarizes older history.

Harrison Chase's conversation on long-horizon agents helped shape how I think about this. A capable model is one part of an agent. The surrounding system determines how it stays oriented through a task that takes many steps.

It helps to separate three responsibilities. The model interprets the available context and produces a response or tool request. The harness coordinates the loop and the information moving through it. The runtime is the environment where actions execute, with the access controls those actions require.

In the bug investigation, the model might request a test run. The harness routes that request to a tool, receives the output, and includes the relevant result in the next model call. The runtime enforces what the test process can access. A tool request is a proposed action; instructions alone don't grant permission to execute it.

Chase's walkthrough with NVIDIA explores this separation with an open model, Deep Agents, and OpenShell. The useful idea extends beyond that particular stack: context orchestration and execution permissions are distinct responsibilities, even when a framework packages them together.

Memory gives the work continuity

The current session holds the conversation and working state for a task. Long-term memory lets selected information remain available after that session ends. Keeping a transcript is useful, but the next session still needs a way to find the parts that matter.

The CoALA paper offers a useful distinction between three kinds of long-term memory. Applied to an engineering agent, they might look like this:

These are ways to understand what an agent retains, rather than requirements for three separate databases. An episode can provide evidence for a fact or a better procedure. The distinction matters because remembering a past failure and changing how future deployments work have different consequences.

Retrieval brings stored information into the current context. That may mean finding a document in a shared knowledge base or recalling a decision from a previous conversation. Retrieval-augmented generation, or RAG, describes a way to use retrieved information; it doesn't, by itself, determine what an agent should remember about its user.

For a product team, that leaves some concrete decisions: what belongs to an individual user, what can be shared across a project, how old information is corrected, and when a memory should expire. Those choices determine whether continuity feels helpful or becomes a source of repeated mistakes.

Skills make procedures available when needed

Skills are a practical way to package reusable instructions. The Agent Skills format starts with a name and description, allowing an agent to discover relevant procedures before loading their full instructions. Supporting references and scripts can be consulted as needed.

For the deployment example, the agent could discover a deployment skill, read its checklist when preparing a release, and consult a migration reference only if that step requires it. The full procedure doesn't need to accompany every unrelated question.

I find this useful because the procedure becomes something a team can inspect and improve. If the instructions are wrong, there's a specific artifact to revise. If the agent never loads the skill, the problem may be its description or how the harness exposes it. If it follows the instructions and still fails, the procedure itself may need to change.

Skills can include scripts, but their instructions don't replace the runtime's permissions. Knowing how to perform an action and being allowed to perform it remain separate concerns.

Remembering also means revising

Memory introduces a write path as well as a read path. Some systems save information when the agent explicitly requests it. Others extract facts or summarize experiences in the background. Either approach needs a way to handle corrections.

Suppose someone says, “Use the staging environment for this test.” Saving that as a permanent preference would change its meaning. A temporary instruction has become a rule for future work. The system needs to preserve enough context to distinguish a one-time request from a lasting decision.

This is why I care about where a memory came from, when it was recorded, and what can supersede it. Retrieved notes should be treated as information with a source and scope. They shouldn't silently acquire the authority of system instructions.

The same care applies when an agent proposes changes to its own skills. A successful run can suggest an improvement, but one success doesn't establish a reliable procedure. I'd want that change reviewed and exercised against representative tasks before making it the default.

Guillermo Rauch's brain, hands, and files framing connects these ideas to system design. The model and harness coordinate the work, tools act on the world, and files hold things such as skills, memories, and repositories. Separating persistent storage from the execution environment makes it possible to review and consolidate memories without starting the agent's full computer. What an agent retains can have its own lifecycle.

Follow the context when something fails

Chase's discussion also emphasizes traces: the record of the steps an agent actually took. Reading the initial prompt won't tell you which document was retrieved later, which tool output was truncated, or which memory influenced a decision.

An evaluation tells us whether the behavior meets an expectation. A trace helps us investigate why it didn't. In the deployment example, I would check whether the agent loaded the procedure, saw the migration requirement, and received the test result. Each failure points toward a different change.

Long tasks need this scrutiny too. Summarizing older history can keep a session manageable, but the summary has to preserve unresolved constraints and decisions. Delegating research to another agent can keep detailed exploration out of the main conversation, but its returned answer must contain the findings the parent needs. Moving information out of the window only helps if we can recover the right information later.

The infrastructure around an agent makes that work possible. Context engineering determines what the agent carries through it. That's what interests me here: building systems that can accumulate useful knowledge, accept corrections, and put both to work when the next task arrives.