« Phase 01 · Warmup · Track Overview

Hitchhiker's Guide — The Agent Kernel

The 30-second mental model

An agent is while True: decide → act → observe. That loop is unsafe to run in a bank for seven reasons, and the kernel is the list of fixes. It is an operating system for probabilistic programs: it bounds what a run may consume, mediates tool access, owns the session state, records what happened, and survives the program misbehaving.

If a process would not be trusted to decide it, an agent is not either.

The numbers

The five things the kernel owns

1. Lifecycle — a declared transition table. Terminal states absorb. acting → completed is illegal on purpose.
2. Budgets — steps, tokens, cost, deadline. Checked before the model call.
3. State — externalized, immutable snapshots, optimistic concurrency.
4. Memory — three tiers, three partition keys.
5. Execution chain — emitted as a by-product, read from the store, complete even after compaction.

What it does not own: the loop shape. ReAct, ReWOO, and plan-execute-replan all reduce to "call a policy, get a decision, dispatch or finish."

One-liners

• ReAct — interleave reason and act. Adaptive, expensive, n model calls.
• ReWOO — plan everything up front with variable references, execute with plain code, then solve. Two model calls. Cannot adapt. Wins on repetitive workflows, which is most of banking.
• Plan-execute-replan — ReWOO until an assumption breaks, then degrade to ReAct. The trigger must be detectable in code.
• Compaction — lossy for the model, never for the record. Keep the recent window even when over budget.
• OCC — read with a version, write conditional on it. Exactly one writer wins and the loser knows.
• Checkpointed ≠ durable — resumability yes, exactly-once no. That is the action gateway's job.
• Drain, then remove — never remove alone, or every deploy drops sessions.
• Recoverable vs fatal — unknown tool feeds back; budget breach stops the run.

Vocabulary

Scratchpad · the run's working record. Compaction · folding old steps into a summary. Session · the durable container with identity and state. Snapshot · an immutable checkpoint. OCC · optimistic concurrency control. Virtual node · one of V ring points per replica. Draining · no new sessions here, existing ones finish. Absorbing state · a terminal state that accepts no events. Trap state · a non-terminal state with no path to termination — a bug. Execution chain · the per-step record that is both the debugging and the audit artifact.

War stories

The deploy that ate forty conversations. State in process memory. A routine rolling update dropped every in-flight session mid-investigation. The fix was not "make deploys rarer"; it was externalizing the state, after which the same deploy is a cache miss. Ask in review: where does session state live?

AED 4,000 in an afternoon. A flaky sanctions API returned a soft error the model kept retrying. The only limit in the system was the provider's max_tokens per call, which bounds one call and nothing else. Four budgets exist because a run can breach any one without the others.

The audit request with no answer. Application logs showed four tool calls: no arguments, no identities, no timing, no link between them. Six weeks of remediation. The design test: can you reconstruct the run from the chain alone, with the code deleted?

The ring that reshuffled every restart. Built on Python's hash(), which is salted per process. Every pod routed differently; every restart moved every session. Invisible in a single-process test.

The agent that answered with a tool result. acting → completed was allowed "to save a model call." The agent returned a raw balance query as its answer to a question about why a payment was held, with no recorded reasoning. One line in the transition table removed the class.

Beginner mistakes

1. Booleans instead of a state machine.
2. One Memory class for all three tiers.
3. Compacting the persisted record.
4. Ranking memory, then filtering by scope.
5. Session state in a worker's dict.
6. Last-write-wins on session state — two runs interleave into one chain.
7. Assuming checkpointing gives exactly-once.
8. session_id % len(replicas).
9. hash() in the ring.
10. Removing a replica instead of draining it.
11. Checking budgets after the model call.
12. Treating a hallucinated tool name as a fatal error.

What "good" sounds like

"The runtime is a kernel: it owns the lifecycle, the budgets, the state, the memory tiers and the chain, and imposes none of them on the loop shape. Lifecycle is a table, so terminal states absorb and a replayed finish raises instead of answering twice. Budgets are checked before the model call — otherwise a breached run pays for the step it discards and burns a rate-limit slot another tenant needed. State is external with a version CAS, so a deploy is a cache miss and a human approval can outlive the pod. Affinity is consistent-hash with virtual nodes and draining, so scaling moves a quarter of sessions to the new replica rather than three-quarters everywhere. And checkpointing gives me resumability, not exactly-once — effects are the action gateway's problem, which is why it's a separate layer."