§0

Choose the depth you need

The foundational track stands alone. Read it first if “agent harness” still feels like a fuzzy label. The two extensions then trace the same concepts through real repositories, with source links pinned to the exact versions studied.

§1

The useful boundary

An LLM receives messages and produces a probabilistic continuation. An agent harness supplies the surrounding control system: it decides what messages the model sees, which capabilities appear as tools, how proposed calls become real effects, what enters durable state, and when another model call should happen. Interpretation

01 · Human

Intent and authority

Supplies the goal, constraints, approvals, and the environment in which actions matter.

02 · Harness

Control and memory

Builds context, validates calls, executes tools, records events, and schedules the next step.

03 · Model

Probabilistic proposal

Interprets the current context and emits text, structured tool requests, or a stopping answer.

04 · Environment

External reality

Files, shells, browsers, APIs, repositories, and people that can return evidence or be changed.

§2

What the primer will let you do

  • Draw the complete control flow of one agent turn, including tool calls and results.
  • Separate deterministic orchestration from nondeterministic model output without pretending either side is perfectly simple.
  • Recognize the common subsystems in a new harness: model adapter, context builder, loop, tool runtime, policy gate, session store, compactor, and extension surface.
  • Reason about capability versus permission: a tool may exist, be shown to the model, be callable, and still require approval before it may act.
  • Inspect a codebase in an order that follows runtime control rather than directory names.
  • Compare designs without collapsing product goals into a feature checklist.

No machine-learning mathematics is required. Familiarity with functions, JSON, files, and command-line programs will help in the source extensions, but the foundational path explains each term before using it.

§3

The evidence contract

“How the product behaves” and “how its internals are implemented” are different claims. DeepSeek Harness and Pi are open source, so their deep dives can point to repository documentation and code at pinned commits. Codex and Claude Code are bounded to what their current official documentation establishes. Their unexposed internals remain unknown here.

SOURCE

Pinned open-source code or repository documentation.

DOCUMENTED

Current official product documentation or a first-party publication.

OBSERVED

A reproducible public behavior, with version and conditions recorded.

INTERPRETATION

A design reading made explicit so it is not confused with source fact.

UNKNOWN

Public evidence does not establish the implementation detail.

This boundary is deliberate: the source-code deep dives cover DeepSeek Harness and Pi; the Codex and Claude Code section compares their documented surfaces without reverse-engineering private implementations. Unknown internals

§4

The full route

TrackChaptersBest for
FoundationBoundary · one turn · determinism · anatomy · context · trust · delegation · reading code · comparisonA complete mental model without repository detail.
DeepSeekPlugin kernel · one turn · tool policy · state · extensions · labA composable, event-oriented architecture with explicit policy seams.
PiThree layers · one turn · context · extensions · labA smaller stack whose core loop and coding integration are easy to separate.

Keep the glossary open if you meet an unfamiliar term. Every page works without JavaScript; the diagrams and context controls add a second way to inspect the same material.