Context Engineering · ~7 min

Assembling the Prompt

A monolithic system prompt pays for every section on every turn. Build the context deliberately instead — per mode, per phase, by delta.

Earlier in Part 3 you saw every preloaded token displace a reasoning token (Lesson 16). The fix isn't a shorter prompt — it's a composed one: include only what this mode, this phase, and this step actually use. Four assembly disciplines, one principle.

1 Compose by mode, not monolith

A single static prompt works for a simple agent. As capabilities grow it accrues sections — identity, code-quality rules, safety constraints, provider quirks — and every conversation pays the token cost for every section, relevant or not.

Each section carries a numeric priority that sets assembly order. Planning mode omits code-quality rules; execution mode omits planning heuristics — so irrelevant instructions never consume context or attention. Provider-specific blocks (a Claude-only directive) inject conditionally, without bloating the prompt for other providers.

Tie-in to caching: identity and tool schemas assemble first so the stable prefix never shifts; dynamic sections sit at the end. A conditionally included section placed early in the priority order invalidates the cache for every token after it — modular composition can defeat the caching it was meant to enable if dynamic content leaks into the prefix.

2 Assemble by phase

When an agent produces poor output, the instinct is to fix the prompt or swap the model. A better lever is the context bundle delivered to that agent for that phase. Different roles need different information.

Orchestrators need condensed summaries — enough to route and decompose; file contents waste attention on decisions they don't make. Workers need targeted, granular context — the exact files they'll edit and the command that confirms correctness. Give both the same bundle and you get drift: planners distracted by implementation detail, workers carrying planning artifacts that crowd out actionable context.

3 Chain with gates between steps

Don't ask one prompt to plan, implement, and validate at once. Decompose into a sequence of LLM calls, each with a single responsibility, each taking the previous output as input — and put a programmatic gate between steps.

The gate is the defining feature: it intercepts errors at the point they occur rather than at final output. A call that plans and implements simultaneously defeats the chain — errors in either phase contaminate the other, and the gate between them can't fire.

4 Grow the playbook by delta

When an agent learns a strategy and you fold it back in by rewriting the whole context, the LLM systematically drops the hard-won specifics — error-recovery sequences, tool ordering — because they read as verbose next to high-level guidance. That's brevity bias, and it compounds.

Instead, accumulate structured delta entries — itemized units, each one strategy or failure mode, each with a unique ID and helpful/harmful counters. Updating one strategy doesn't regenerate the context; entries persist independently and merge through deterministic, non-LLM logic. Consistently useful entries surface; harmful ones are deprioritized — no labels required. It's the same logic as composition: change the part, not the whole.