Context Engineering
The discipline of designing what information AI agents receive and when they receive it. Not just "what goes in the prompt" - but how to build systems that assemble the right context for any task, across any number of sessions.
Why Context Engineering Matters
The quality of an AI agent's output is bounded by the quality of its context. A perfectly capable model with the wrong context will produce confidently wrong results. A smaller model with precisely the right context will outperform a larger one working blind.
This is not about prompt engineering - crafting individual prompts for individual tasks. Context engineering is the systems-level discipline of designing how information flows to and from AI agents across entire workflows, sessions, and projects.
The difference matters because real work does not fit in a single prompt. A software project spans hundreds of files, dozens of decisions, and weeks of sessions. The agent that picks up your work tomorrow needs to understand what happened today - not because you told it, but because the system assembled the right context automatically.
Four Layers of Context
SPINE assembles context from four distinct layers, each with different lifetimes and update frequencies. The layers compose - higher layers override lower ones when they conflict.
L1: Static Context
Project filesCLAUDE.md, config files, README. Information that changes rarely and applies to every interaction. Loaded at session start.
L2: Memory Context
Minna Memory / Session HandoverPersisted knowledge from previous sessions. Decisions made, errors encountered, patterns discovered. Recalled by entity and attribute.
L3: Discovery Context
Sibling projects, file systemDynamically discovered resources from adjacent projects. The agent finds related codebases, shared dependencies, and cross-project patterns.
L4: Ephemeral Context
Current sessionShort-lived findings from the active session. Decays over time using configurable curves (linear, exponential, step). Prevents context pollution from stale intermediate results.
Memory Systems
Four complementary memory systems serve different persistence needs. The key insight: memory is not one thing. A fact that should persist forever, a session finding that should decay in hours, and a code relationship that should update on every commit all need different storage.
Entity Memory
Structured facts about people, projects, topics, and concepts. Each memory has an entity, attribute, value, confidence score, and timestamp. Confidence decays over time.
Session Memory
Ephemeral findings with configurable decay. Three curves available: linear (steady fade), exponential (rapid initial decay), and step (sharp cutoff). Prevents context pollution from stale data.
Handover Memory
Structured documents that capture session state for the next agent. Accomplishments, pending tasks, key decisions, infrastructure status, and Minna memory pointers.
Graph Memory
Code entities and relationships stored in a graph database. Functions, classes, imports, and call chains across 38+ projects. Enables cross-project impact analysis and blast radius detection.
Scenario-Driven Assembly
Context assembly is not random. SPINE uses YAML scenario files that define exactly which context layers to activate, which tools to make available, and what verification to run for a specific type of work.
A portfolio-review scenario loads PAAF metrics, recent audit scores, and archiving candidates. A code-review scenario loads Intelligence Engine data, complexity hotspots, and blast radius information. The agent does not need to decide what context it needs - the scenario defines it.
This is the difference between "here is everything, figure it out" and "here is exactly what you need for this type of task." The former wastes context window. The latter focuses the agent's attention on what matters.
Anti-Patterns to Avoid
Lessons learned from building context systems across 70+ sessions and 230+ projects.
Context Dumping
Problem: Loading everything available into the prompt.
Fix: Use layered assembly - load L1 always, L2-L4 selectively based on task classification.
Stale Context
Problem: Session findings from hours ago treated as current facts.
Fix: Ephemeral memory with decay curves. Facts older than the configured half-life get lower confidence scores.
Context Amnesia
Problem: Each session starts from zero, repeating discoveries from previous sessions.
Fix: Session handover protocol: structured documents + Minna memory recall at session start.
Shared Context Pollution
Problem: Multiple projects writing to the same memory store, creating entity collisions.
Fix: Per-project memory databases. Every project gets its own Minna DB via MINNA_DB_PATH.
Unverified Context
Problem: Trusting written status claims without checking the actual codebase state.
Fix: Verify-before-acting protocol: cross-check backlog claims against git status and IE queries before executing.
The Five-Point Verification Protocol
Context engineering is not just about assembly - it is about verification. Every task processed through SPINE follows the Five-Point Protocol: Clarify the task, Validate the scope, Plan the reasoning, Execute according to plan, and Verify the output against the original intent.
This protocol is itself a form of context engineering. By forcing explicit clarification and scope validation before execution, it prevents the most common failure mode of AI agents: confidently solving the wrong problem.
The protocol also creates natural checkpoints for context refresh. After execution, the verification step re-reads the original intent and compares it to the output. Any drift between what was asked and what was produced becomes visible immediately.