When I wrote Context Engineering: The Craft of AGENTS.md, the focus was entirely on the repository. The goal was to give a coding agent enough durable knowledge (architecture rules, naming conventions, testing procedures) that it stopped guessing and started acting like a capable junior engineer who actually read the onboarding docs.

That solves the repository problem. But when you move from a coding assistant on your laptop to an autonomous agent running in production, the stakes change. A production agent does not just need onboarding documents; it needs a runtime environment. It needs to know what evidence to trust, which actions are safe, when to stop, and how its work will be judged.

This is the operational side of context engineering. It is the shift from treating an agent as a prompt-in-a-loop to treating it as a production dependency. The model is not the agent. The production system is the agent.

In this guide, we will break down how to engineer the context package that surrounds a production agent. We will cover how to structure an evidence supply chain, how to enforce boundaries that keep the useful thing the safe thing, and how to build evaluations that judge the outcome rather than the confidence.

Start with a context contract, not a giant prompt

The most common failure mode in early agent deployments is the "junk drawer" system prompt. A team realizes the agent is making mistakes, so they paste in the employee handbook, the API documentation, the last five customer transcripts, and a list of thirty rules that all begin with "NEVER."

As Anthropic notes in their research on effective context engineering, context is a finite resource with diminishing returns. [1] Large language models suffer from context rot: as the haystack grows, the model's ability to reliably find the needle degrades. Every new token introduced depletes the model's "attention budget." [1]

Instead of a giant prompt, a production agent needs a versioned context contract. This contract defines exactly what the agent knows, what it is allowed to do, and what constitutes a finished job. Every item admitted to the context must have a clear job, an identifiable owner, and a refresh policy. If a piece of context does not change the agent's behavior or prevent a specific failure, it should be removed.

Sources: design an evidence supply chain

A production agent operates on evidence. If you feed it stale data, it will confidently execute the wrong action. Context engineering requires designing an evidence supply chain that distinguishes between four classes of information.

Source Class	Description	Examples	Authority & Freshness Rule
Stable Operating Instructions	The foundational rules, tone, and escalation paths.	System prompts, constitution.md, tool schemas.	Version-controlled and deployed with the application code.
Authoritative Runtime Facts	The ground truth required to make a decision.	Live database queries, CRM records, current inventory.	Retrieved just-in-time via tools; never cached in the prompt.
Task-Local User Input	The specific request or trigger event.	An incoming email, a webhook payload, a Slack message.	Validated and sanitized before reaching the agent.
Working State	The agent's memory of what it has done so far on this task.	Tool execution results, intermediate decisions, active errors.	Compacted regularly; cleared when the task completes.

That first row is its own discipline. If you have never written a constitution for an agent, The Agent's Self is the long version of how to give one a stable identity and voice that survives contact with production.

The rule for evidence is simple: just-in-time retrieval beats preloading. Rather than stuffing a massive knowledge base into the context window, give the agent lightweight references such as file paths, stored queries, or search tools, and let it pull exactly what it needs. [1] When sources conflict, the system must enforce a clear hierarchy: the authoritative system of record wins. If the agent cannot determine the truth, it must escalate.

Boundaries: make the useful thing the safe thing

An agent without boundaries is a liability. You cannot rely on a soft prompt instruction like "please be careful with the database" to prevent destructive actions. Boundaries must be enforced by the environment, not just requested in the context.

There are five boundaries every production agent needs:

Boundary Type	What It Protects	The Rule	Agent Response
Data Boundary	Privacy and tenant isolation.	The agent only receives credentials scoped to the current user or tenant.	"I cannot access that record."
Authority Boundary	Destructive or high-impact actions.	Read operations are autonomous; write/delete operations require a human-in-the-loop approval token.	"I have drafted the refund. Please approve to execute."
Action Boundary	Tool scope and complexity.	Tools do exactly one thing. No "god tools" that accept arbitrary SQL or bash scripts.	The agent uses specific, constrained tools sequentially.
Context Boundary	The attention budget.	The context window is strictly limited. Transcripts are compacted; old tool results are dropped.	The agent requests a summary or specific historical fact if needed.
Escalation Boundary	Infinite loops and hallucinations.	If the agent repeats an action, receives three consecutive tool errors, or hits a token limit, the run terminates.	"I am stuck. Escalating to a human operator."

In practice, enforcing an authority boundary looks like this in your orchestration layer:

async function executeAgentAction(action: AgentAction, context: ScopedContext) {
  if (action.type === 'REFUND_CUSTOMER' && action.amount > 50) {
    if (!context.approvalToken) {
      // Throw back to the agent so it knows it must ask the user
      return {
        status: 'APPROVAL_REQUIRED',
        message: `Refunds over $50 require human approval. Ask the user to confirm.`,
      }
    }
  }
  return await runTool(action)
}

