For leads: what a team’s time and money buy here

This page is for the person who decides whether a team spends its time on this material, and who may have to explain the choice to someone else. It has no code to read. Every figure on it comes from the runs recorded for Building AI Agents in Go, with the chapter that reports it.

What it costs to try

Nothing, to start. Every example in the companion code runs offline: without an API key, the programs replay model replies recorded from real runs, while the tools, go test among them, really execute. Each engineer can clone the repository and work through it with no account, no key, and no budget request. The code is Apache 2.0, and its 2,684 test functions run without a network.

Very little, to run live. With an inexpensive model, live runs are cheap, and the book reports what each chapter’s runs cost:

Run	Cost	Source
One live run of Part 1’s bug fix (40 runs measured)	no more than a fifth of a cent	Chapter 1
One crash-triage run on the default model, averaged over the confirmation tasks	$0.0081	Chapter 13
Two runs of each of 20 triage tasks, one of chapter 13’s exercises	$0.32	Chapter 13
The 99-report batch, before chapter 8’s context policy	$1.33	Chapter 8
The same batch after the policy, two runs	$0.06 and $0.42	Chapter 8
Each passing run of the finished agent on anthropic/claude-haiku-5.5	$0.0165	Chapter 17
Every run behind chapter 17’s tables, three models	$3.89	Chapter 17

Live calls go through OpenRouter on prepaid credit, so the worst case has a ceiling: when the credit runs out, calls fail rather than adding to a bill. The agent’s own budgets are a second ceiling: each run has a turn limit and a cost limit, and the finished service keeps a daily budget on disk, so a restart doesn’t reset it.

What the team will be able to build

The book ends with a crash-triage agent for a Go web service, running as a command and as a service. It groups crash reports by cause, writes a test that reproduces each one, fixes the code when a fix is safe, and files one issue per cause, pausing for a person before anything risky. Measured on 20 tasks it was never tuned on, it passed 70% of runs on its default model, with a range of 53 to 85%, at under two cents per passing run.

Crash triage is the running example, and the skills are general. Along the way an engineer builds every part an agent needs, with tests, and the same parts carry over to agents that do other work; beyond crash triage walks through three. They come away able to read any agent framework and see what it does underneath, so the team can decide on evidence whether to build its own harness or adopt one.

The risks, and how they’re handled

Each risk below is one the book measured, and each answer is code the team writes and tests.

An agent that loops or overspends. A turn limit, a cost budget, and a named reason for every stop, which callers check in code (chapter 5). The finished service keeps its spending on disk across restarts (chapter 17).

An improvement that is really chance. In chapter 13, two runs of one unchanged agent over one set of tasks scored 15 points apart. Its evals put a range around every rate and compare versions task by task, so the team can tell when a prompt or model change helped.

Text that steers the model. One sentence in a tool description decided the model’s first move in 79 of 80 replies across four models (chapter 10). The defenses don’t rely on the model obeying: a sandbox for the tools, limits on what may leave the machine, and a person’s approval for risky actions (chapter 14). In chapter 17’s runs, no model did what a planted instruction asked.

An action that can’t be undone. Protected paths need a person’s approval, and the agent starts on a new codebase in diagnose-only mode, where the tool that edits code isn’t offered at all (chapters 14 and 17).

A crash halfway through. Runs are saved as they go, and every call that changes something carries an idempotency key. Chapter 15 crashed a run at every point a crash could land and resumed it: 910 scenarios, with nothing filed twice and nothing lost.

More agents than the job needs. Splitting a batch across four agents at once finished no sooner and cost 25 to 60 percent more than one agent (chapter 9); workflow or agent shows how to pick the simplest shape that does the job.

Models and prices that change. The model is one setting, the recorded replies keep every test passing after a model is retired, and chapter 17’s results table carries its dates and is meant to be measured again whenever any input to it changes.

Lock-in to a framework. Chapter 16 compares five Go agent frameworks part by part against the harness the team wrote, and closes with eight questions to put to any framework; it ranks none of them.

The launch checklist collects these into items a design review can check, and twelve measured mistakes shows what happened in the runs where one was missing.

What it leaves out

Retrieval over large document sets, memory kept across unrelated tasks, and a model that plans work and hands it to other agents at run time are all out of scope, along with user interfaces and fine-tuning. What this covers gives the reason for each and the signs that a team’s task needs one.

Getting a team started

1. The free code. Clone the repository and run go run ./ch01 from its code directory; Run it lists every chapter’s program and its command.
2. The reading paths. Start here has an ordered path for engineers new to agents and one for engineers shipping soon.
3. The free sample. The introduction and the first part of chapter 1, as a PDF.
4. The book. Building AI Agents in Go has the full build, the tests, the exercises, and the reasoning behind each decision. Team licenses are available; ask through Work with me.
5. A workshop. A hands-on workshop in which the team builds an agent in Go from the loop up; Work with me describes it.