AI Agent Memory: Better Handled via Context Engineering

Every LLM API call begins from a completely fresh slate — the model has no access to prior calls even one millisecond earlier. There is no built-in memory; the illusion of continuity is produced entirely by platform engineering that strategically reinserts relevant context (prior messages, facts, rules) into each new call. This means "agent memory" is not a property of the model — it is a property of the infrastructure wrapping it.

Prompt engineering focuses on crafting individual instructions to steer model behavior in a single call. Context engineering is the broader discipline of deciding what information to include, exclude, compress, or retrieve across the entire context window — managing memory tiers, retrieval signals, summarisation fidelity, and injection timing so the model has the right information at each turn. Context engineering is the architectural layer; prompt engineering is one tool within it.

Working memory (active context window — populated by the SessionStart hook); Episodic memory (time-anchored records — sessions/YYYY-MM-DD-{llm-id}-{agent-env}.ttl using OPAL Analytics Ontology); Semantic memory (stable facts — core.ttl with schema:Person and schema:PropertyValue triples); Procedural memory (behavioral rules — preferences.ttl sparse index + 44 companion howto/*.ttl files encoding 103 standing instructions).

The lost-in-the-middle effect is the empirically observed phenomenon where LLMs recall information at the beginning and end of a context window more reliably than in the middle. agent-rdf-memory mitigates this through the sparse-index pattern: preferences.ttl contains only step names and one-sentence rules — keeping it compact so all content falls in the high-attention zone. Full detail is in howto/*.ttl files loaded on demand.

RDF Turtle gives behavioral rules four properties markdown cannot: (1) Queryability — rules are addressable via SPARQL by trigger condition, position, or topic; (2) Semantic typing — each rule is a schema:HowToStep with explicit rdf:type, trigger, and rdfs:seeAlso; (3) Resolvability — entity IRIs are dereferenceable URLs, not opaque strings; (4) Composability — rules cross-reference each other, forming a connected graph rather than a flat list.

The SessionStart hook (load_memory.py) fires before the agent generates any response. It reads core.ttl, preferences.ttl, index.ttl, and the most recent session file, then returns their compiled content as additionalContext to the harness, which injects it into the model's context window. Memory loading is structural — enforced by the runtime, not reliant on the agent remembering to invoke a tool.

The sparse-index pattern splits memory into two tiers: a compact always-loaded index (preferences.ttl) with only step names, one-sentence rules, trigger conditions, and rdfs:seeAlso pointers; and verbose on-demand companion files (howto/*.ttl) with full rationale, code examples, and gates. preferences.ttl is read at every session start — its token cost is unconditional. Verbose content would inflate that cost by its full length every single session.

Four key tradeoffs: (1) Recency vs. relevance — balance between the most recent and most semantically similar information; (2) Summarisation fidelity — compression reduces cost but loses precise detail; (3) Staleness — outdated facts can persist with unwarranted confidence; (4) Security exposure — persistent memory creates long-term attack surfaces for injected malicious content. agent-rdf-memory addresses staleness via dated session files and explicit schema:dateModified tracking.

validate-memory-protocol.py parses Claude Code JSONL session transcripts and checks for five mandatory tool calls in order: (1) ls agent-rdf-memory/, (2) Read core.ttl, (3) Read preferences.ttl, (4) Read index.ttl, (5) at least one additional howto or session file. The --strict mode additionally verifies all reads occurred before the first substantive assistant response — catching "read-after-respond" violations.

RAG retrieves relevant chunks from a vector store at query time. agent-rdf-memory uses structural injection — loading behavioral rules in full at session start, not query time — ensuring they are always present. Retrieval is reserved for querying the local RDF file system during KG question-answering workflows. The two approaches are complementary: RDF context engineering for behavioral rules, RAG for knowledge retrieval.

Session files follow: YYYY-MM-DD-{llm-id}-{agent-env}.ttl. The three-component key (date, model, environment) enables unambiguous cross-session provenance: the same day can produce multiple files for different models or environments, and the model component is always sourced from the system-prompt model identifier — never inferred from conversation context — preventing misrouting of artifacts.

Production memory failures are almost never caused by information not being stored — they are caused by the right information not being surfaced at the right moment. This shifts the design burden from storage capacity to retrieval precision. In agent-rdf-memory, the SessionStart hook pre-loads critical memory unconditionally; howto files are loaded on demand via rdfs:seeAlso; and SPARQL makes any fact retrievable by subject, predicate, trigger condition, or date range.