Structured and versioned context, dynamically assembled.
No giant prompt, and no path fixed in advance. A structured evaluation engine reads each turn and assembles the exact context it needs, from your policies, routines, and memory.
Dynamic Context Engineering, the mechanism behind Interactive Agents.
The context problem
Most agents fail at context in one of two ways.
They stuff everything into the prompt.
Every rule, edge case, and policy loaded into one monolithic prompt. As it grows, the model can no longer weigh competing priorities, instructions get lost, and the full behavioural surface is exposed on every call.
system-prompt agents
They hard-code the path in advance.
A rigid routing graph sends each turn down a fixed path to a node with narrower context. A compound question or an abrupt topic switch breaks the flow, and when the routing chooses wrong, the missing rules produce ungrounded, incorrect answers.
workflow graphs · routed flows
Either way, the agent works with the wrong context, and reliability and cost both pay for it.
Dynamic context engineering
How context gets assembled. Every turn.
Read the state
The engine inspects what is happening right now: the user's intent, the routine in progress, and the variables in play.
Assemble the subset
It injects the matched policies, routine state, glossary terms, context variables, retrieved knowledge-base snippets, and tool results. What stays out is as deliberate as what goes in.
Resolve conflicts
When matched rules conflict, the engine resolves it, not the model. Declarative precedence, set by the team in advance, decides which instruction wins, and non-conflicting rules still apply.
Startup vs runtime
A rigorous startup buys a lean runtime.
Before your agent runs, a startup evaluation pass rewrites, validates, and structures the instructions, routines, conditions, and actions your team wrote into your context store, so even a rough routine reaches production polished. Think of it as CAPEX: the investment up front that buys a lean, reliable, low-cost runtime. The expensive context-building evaluation happens once, at startup, so at runtime the engine just matches the policies each turn needs and traverses the routines it already built.
Startup · CAPEX
Once, at build time
- Rewrite and clarify your instructions
- Validate every condition and action
- Optimize the language for the model
- Structure and store them in the context store
The heavy LLM evaluation runs here, once.
Context store
Your polished contextual elements
Runtime · OPEX
Every turn, in production
- Match the policies this turn needs
- Traverse the routine, step by step
- Assemble the exact context
Built at startup, so runtime just matches and traverses.
Startup is the investment. Runtime is where it pays off.
Why it matters
Manage context per turn, and four things follow.
Precision
A focused context means a focused model: no competing rules to dilute attention, so answers stay accurate and on-policy turn after turn.
A smaller security surface
Each turn assembles only the rules that moment needs, so less of the full instruction set is present in any single call, a smaller blast radius if a prompt is ever probed.
Scale without instruction fatigue
Add a policy, a routine, or a whole new scenario without bloating a prompt. The library can grow for years while per-turn context stays roughly constant, so capability scales and reliability holds.
Interpretable by design
Every operation is captured as a structured trace, so behaviour ties back to versioned, editable artifacts, not buried somewhere inside a wall of prompt text.
Dynamic Context Engineering is one mechanism inside a larger architecture. The manifesto lays out the rest.
Read the full manifestoDynamic Context Engineering
See context resolved turn by turn.
Bring a real use case. We will show the engine assemble only what each turn needs, on your rules, in a working agent.