« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 04 — Context Engineering: Prompt Assembly, Memory & Intent Routing

Answers these JD lines: Citi's "prompt/context management," "develop prompt and intent-classification logic to avoid workflow collisions," and "context engineering" (the exact phrase now appears on the Lead Agentic AI Engineer and Agentic AI Technical Lead postings in jd.md); the "context management" and "memory" language echoed by Cohere, Redcan, and Anthropic's Claude-Code roles.

Why this phase exists

Phase 00 gave you the arithmetic (the window is a finite, billed budget; ReAct's scratchpad grows quadratically). Phases 01–03 gave you a loop, typed tools, and MCP servers that all produce more candidate context than fits. This phase is the discipline that decides, on every single turn, what actually goes into the prompt — the successor skill to "prompt engineering" that senior JDs now call context engineering.

"Prompt engineering" was writing one clever string. Context engineering is engineering the whole payload: assembling the system prompt, the task, memory, retrieved documents, and tool results into a finite token budget, in an order the model can actually use, having routed the request to the right prompt/tool/model in the first place. It is a systems problem — a budget, a priority queue, a cache, and a classifier — not a wordsmithing one. Four ideas do the work:

1. The window is a budget you pack, not a bucket you fill. More context is not better; past a point it is slower, costlier, and worse (context rot, lost-in-the-middle). You pin the must-haves, add the rest by priority, and drop or truncate to fit.
2. Position matters. LLM recall is U-shaped: strong at the beginning and end of the context, weak in the middle (Liu et al. 2023). Where you put a fact changes whether the model uses it, so ordering is a control, not a cosmetic.
3. Route before you reason. Classifying intent up front lets you dispatch to a cheaper, specialized prompt/tool/model — and, critically, lets you refuse to route when two intents collide, instead of sending a "cancel and refund" request down one pipeline.
4. Memory is a hierarchy, not a log. A short working buffer, a rolling summary of what fell out of it (compaction), and a semantic long-term store you recall from by similarity — the same three tiers Claude Code, Cursor, and ChatGPT memory implement.

Concept map

• Token budget: count_tokens (a real tokenizer stand-in) is the unit; the window is a budget, and every source (memory, retrieval, tools) competes for it. Ties to Phase 00's cost math and Phase 14's caching.
• Assembly: pin → prioritize → truncate (word boundary + elision) or drop → pack. Invariant: result tokens ≤ budget, pinned always present.
• Ordering: order_for_recall — highest priority at the edges, lowest in the middle (lost-in-the-middle).
• Routing: bag-of-words cosine → intent, with a fallback on low confidence or an ambiguous tie (the "workflow collision"). Per-intent models are a cost lever (Phase 14).
• Memory: working buffer (FIFO) · rolling summary via an injected summarizer (compaction) · semantic store (embed + cosine recall). Maps to working/session/long-term.
• Integration: build_agent_context = route + gather memory + retrieved + assemble in budget with recall ordering.
• Forward refs: retrieval that fills the recalled/retrieved slots is Phase 05/06; context caching that makes the packed prefix cheap is Phase 14.

The lab

Integrated scenario (how this shows up at work)

Citi wants a support agent that handles billing, cancellations, and tech issues over a long multi-turn conversation, without leaking one workflow into another. You route each user message to an intent — but when someone writes "cancel my plan and refund the last charge," your router detects the billing/cancel collision and returns a clarify turn instead of silently guessing. You keep a tiered memory: the last few turns verbatim, a rolling summary of everything older (so a 40-turn chat still fits the window), and a semantic store of durable facts (the account id, the plan tier) you recall by similarity. On every turn you assemble the system prompt (pinned), the routed intent, the recalled facts, the retrieved policy docs, and the recent turns into a fixed token budget — pinning the must-haves, truncating the long policy doc, dropping the chit-chat, and ordering so the system prompt and the live task sit at the edges where the model will actually read them. That is the whole phase, and it is exactly the "prompt/context management" and "intent-classification logic to avoid workflow collisions" the JD asks for.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• You can explain, from the U-shaped curve, why order_for_recall brackets the important context at the edges.
• You can state the two conditions under which a router should refuse to route, and why guessing is worse than clarifying.
• You can name the three memory tiers, what "compaction" trades, and where each maps in Claude Code / Cursor / ChatGPT.
• You can argue RAG-vs-long-context and context-caching as budget decisions (forward-ref Phase 05/06 and Phase 14).

Key takeaways

• Context engineering is the senior successor to prompt engineering: you engineer the whole payload under a budget, not one clever string.
• The window is a budget you pack (pin, prioritize, truncate, drop), and position is a control — lost-in-the-middle is a design constraint, not trivia.
• Routing's real value is often the fallback: refusing to route an ambiguous request is what prevents a workflow collision, and per-intent models are a cost lever.
• Memory is a hierarchy — buffer, compaction summary, semantic recall — and every production agent product implements some version of it.