Loop is a layered orchestration system:
- Entry and Context Layer
- Session context capture
- Prompt/task intake
- Complexity analysis inputs
- Decision Layer
- Pattern classification
- Activation decision
- Mode and budget strategy selection
- Execution Layer
- Orchestrator recursion/decomposition
- REPL-backed module execution
- LLM routing and cost tracking
- Persistence and Evidence Layer
- Memory graph storage
- Reasoning traces
- Validation outputs and governance evidence
- Integration Layer
- Rust API
- Python bindings
- Go bindings
- Adapter surfaces (Claude Code, TUI, etc.)
| Component | Responsibility |
|---|---|
context |
Session state, messages, and externalized context |
complexity |
Pattern-based activation signals |
orchestrator |
Recursive execution and synthesis |
repl |
Safe executable surface for generated code/flows |
llm |
Provider clients, routing, and cost accounting |
memory |
Persistent knowledge and experience graph |
reasoning |
Decision traces and graph analysis |
spec_agent |
NL -> Topos/Lean workflow |
sync |
Topos/Lean drift detection and synchronization |
- Every nontrivial execution should be explainable via trajectory/events.
- Policy gates are enforceable from repository-local runtime commands.
- Behavior-affecting changes require tests and documentation in the same change set.
- Integration surfaces should remain compatibility-aware unless explicitly changed.
- User/task input arrives.
- Context + complexity signals are computed.
- Activation decision selects path.
- Execution path runs modules/LLM/REPL actions.
- Outputs, traces, and memory updates are persisted.
- Governance and validation gates assert correctness for ship decisions.
- Loop favors explicit evidence over implicit confidence.
- Internal flexibility is allowed; release surfaces are contract-sensitive.
- If a behavior cannot be validated, it is not done. It is merely enthusiastic.
Related:
runtime-walkthrough.mdfor request lifecycle details.module-map.mdfor file-level entry points.