Context engineering

Type: kb/types/tag-readme.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

• A derived copy of recomputable truth must be checked or absent - When an artifact carries a copy of information recomputable from a ground-truth source, the copy must be machine-checked against that source or not exist — hand-maintained-and-trusted is forbidden
• Activate Behavior-Changing Memory Before The Mistake - Behavior-changing memory must activate before relevant actions rather than waiting for explicit retrospective search
• Active work state is not retrospective memory or chat history - Active work state needs current pointers, evidence gates, and closure; treating it as retrospective memory or chat history preserves the wrong state
• Agent memory needs discoverable, composable, trusted knowledge under bounded context - Frames discoverable, composable, trusted remembered knowledge as the minimal artifact-quality basis for agent memory under bounded context.
• Agent Memory Requirements - Navigation hub for concrete agent-memory requirements extracted from the memory-system design synthesis
• 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
• Create Memory Directly - Direct memory creation preserves live understanding by writing useful artifacts before later trace extraction loses structure
• Design for the first-time human, except on access cost - Treating an LLM agent as a competent first-time human is a good default for designing the systems it consumes — on most affordances. The proxy breaks on access cost, because humans read large artifacts sublinearly while agents load them whole into bounded context.
• Evaluate Memory By Effects, Not By Existence - Memory should be evaluated by downstream effects on tasks, artifacts, answers, behavior, context efficiency, and lineage alignment
• 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
• Import External Knowledge Into Internal Form - Agent memory systems need import paths when authoritative project knowledge already exists outside the memory substrate
• Keep Lineage And Compiled Views From Drifting - Generated cues, prompt files, indexes, and assistant-specific views need lineage and authority rules so they do not drift into independent behavior-shaping force
• Make Authority Explicit - Memory architecture must state who can read, write, promote, activate, enforce, revise, and retire memory across risk levels
• Memory design adds operational axes to artifact analysis - Memory design needs operational policy axes (capture, derivation, activation, authority assignment, lifecycle, evaluation) on top of substrate, form, lineage, and behavioral authority
• Preserve Evidence Without Making History The Next Context - Trace retention should preserve evidence for audit and extraction without making raw history the agent's default context
• Promote Only When Future Value Exceeds Maintenance Cost - Candidate memory should become durable only when future retrieval or activation value exceeds review and maintenance cost
• Raw accumulation does not create usable memory - Accumulation preserves material, but usable agent memory requires ingress work that adds handles, scope, relationships, provenance, trust signals, and lifecycle pressure.
• Retire, Redact, Supersede, And Relax Memory - Memory systems need lifecycle operations for redaction, decay, supersession, retirement, relaxation, and temporal validity
• Serve Multiple Consumers, Not One Retrieval Interface - Memory systems need multiple surfaces because acting, scheduling, review, learning, governance, and active work consume memory differently
• 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
• Symbolic context engineering is bounded by symbol availability - Symbolic context selection — matching on type, path, tag, tool, or event — can act only on an already-observable symbol; an operation's identifying symbol arrives by declaration, by the operation naming it, or by carryover from a prior one, so apparent anticipation is reaction to an earlier symbol. Producing context with no symbol available requires semantic inference.
• The adaptation survey corroborates memory requirements but misses artifact governance - The agentic-adaptation survey supports the memory requirements map by treating memory and skills as adaptive tools, but it needs substrate, form, lineage, and authority governance to become design guidance
• The practical scheduler is the host language, not a reified select - The simplest practical orchestration library demotes the tool loop to a returning, per-call-parameterized function and lets ordinary host-language code play select and K — reifying K only when the run must outlive its process or outgrow its memory
• Trace-derived memory earns authority per operation, not at capture - Trace-derived memory arrives as a record, not knowledge — authority is earned through post-capture operations (verify, distill, consult) with increasingly hard oracles; stores that stall before verification accumulate guesses masquerading as knowledge
• Use Trace-Derived Extraction As Meta-Learning - Trace-derived extraction is an after-the-fact learning path that must respect signal quality, review, and readable-artifact versus distributed-parametric learning boundaries