Most applications should start with a single Context Compiler engine.
A single engine is not a single rule.
It maintains a complete authoritative state consisting of:
- one premise (a single explicit conversational stance)
- a set of per-item policy states (
useorprohibit)
Because policies are keyed and independent, a single engine can represent many constraints simultaneously.
A single engine can manage:
- global constraints
- conversational stance
- explicit correction and replacement flows
- policy removal and reset
- transcript replay and persistence
Example:
User: set premise concise, practical answers
User: prohibit docker
User: use uv
User: use pytest
All constraints coexist in a single deterministic state snapshot.
Policies do not interact with each other.
- There is no ordering
- There is no grouping
- There is no domain model
Each policy entry is an independent authoritative key.
Use multiple engines only when you need independent state instances, not additional expressiveness.
Typical cases:
- separate assistants or agents
- separate user sessions
- isolation between workflows
- independent persistence or reset behavior
The compiler does not coordinate multiple engines.
The host is responsible for:
- selecting which engine(s) apply
- combining state into model context
- managing lifecycle (reset, persistence, replay) per engine
The compiler only maintains a single authoritative state per instance.
Start with one engine.
Introduce multiple engines only when you need independent lifecycle or isolation, not because a single engine is insufficient.