Context engineering
Type: kb/types/index.md ยท Status: current
Context engineering is the machinery for getting the right knowledge into a bounded context at the right time. Use this index for notes about routing, loading, scoping, scheduling, and maintenance practices that make agent-operated KBs usable under context limits.
Core Claims
- Designing a Memory System for LLM-Based Agents - applies context-engineering pressure to memory-system design
- semantic sub-goals that exceed one context window become scheduling problems - explains when context limits force orchestration instead of a single larger prompt
- stateful tools recover control by becoming hidden schedulers - shows how runtime state can relocate context control behind the tool boundary
Adjacent Indexes
- Computational model - explains the bounded-call substrate context engineering operates on
- Tool loop - covers framework-owned loops and when scheduling must become explicit
- Learning theory - covers how context machinery contributes to deploy-time learning
Other tagged notes
- Brainstorming: how to test whether pairwise comparison can harden soft oracles - Staged test plan for whether pairwise comparison improves soft-oracle properties (discrimination, stability, calibration) in LLM evaluation loops
- Codified scheduling patterns can turn tools into hidden schedulers - As agent behavior matures, deterministic next-step policies need explicit control logic; if the framework offers only tools, scheduling patterns end up there and the tools become hidden schedulers
- Evolving understanding needs re-distillation, not composition - When understanding evolves, reconciling fragments into a coherent picture can exceed effective context; a pre-distilled narrative keeps the whole picture within feasible bounds
- Selector-loaded review gates could let review-revise learn from accepted edits - Brainstorm on learning reusable review gates from accepted note edits: mine candidate gates from before/after diffs, store them atomically, and load a bounded subset into future reviews
- Subtasks that need different tools force loop exposure in agent frameworks - When decomposition creates child tasks with different tool surfaces, the parent must construct fresh calls for each child, so a framework-owned loop is no longer the right control surface