---
name: context-engineering-agents
description: "Engineer agent context: token budgets, dynamic selection, compression, memory tiering, and drift monitoring for long runs. Production context engineering for agents: structured prompts under token budgets, AGENTS.md as cross-tool context source, dynamic context selection and retrieval, summarization-based compaction, memory tiering (working/short-term/long-term with external stores), and drift monitoring across long-horizon runs. Covers context-window pressure, tool-result pruning, and recovery patterns to prevent context rot and stalls."
license: MIT
---

# Context Engineering Agents

A working toolkit for treating the context window as a managed resource rather than an afterthought. This skill helps you design agents whose prompts stay inside token budgets, pull in only the context a step actually needs, compact history as it grows, and survive long-horizon runs without silently drifting off-task. It is aimed at developers building multi-step or long-running agents on top of LLM APIs (Claude, GPT, open models) who keep hitting context-window limits, ballooning costs, or degraded reasoning after dozens of turns.

## When to use it

- An agent loop runs for hundreds of turns and the transcript no longer fits the window.
- You pay per token and want to stop re-sending the entire history on every call.
- Multiple tools (CLI, IDE, CI) need to share the same project context without copy-paste.
- A long task slowly loses the original goal, repeats steps, or contradicts earlier decisions.
- You need to decide what belongs in the system prompt vs. retrieval vs. an external store.

## What it does

- **Token budgeting.** Assigns explicit budgets to system prompt, tool defs, retrieved chunks, and history; uses a tokenizer (e.g. `anthropic.count_tokens`, `tiktoken`) to enforce them before each call.
- **AGENTS.md as shared context.** Treats a repo-root `AGENTS.md` as the single source of cross-tool instructions, conventions, and project facts that every agent reads.
- **Dynamic selection & retrieval.** Scores and pulls only relevant docs/snippets per step instead of stuffing everything in.
- **Summarization-based compaction.** Replaces old turns with rolling summaries when usage crosses a threshold, preserving decisions while dropping transcript bulk.
- **Memory tiering.** Separates working memory (current step), short-term (recent turns), and long-term (vector/KV store) with explicit promotion/eviction rules.
- **Drift monitoring.** Periodically checks current behavior against the stated objective and flags divergence.

## Example

```yaml
# context.config.yaml
budget:
  total_tokens: 180000
  system: 4000
  tools: 6000
  retrieval: 40000
  history: 120000
compaction:
  trigger_ratio: 0.8        # summarize when history hits 80% of its budget
  keep_last_turns: 6
memory:
  long_term: { store: vector, top_k: 8 }
context_sources: [AGENTS.md]
drift_check:
  every_n_turns: 20
```

## Tips & gotchas

- Budget the *output* too: reserve `max_tokens` for the reply so a full input window doesn't truncate the answer.
- Summaries are lossy — pin hard constraints (IDs, file paths, decisions) into a protected block that compaction never rewrites.
- Keep `AGENTS.md` short and stable; it is prepended on every call, so churn there multiplies cost.
- Retrieval relevance beats volume. A smaller, sharper `top_k` usually improves reasoning over a large dump.

## FAQ

**Does this depend on a specific model?** No. It is tokenizer- and provider-agnostic; configure the count function for your model.

**How is compaction different from a bigger context window?** A larger window delays the problem; compaction and tiering bound cost and keep signal-to-noise high regardless of window size.

**Will it edit my prompts automatically?** It applies budgets and compaction at runtime; your authored system prompt and `AGENTS.md` stay under your control.