AI Engineering from Scratch

Manuals

Each manual explains one subject at one exact version, from its purpose to each request and response. The examples come from recorded runs of a working system, and each rule links to the specification text that it comes from.

  • Read

    The web edition, with figures that play as you scroll.

  • Keep

    A PDF of the same text, attached to every release of the course.

  • Rerun

    A capture kit that regenerates every listing in the manual with one command.

A2A protocol 1.0.1 · 3303592 · 2026-05-28 · Edition 2026.10

A2A 101

The Agent2Agent protocol, from its purpose to each request and response

How one agent gives work to another agent that it cannot see inside. Each request, response, and stream event in this manual comes from a recorded run.

  • The Protocol on One Page
  • AgentCard
  • Data Model
  • Operations
  • Bindings
  • Security and Extensions
  • Implementing A2A
7 parts · 28 sections · 31 figures
Read the manualDownload the PDFSource files
Plate IOne planner, three remote agents
One planner, three remote agents The planner from capture/planner.py on the left and three lanes, one per delegation, in the order it ran them. In each lane the planner calls a remote agent, shown with its port and skills, and the agent runs a task shown with its states. test-runner completes with 13 passed. code-reviewer asks which base branch to use, the planner answers main, and the task completes with one finding. deployer waits in TASK_STATE_AUTH_REQUIRED until an operator approves, while the planner follows the task with SubscribeToTask, and then completes. CLIENT AGENT REMOTE AGENT THE TASK IT RUNS planner client agent reads 3 cards, then delegates test-runner port 41241 skill run-tests SendMessage task 954267b7 TASK_STATE_COMPLETED summary.json: 13 passed code-reviewer port 41242 skills review-diff, answer-question SendMessage task 80bc7784 TASK_STATE_INPUT_REQUIRED asks for the base branch the planner answers: main TASK_STATE_COMPLETED review.json: 1 finding answer: main deployer port 41243 skill deploy bearer token required SendMessage task a31361b3 TASK_STATE_AUTH_REQUIRED waits for an operator the planner subscribes TASK_STATE_COMPLETED build live on staging SubscribeToTask operator outside A2A approves
The planner reads three cards and delegates three tasks: one completes at once, one after a question, and one after an operator approves. Lanes run top to bottom in the order of capture/out/19-planner.log, and ids are shortened to 8 characters.
Docker Sandboxes (sbx) and Docker Agent (docker-agent) sbx 0.47.0, docker-agent 1.149.0 · bf4169c · 2026-10-07 · Edition 2026.10

Docker Sandboxes and Docker Agent 101

Isolated microVMs for coding agents, and the agent runtime that runs inside them, command by command

How to run an agent you do not trust on files you do. Every listing in this manual comes from a recorded run of sbx and docker-agent on one Mac.

  • The Two Products on One Page
  • sbx run
  • sbx policy, sbx secret, sbx mcp
  • Kits and sbxenv.yaml
  • docker-agent run and the Agent File
  • docker-agent serve and share
  • Operating It
7 parts · 33 sections · 34 figures
Read the manualDownload the PDFSource files
Plate IOne agent, one microVM, one proxy
One agent, one microVM, one proxy The recorded docker-agent run --sandbox on the capture Mac. On the host, docker-agent v1.149.0 stages the kit sandbox-kits/<hash>, writes the allowlist with models.dev and localhost:12434 into the proxy rules, and asks sbx and sandboxd to create the sandbox, which becomes running. Below the Hypervisor.framework line, the microVM docker-agent-<hash> from docker/docker-agent-sbx-templates:latest holds docker-agent version main, its filesystem and shell tools, the workspace mounts, and an environment whose proxy is gateway.docker.internal:3128 and whose provider keys read proxy-managed. The model call goes up to host.docker.internal:12434, through the proxy, and on to Docker Model Runner on port 12434 with ai/qwen3:4b. The answer is: The working directory contains README.md with 1 line. HOST · MACOS 26.2 ARM64 docker-agent run --sandbox --exec files-sandbox.yaml docker-agent v1.149.0, Homebrew sbx, sandboxd v0.47.0 proxy :3128 on the host Model Runner ai/qwen3:4b sandbox-kits/<hash> the staged kit allowlist models.dev localhost:12434 created, running create stage allow proxy rules :12434 docker-agent version main commit 154b78f2 runs files-sandbox.yaml host.docker.internal:12434 through HTTP_PROXY Hypervisor.framework · kern.hv_support: 1 microVM docker-agent-<hash> · docker/docker-agent-sbx-templates:latest workspace mounts repo-sandbox rw, agents ro sandbox-kits ro, cfg ro environment HTTP_PROXY gateway.docker.internal:3128 ANTHROPIC_API_KEY=proxy-managed filesystem, shell tools that act on the mounts inside the VM The working directory contains README.md with 1 line.
The agent runs in a microVM that sbx creates, its model call leaves through the host proxy, and the provider keys inside are placeholders. Read top to bottom. From capture/out/27-sandbox-run.txt, 27-inside.txt, and 27-inside-run.txt.