« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 01 — The Agent Kernel: Lifecycle, Memory, State & Session Affinity

Answers this JD line: "Design the platform's agent kernel, including agent lifecycle management, planning and reasoning loops, memory architecture (short-term, long-term, episodic), state management, session affinity, scratchpad persistence, and execution chains."

Why this phase exists

The JD calls it a kernel, and that word is doing real work. A kernel is not a framework and not a library — it is the component that stands between an untrusted program and privileged resources, and enforces limits the program does not get to choose.

Substitute "agent" for "program" and the whole design follows:

  • A process does not decide its own memory limit → an agent does not decide its own step, token, cost, or deadline budget.
  • A process cannot keep its page tables in another process's heap → an agent's session state lives in a store, not in a worker's memory.
  • A kernel records what every process did → the kernel emits an execution chain, and that chain is simultaneously the debugging artifact and the audit artifact.
  • An illegal syscall returns an error, it does not crash the machine → a hallucinated tool name is a recoverable observation, not a failed run.

Get this layer right and thirty agent teams inherit bounded execution, resumability, and auditability for free. Get it wrong and every team reimplements it, each slightly differently, and you find out during an incident which of the thirty forgot the step budget.

Five ideas carry the phase:

  1. Lifecycle is a declared state machine. Every legal transition is in a table; everything else raises. This is what lets you say "an agent cannot act after it has completed" and mean it as a property, not a hope.
  2. Memory is three different things with different lifetimes and different partition keys: the scratchpad (this run), semantic memory (durable facts, scoped to a user/tenant), and episodic memory (what happened last time). Conflating them produces either a context window that explodes or a memory store that leaks across tenants.
  3. State is externalized, and affinity is an optimization. Sticky sessions that require in-memory state make every deploy a customer-visible event. Externalize the state, keep the affinity for cache warmth, and a pod restart becomes a cache miss.
  4. Compaction is a kernel policy. The scratchpad grows quadratically; something must fold it. That something must never eat the recent window, and must never be the audit record.
  5. The execution chain is the product. Not a log. A structured, per-step record with identity, arguments, outcome, cost and timing, persisted as a by-product of running.

Concept map

  • Lifecycle: created → planning ⇄ acting → completed | failed | cancelled, plus waiting_input (human-in-the-loop) and suspended (checkpointed, evictable). Terminal states are absorbing.
  • Reasoning loops: ReAct (interleave), ReWOO (plan-then-execute), plan-execute-replan — and which one the kernel should support versus impose.
  • Memory tiers: scratchpad (volatile, bounded, compacted) · semantic (durable facts, scoped user/tenant/app) · episodic (append-only outcomes, recalled by similarity + recency).
  • State: SessionSnapshot as an immutable checkpoint; optimistic concurrency via a version compare-and-swap; the difference between checkpointed and durable.
  • Session affinity: consistent hashing, virtual nodes, the \( 1/n \) movement property, draining for rolling deploys, and why hash() is the wrong hash.
  • Budgets: steps, tokens, cost, wall-clock deadline — checked before the expensive call.
  • Error taxonomy: recoverable (unknown tool, schema violation, tool 5xx) vs fatal (budget breach, illegal state) — and why the distinction belongs to the kernel.
  • Execution chain: the audit artifact, read from the store so compaction cannot lose it.

The lab

LabYou buildProves you understand
01 — The Agent Kernela lifecycle state machine with a provable transition table, three memory tiers with correct partitioning, a session store with optimistic concurrency, a consistent-hash affinity router with draining, kernel-enforced budgets, and a run loop that checkpoints every step and emits an execution chainthat agent runtimes are operating systems for probabilistic programs, and that every property a bank needs — boundedness, resumability, isolation, auditability — is a kernel responsibility

Integrated scenario (how this shows up at work)

A Wholesale team's payment-investigation agent has been in production for two weeks. Three things happen in one afternoon. First, a deploy rolls the agent pods; forty in-flight conversations vanish, because state was in process memory. Second, one agent gets into a loop with a flaky sanctions API and burns AED 4,000 of tokens before anyone notices, because the only budget was the model's max_tokens. Third, Internal Audit asks for the step-by-step record of an investigation that recommended releasing a payment, and the team produces application logs that show four tool calls with no arguments, no identities, and no timing.

Every one of those is a kernel defect, not an agent defect. This lab builds the kernel that makes all three impossible: externalized state so the deploy is a cache miss, kernel budgets so the loop stops at step twelve, and an execution chain so the audit request is a query.

Deliverables checklist

  • Lab 01 green under LAB_MODULE=solution pytest and under your own lab.py.
  • You can draw the lifecycle from memory and justify each edge — including why acting cannot go straight to completed.
  • You can explain the three memory tiers, their lifetimes, and their partition keys.
  • You can explain why externalized state makes affinity optional, and what affinity still buys.
  • You can derive the \( 1/n \) movement property of consistent hashing and contrast it with modulo.
  • You can name four kernel budgets and say why they are checked before the model call.
  • You can classify five agent failures as recoverable or fatal, and justify each.

Key takeaways

  • The kernel enforces; the agent proposes. Budgets, lifecycle, and state are not the agent author's responsibility, exactly as memory limits are not a process's.
  • Undeclared transitions are bugs you can prove do not exist. A table plus a raise is cheaper than any amount of testing.
  • Three memory tiers, three partition keys. The scratchpad is per-run, semantic memory is per (scope, owner), episodic memory is per-tenant. A single "memory" abstraction leaks.
  • Externalize state; keep affinity as an optimization. Then a rolling deploy is a cache miss instead of forty lost conversations.
  • Compaction is lossy for the model and never for the record. The scratchpad is the model's working set; the checkpointed chain is the truth.
  • Recoverable ≠ fatal. A hallucinated tool name should teach the model something. A budget breach should stop the run. Confusing the two produces either brittle agents or runaway ones.