The boundary is enforced by the system, but the agent receives clear, actionable context about why the action was blocked and what to do next.

Working state: preserve decisions, not transcripts

When an agent operates over many turns, the transcript grows quickly. A common mistake is treating the raw, unedited transcript as the agent's memory. This leads to bloated contexts, increased latency, and a higher risk of the agent losing the thread of the task.

Working state should preserve decisions, not every conversation turn. Instead of passing a 50-message transcript, implement a compaction step that distills the state into a structured schema.

A compact task state should include:

• The goal: the original, unmodified objective.
• Current facts: the verified evidence retrieved so far.
• Decisions made: the irreversible choices the agent has committed to.
• Completed actions: a list of successful tool executions.
• Next safe step: the immediate action the agent intends to take.

This approach, which aligns with the profile and board architecture we explored in Running the Fleet, ensures the agent always has a clear view of its progress without drowning in the noise of its own past reasoning.

Compaction matters most when nobody is watching. If your agent runs unattended on a schedule, the same discipline is what keeps a long-running loop from drifting off the goal; Loop Engineering covers that side of the problem.

Evaluation: judge the outcome, not the confidence

The capabilities that make agents useful (autonomy, flexibility, multi-step reasoning) also make them incredibly difficult to evaluate. A traditional unit test checks if a function returns true. An agent evaluation must check if the agent correctly navigated an environment, used the right tools, and achieved the desired outcome without causing collateral damage. [2]

Building that harness properly is a topic of its own, and I have written it up separately in Eval-Driven Development. What follows is the part that touches context directly.

A production agent must have an externally observable definition of done. You cannot rely on the agent saying, "I successfully completed the task." You must verify the environment.

Effective agent evaluation operates in three layers:

1. Code-based graders: deterministic checks that verify the outcome. Did the agent actually insert the row into the database? Did the code compile? Did the tool calls match the expected schema? These are fast, cheap, and objective. [2]
2. Model-based graders: LLM-as-a-judge evaluations that assess quality and adherence to the agent's constitution. Did the agent's response match the brand tone? Did it correctly summarize the retrieved context? These handle nuance but require calibration against human judgment. [2]
3. Human review: the gold standard for high-impact or ambiguous tasks. Use human grading to spot-check the model-based graders and establish the initial quality baseline. [2]

When building your evaluation suite, distinguish between capability evals and regression evals. Capability evals test the frontier of what your agent can do; they should have a low pass rate as you hill-climb toward better performance. Regression evals test the established baseline; they should have a near-100% pass rate, and any failure should block a deployment. [2]

As I covered in How to Use Claude Code to QA Your Website, the best way to run these evaluations is to have an agent do it. Define the expected outcomes, give the QA agent a safe test environment, and let it run the scenarios on every deploy. QA in the Era of AI is the longer version of that argument.

A practical 70/30 context audit

Before you add another tool or switch to a larger model, run this 60-minute audit on your existing agentic system (the 70/30 framing comes from The 70/30 Engineer). Score each question as Green (systematized), Amber (partially handled), or Red (missing or ignored).

1. Objective: is the agent's goal defined as a measurable outcome rather than a vague instruction?
2. Sources: does the agent retrieve facts just-in-time from an authoritative system of record?
3. Relevance: is the system prompt free of aspirational rules that the agent routinely ignores?
4. Boundaries: are destructive actions blocked by system-level approval gates?
5. State: is the agent's working memory compacted into decisions rather than a raw transcript?
6. Verification: do you measure success by checking the environment (database state, for example) rather than the agent's final message?
7. Learn loop: when the agent fails, do you update the context contract or the tool schema to prevent that specific failure class?

If you have more than two Reds, your problem is not the model's intelligence. Your problem is the context.

What to change in the next 30 days

If you want to move your agents from experimental scripts to production systems, use this staged rollout:

• Week 1: map and measure. Document exactly what is currently in your agent's context window. Identify the bloat. Set up a baseline regression eval for your three most critical workflows.
• Week 2: sources and boundaries. Strip out the hardcoded facts and replace them with retrieval tools. Implement hard system boundaries for any action that modifies data or contacts a customer.
• Week 3: instrument and evaluate. Build code-based graders to verify the outcomes of your agent's actions. Log the context version and the retrieved source IDs on every run so you can debug failures.
• Week 4: run the learn loop. Take the failures caught by your new evaluations and use them to refine the context contract.

Agentic systems are powerful, but they are not magic. They require the same rigorous engineering, boundary design, and testing as any other production dependency. Build the context, enforce the boundaries, and measure the outcome.

If you want the full architecture rather than the operational slice, Building Your Agentic OS is where the pieces fit together.

References

1. Anthropic: Effective context engineering for AI agents
2. Anthropic: Demystifying evals for AI agents