Four layers of context engineering for production AI agents: How Deep Insight applies them in working code

When production AI agents handle tasks such as data analysis and report generation, context management can become a major bottleneck. A 200K-token window sounds generous until a real-world task burns through most of it in minutes. Data analysis and report generation leave the agent failing mid-execution, losing accuracy, or driving up costs. A body of published guidance already addresses this, but the individual techniques are easier to read about than to apply. Applied together, they make a measurable difference: in the reference implementation this post walks through, a single write-and-execute tool cuts the tokens each script adds to context by about 95 percent, and loading skills on demand shrinks the system prompt by about 97 percent. This series organizes that guidance into practices you can apply directly. Anthropic’s engineering posts, together with features built into the Strands Agents SDK, converge on four layers of context engineering: isolate context at the architecture level, control it through prompts, externalize it to the filesystem, and verify it with independent agents and safeguards. In this post (Part 2), you will learn how each layer works and what it looks like in working code. We applied these techniques in Deep Insight , an open source multi-agent data analysis solution built on the Strands Agents SDK and Amazon Bedrock AgentCore, which serves as the reference implementation throughout. Post series Part 1: 5 production challenges in multi-agent systems and how Deep Insight solved them. Part 2: Four layers of context engineering for production AI agents: How Deep Insight applies them in working code. Part 3: Harness engineering in practice: moving Deep Insight from dev to production. (Coming soon!) The first post defined five core challenges that production multi-agent systems must solve. It introduced how Strands Agents SDK , Amazon Bedrock and Bedrock AgentCore , and AWS Fargate each address different layers of the problem, with code examples. This second post takes the four layers of context engineering practice that sit on top of that architecture and shows each one implemented. The third post guides you through deploying and operating agents in a secure private network on Amazon Virtual Private Cloud (Amazon VPC), covering everything needed for real-world operations. What is context engineering? Context engineering is the discipline of optimizing the information in a large language model (LLM)’s limited context window so agents perform at their best. Anthropic Claude Sonnet 4.5, available on Amazon Bedrock, offers a 200K context window, but complex production tasks quickly exceed it. For example, a seemingly straightforward request like “ Analyze sales data and create a DOCX report ” runs through several stages: data loading and exploration (5 min), category-based sales analysis (3 min), generating five charts for time-series analysis (10 min), statistical validation (3 min), and final report generation (5 min). Together they consume over 150K tokens across 15 minutes. Processing such tasks in a single context causes problems: the window overflows mid-task, stale context degrades performance, and errors require re-running the whole pipeline. As context grows, attention to important information drops, and inefficiency raises cost under per-token pricing. “As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases (Context rot).” — Anthropic, “ Effective Context Engineering for AI Agents ” (2025.09) Context engineering solves exactly these problems, and it is not only a collection of techniques. Spanning architecture design, prompt writing, tool implementation, and verification, it’s a layered discipline where each layer compensates for what the previous ones miss. This post details the four-layer approach you can apply to manage context efficiently. How to handle tasks that exceed the context window Anthropic has published several techniques for handling long-horizon tasks. Deep Insight groups these techniques into four layers, with each layer addressing the limitations of the others. The following table sets out the four layers. Layer Practice Core Principle Limitations Layer 1: Architecture Isolating Context Through Multi-Agent Architecture Each agent operates in an independent context When isolation alone is not enough Layer 2: Prompt Output Control and Behavioral Rules Limiting context intake through prompts When prompts alone are not enough Layer 3: Tools File-based Context Externalization Keeping heavy content in files outside the context When issues still arise Layer 4: Verification Agents and Safeguards Independent Verification and Safeguards Catching errors and preventing context overflow Final line of defense The sections that follow take each layer in order, stating what the layer prescribes, why the preceding layers alone are insufficient, and how the practice is implemented in Deep Insight. 1. Isolating context through multi-agent architecture Give each specialized agent its own context window and pass only compressed results to the orchestrator. Deep Insight does this with a hierarchy of Coordinator, Planner, Plan Reviewer, Supervisor, and Tool Agents (Coder, Validator, Reporter, Tracker, Auditor). With a single agent, all information, from user requests through data exploration, analysis, chart generation, validation, and reporting, accumulates in one context and easily exceeds the window. Giving each agent its own context keeps even the Coder, which uses the most, under 25K tokens total. Each agent receives only what it needs and signals others with a completion notice and brief summary. The key to isolation is minimizing shared information. Deep Insight uses a Python dictionary, shared_state , that stores only four things: messages : The previous agent’s final message (not the full conversation history). clues : Compressed summaries collected from each agent. full_plan : A checklist generated by Planner and updated by Tracker. history : A brief log of agent names and messages. The clues use a fixed CLUES_FORMAT: instead of each agent’s full conversation (tens of thousands of tokens), only compressed core results are passed. # coder_agent_tool.py -- context passing format CLUES_FORMAT = "Here is clues from {}:\n\n \n{}\n \n\n" RESPONSE_FORMAT = "Response from {}:\n\n \n{}\n \n\n*Please execute the next step.*" # After Coder completes: add only compressed result to clues clues += CLUES_FORMAT.format("coder", response["text"]) This pattern is the one recommended in Anthropic’s “ How We Built Our Multi-Agent Research System ” post, which describes an orchestrator-worker pattern in which a lead agent delegates to specialized subagents, with each agent working only within its own context. You do not need to build it yourself: the agents-as-tools pattern in the Strands Agents SDK provides this isolation at the framework level. 2. Controlling context inflow through prompts Layer 1 isolation alone is not sufficient: even with independent contexts, an agent that generates long responses inflates the Supervisor’s context. Layer 2 limits each agent’s output through prompts. For Deep Insight, we use prompts to limit how much information each agent returns to the Supervisor. Three rules do most of the work, as Deep Insight’s prompts show. “Start with the strongest model and a simple prompt. Then incrementally add specific instructions based on actually observed failure cases.” — Anthropic, “Effective Context Engineering for AI Agents” (2025.09) Implementation detail 2-1: Explicit per-agent output token budgets Each agent’s prompt specifies a maximum response token count, preventing long responses that pollute the Supervisor’s context. Agent Output Token Budget Reason Coder 1,000–1,500 tokens Analysis code is saved to files, so the agent returns only a summary of state, completed tasks, and insights Validator 800 tokens Validation results ar