Reading path: the knowledge layer of agentic systems

A curated spine through the knowledge base for builders new to it. Every note's title is its claim; each step builds on the ones before it. Read it yourself in an hour, or hand this file to your coding agent as the traversal order and ask your questions as you go.

Part 1 — The constraint

Everything in agentic-system design is downstream of one scarce resource.

  1. Agent context is constrained by soft degradation, not hard token limits — the binding constraint is silent reliability degradation across volume, complexity, and interference, not the provider's token limit.
  2. Context efficiency is the central design concern in agent systems — context is scarce for two distinct reasons, feasibility and cost, and feasibility binds first; nearly every architectural pattern is a response to this pressure.
  3. Context engineering — the discipline this forces: getting the right knowledge into a bounded context at the right time.

Part 2 — Knowledge that changes behavior

Storing knowledge is easy. Making it change what the agent does is the actual problem.

  1. Knowledge storage does not imply contextual activation — the load-bearing distinction of the whole KB: knowledge that exists, knowledge loaded into context, and knowledge that actually changes behavior are three different things.
  2. In-context learning presupposes context engineering — "the model will figure it out from context" assumes selection machinery that is itself a system you have to build and improve.
  3. Agent memory needs discoverable, composable, trusted knowledge under bounded context — the minimal quality basis for remembered knowledge: if artifacts aren't discoverable, composable, and trusted, storage is dead weight.
  4. Agent memory is a crosscutting concern, not a separable niche — memory decomposes into storage (solved), retrieval/activation (Part 1–2), and learning (Part 3); the hard problems live at the intersections, which is why "add a memory product" rarely fixes them.

Part 3 — Learning during deployment

Your system will meet reality after you ship it. Where does what it learns go?

  1. Deploy-time learning is the missing middle — between slow parametric retraining and ephemeral in-context adaptation sits the underbuilt layer: durable, inspectable artifacts updated across sessions during deployment.
  2. Distillation and constraining — the two orthogonal moves that layer performs: extracting use-shaped artifacts from larger material, and narrowing the space of valid interpretations (up to codification into schemas and code).
  3. Constraining during deployment is continuous learning — continuous learning can happen outside of weights: prompts, schemas, tools, and tests accumulate adaptive capacity you can read and audit.

Part 4 — When it fails

  1. Interpretation errors are failures of the interpreter — real LLMs violate explicit constraints and fumble fully specified bookkeeping; design for an imperfect interpreter rather than a noisy-but-valid one.
  2. Failure modes — the taxonomy of ways knowledge can exist in your system without ever changing agent behavior.

Capstone — the field, surveyed

  • What the matrix shows across 141 agent memory systems — every claim above, tested against the field: 141 code-grounded reviews classified on shared axes, showing that storage substrate predicts little and the real forks are who decides what to remember and whether memory ever reaches behavior.

Where next

  • Browse by topic — the tag hub: foundations, learning theory, context engineering, tool loop, observability, and more.
  • Browse the system reviews — find the systems closest to your architecture and read what their source code actually does.