Build a coding agent from nothing. Not a prompt pasted into a chat window — a program that runs the loop: sends a conversation to a model, executes the tools the model asks for, feeds the results back, and keeps going until the job is done. Then give it hands (files, shell, permissions), a memory (AGENTS.md, sessions, compaction), a way to learn (skills, hooks, subagents), a way to plug in the world (MCP), and finally a face: a terminal UI you would actually sit in.

Seven sessions, one codebase. You start each part in the folder where the last one ended (or in an empty one, and your previous work is fetched for you), and every part opens by re-checking the contract the previous part earned — so a campaign carried honestly pays from its first check.

The shape, frozen in part one

You declare one command; the platform keeps it in session memory:

agent: <command>     started as:  <command> -C <dir> [--yes] -p "<prompt>"

Without -p the same command opens the terminal UI (part six). The model behind the harness is a pluggable provider: every model call runs the command in AGENT_MODEL_CMD, writes the request to its stdin as JSON and reads the reply from its stdout. The checks plug in a scripted model, which is how a harness gets graded exactly; wiring a real API behind the same interface is your job — and your reward, because from part two on the thing codes for you.

The parts

1. The Loop — the headless agent: one prompt in, one answer out, the model protocol, a tool round trip, many turns, a provider registry with switchable models, retries, turn caps and the bill.
2. The Tools — read, write, edit, glob, grep and bash with real semantics; errors that come back as results; timeouts; a permission engine with allow/deny rules; parallel tool calls.
3. Context and Sessions — AGENTS.md up the tree with imports, @file mentions, environment in the system prompt, resumable sessions, and compaction when the context runs out.
4. Skills, Hooks and Agents — skills discovered and invoked, slash commands, pre/post tool hooks that can block, prompt and stop hooks, layered settings, and subagents that run their own loop.
5. MCP — stdio servers from .mcp.json: the handshake, tools advertised to the model and called through the server, errors, a server that will not start, prompts as commands, resources as mentions, environment and shutdown.
6. The TUI — the interactive face: a prompt, streamed answers, tool calls rendered, permission questions, slash commands, a status line with the bill, and an interrupt key that actually interrupts.
7. ACP — the agent inside an editor: the Agent Client Protocol over stdio, so any ACP client (Zed, Neovim, JetBrains…) can drive the same loop — sessions, streamed chunks, tool calls reported, permissions asked, cancellation, the editor's unsaved files, the client's MCP servers.

How it is scored

Every rung is verified by deterministic checks against your running agent — they start it with a scripted model, watch what it sends and does, and compare exact results. The review panel does not wait for the end: each judge sits on the rungs where its subject is decided and reads the repository as that rung lands — architecture where a seam appears, performance where a loop or a process is paid for, code quality and tests where the edge cases live, technical governance where a decision should be written down, and developer experience — what the tool prints, how it fails, how it explains itself — where the output is the point, judged from terminal recordings and raw output you deliver on request. A rung you never reach is a verdict you never get.

Wrapping claude, codex, gemini, aider or any other coding agent, or building on an agent SDK that owns the loop for you, is not building one. The loop, the tools, the permission engine, the MCP client and the TUI are yours. HTTP clients, JSON parsers and terminal-drawing libraries are tools, not the wheel.