How to build agentic systems for real

Nine ideas that reorganize the field

If you take only one thing from here, take these. They are the connections the traditional order (start with frameworks, or with "how to call a tool") hides.

1. 01

   The whole field derives from three substrate properties. An LLM is stochastic, stateless, and runs on a finite window. Memory exists because it forgets; evals run pass^k because it is stochastic; context engineering exists because the window is finite. Learn the root and sixteen topics collapse into one tree.

2. 02

   Eval, reward, and grader are the same function wearing three hats. The verifiable function that scores a training rollout is the same one that grades your evals and shapes self-improvement. Master writing un-hackable verifiers and you master training, evaluation, and self-improvement at once.

3. 03

   Security and human-in-the-loop are not a separate pillar. They fall straight out of compounding error and partial observability. Prompt injection has no clean fix, so the trust boundary has to live in deterministic code, not in the prompt.

4. 04

   Memory is coupled to security more tightly than to context. The write-path is where untrusted input becomes trusted knowledge. A poisoned memory is a persistent, multi-session attack — strictly worse than a one-turn injection.

5. 05

   Teach reasoning after the loop and evals, not before. Chain-of-thought is not faithful to the internal computation, so it is no audit trail and no injection defense. That lesson only lands once you already understand graders and architectural defense.

6. 06

   The return is in five decisions, not sixteen pillars equally. Do I even need an agent. Does control flow live in code or get delegated to the model. Is reversibility the gate for human review. Did error analysis come before writing evals. Is the defense architectural or behavioral. These five carry most of the reliability ROI.

7. 07

   Start from the mental model and the raw API, not from a framework. Heavy agent frameworks hide the loop and the policy and quietly push you toward over-engineering. Understand the POMDP first and you can reason about any framework instead of being trapped in one.

8. 08

   You learn security by breaking things, not by reading about them. A system whose weak spots you have exploited and then patched teaches the principle far better than a clean example that was never wrong.

9. 09

   Retrieval, memory, and context are one triangle. Three ways to manage the finite belief state of the POMDP: retrieval loads knowledge on demand, memory persists state across turns, context curates what enters the window now. Traditional teaching fragments them into RAG, memory, and prompting silos.