What is an agent? The seams the word smears

Date: 2026-06-24. Scope: a mapping document, not a benchmark. It pins vocabulary against shipped seams and is honest in §6 about which seams are wired and which are foundations. It is the horizontal complement to engineering-is-building-loops: that doc decomposes an agent by scale (nested loops); this one decomposes it by part (the components inside any one loop) and then names the cuts the word collapses. Read together they are a 2-D map.

0. The word is doing too much work

Ask three engineers what “the agent” is and you get the model, the loop around the model, and the running session. None is wrong. That is the problem. “Agent” has become a smear word: it names a brain, a control loop, a lifetime, a fleet, and a product, and a sentence rarely says which.

There is a precedent for fixing this. “A program” used to smear together the process, the thread, the address space, the file descriptor, and the scheduler, until an operating system gave each one a name, a type, and a syscall. After that you could swap a thread without forking a process, share an address space across threads, and revoke a descriptor without killing the program. The names were the engineering.

fak’s bet is that an agent kernel does the same job for “agent.” If a tool call is a syscall, then an agent is not one thing; it is a small set of separable parts held apart by typed seams, and keeping them apart is what lets you swap, gate, and prove each independently. This doc is the parts list and the cuts.

1. Five questions hide inside one word

“What is an agent” is not one question. The field, and fak’s own docs, answer it at least five different ways, and they blur because each reaches for the same tired words (“layer”, “loop”, “level”). Pin the five apart first, because most confusion is a category error between two of these, not a wrong answer inside one.

Decomposition The question it answers The units Owned by
by scale how much runs in one address space, and how many of each inner / turn / session / fleet / RSI engineering-is-building-loops
by part what components one agent is built from engine, history, view, prompt, tool, loop, gate, … this doc
by optimization target what you change to make it better skill / trajectory / substrate RESEARCH-three-layers
by memory layer how the KV / agent-memory is organized routing / addressing / fusion / semantics MEMORY-LAYERS-EXPLAINER
by integration layer where you wire it in gateway / kernel-ABI / backend agent-integration-architecture

These axes are orthogonal. A “turn loop” (a scale) is not a “trajectory layer” (an optimization target); the four-layer KV memory (an organization) is not the five-loop ladder (a scale). When someone says “the agent layer,” ask which of the five they mean. The rest of this doc develops the part axis, then the cuts that run across all of them.

2. The parts list

One agent decomposes into five groups of parts. For each part: a one-line definition, the fak seam that is it (cited by symbol and test, never by line number — line numbers rot), and the single sharpest “it is not.”

A. Substrate — what persists across turns

B. View — what the model sees this turn

C. Compute — what proposes

D. Control — what disposes and drives

E. Plurality — more than one

                 THE PARTS OF ONE AGENT  (the horizontal axis)

   A. SUBSTRATE        B. VIEW             C. COMPUTE        D. CONTROL
   what persists       what the model      what proposes     what disposes/drives
                       sees this turn
   +-------------+     +-------------+     +-----------+     +---------------+
   | history     |     | context     |     | engine    |     | tool          |
   | session     | --> | window      | --> | (model)   | --> | loop          |
   | identity    |     | system prompt|    |           |     | adjudicator   |
   |             |     | skill       |     | intermed. |     | quarantine    |
   +-------------+     +-------------+     | output    |     +---------------+
        |              (a VIEW over        +-----------+          |
        |               substrate)           (PROPOSE) -----------+ (DISPOSE)
        |                                                         |
        +----- E. PLURALITY: many of the above, two rank spaces --+
               (DistComm moves bytes | agent communicator moves none)

3. The cuts that run across the parts

The parts list tells you what the pieces are. The real clarity is in the binary distinctions the single word “agent” collapses. Each cut below is a line the kernel draws with a type, and a power you only get once the line exists.

  1. Substrate vs view. History is lossless and durable; the context window is a lossy, re-derived projection of it. The field calls both “context.” The cut is ctxplan.Store versus ctxplan.Optimize’s output. Power: you can drop a span from the window without losing it — it pages back on demand.
  2. Soft steering vs hard gate. A system prompt and a skill are tokens the model may ignore; the adjudicator is code it cannot bypass. The word “steering” covers both. Power: where a prompt can only make a request, a gate makes a guarantee. This is the load-bearing cut; most “safety” claims live or die on which side they are on.
  3. Propose vs dispose. The model’s output is a proposal; the action is a disposition. “The agent did X” smears them. Submit adjudicates before any engine or network is touched, and a denied call never reaches dispatch. Power: you can prove an action that should not have run never ran.
  4. Replaceable vs durable. The engine is swappable per call; identity and session persist across the swap. “Which agent / which model” smears them. Power: you can change the brain without losing the agent.
  5. Reasoning vs action vs answer. Three kinds of intermediate output, not one “response.” Only the action is adjudicated; reasoning is echoed but never executed; the answer is terminal only when no tool calls ride with it. Power: you never confuse “the agent thought X” with “the agent did X.”
  6. Primitive vs composed. A tool is one syscall; a skill is a procedure over tools. “Capability” smears them. Power: the gate has a small, fixed surface to reason about — it sees tool calls, not playbooks.
  7. Turn vs session vs identity. One model round-trip, the durable lifetime that spans many, and the stable name for who is running — three things, one word (“session”). The session note already splits cold resume (re-attach a context image) from a warm flip (PAUSED → RUNNING). Power: you can dial a live run without restarting it, and re-home it without renaming it.
  8. Drive vs audit. Drive state is what happens next and is writable; the audit plane is what already happened and is read-only. Both get called “session state.” They meet at the TraceID and never overlap. Power: control and forensics do not contaminate each other.
  9. One rank space vs the fleet rank space. A tensor collective moves activations between ranks; the agent communicator moves no payload between sessions. Power: you cost and reason about “distributed” correctly instead of importing GPU intuitions into a lease-coordinated fleet.
  10. Residency vs reuse vs legality. The cache trichotomy: where bytes sit, whether two requests may share computed state, and whether that sharing is still legal. SCALING-LAWS §6 already pins this (“the word cache names at least seven different things”); it is the same move as this doc, applied to memory. Power: “the cache is hot” stops being mistaken for “this reuse is safe.”

4. Glossary: seven words that mean several things each

The clearest single artifact is a list of the overloaded terms with their sharpest split. These are not hypothetical; each sense below is a real type or doc in this tree. The canonical, maintained version is docs/glossary.md, which also carries the shared-memory sense split and the live memory issue-owner audit.

5. The map, and what the seams buy

Place the part axis (§2) against the scale axis (the loops doc) and you get the 2-D map. A given seam lives in one cell: the adjudicator is control at the inner ring; the session table is substrate at the session ring; the communicator is plurality at the fleet ring.

            CONCERN (this doc, the horizontal)  -->
 SCALE      substrate     view          compute       control        plurality
 (loops,    -----------   -----------   -----------   ------------   -----------
  vertical)
 inner      Ref/taint     -             EngineDriver  adjudicator     -
 turn       Message log   ctxplan view  Completion    loop / ctxmmu   -
 session    session.Table recall image  route policy  Decide gate     -
 fleet      identity      -             -             dispatch        DistComm /
                                                      witness         agent comm.
 RSI        journal       -             -             shipgate        -

Keeping the seams apart is not tidiness; each separated cut is a concrete power the smeared word cannot give you:

6. Honest fences

This is a map of seams at different maturities, not a claim that every part is shipped and wired. The load-bearing gaps, stated plainly:

None of these weakens the map. The point of naming a seam is precisely to say where the line is and how far the wiring has reached.