2. Agents

What the root agent is, and which chapters extend it

The root agent is one Go value: an ADK llmagent.Config holding a model, an instruction string, and a flat list of tools, assembled in agents/go/compose/composition.go. Every chapter after this one adds to that same value rather than replacing it: Chapter 3 gives it capabilities, Chapter 4 wraps it in quality checks, Chapters 5 and 6 put it behind a gateway and onto Kubernetes, Chapter 7 watches it in production — and by 7.7 the agent itself is the incident. So learning where each part lives pays out five more times.

A composition is one wiring of that value with the agents around it; the repository ships three. Compose.RootAgent(), in agents/go/compose/compose.go, reads AGENT_ENTRYPOINT and builds exactly one of them: the conversational agent by default, the triage workflow, or the coordinator.

The policy callbacks — hooks around every model and tool call — sit on the application rather than on any single agent, which is why a sub-agent you add next month is governed the moment it exists.

This page routes each field to its owning page and confirms the agent assembles before any model runs. The worked example is incident response, read from a committed SQLite seed.

Prove the agent assembles before you run a turn

1.1. Go already ran that proof: mise run test inside agents/go runs the offline suite and enforces the 80% per-package coverage floor — the share of each package’s statements its tests must execute. Green there means the agent assembles; red means fix that first.

Before you have run a single turn, the composition, the configuration, the persistence, and the policy plane have all been exercised on your machine — in well under a minute, with no account, no API key, and no network.

That green run says nothing about whether the agent reasons well: nothing in it called a model. Keeping those two kinds of green apart is what 0.2. Evidence is for.

Which page and which module own each part of the agent

Each field traces to exactly one page, so a surprising behavior has one place to go rather than six.

Read them in order. 2.0. Concepts (concept) is the only page that asks you to think before typing; 2.1. First Agent (hands-on), 2.2. Models (hands-on), 2.3. Instructions (hands-on), 2.4. Sessions (hands-on), and 2.5. Dev Loop (hands-on) put you at a terminal.

Tools and policy hooks are named here and taught next: Chapter 3 owns each tool, and 4.5. Guardrails owns the policy plugin.

    flowchart TD
    concepts["Runtime concepts · 2.0<br/>Agent · Runner · Session · Events"]
    subgraph agent["Compose.RootAgent() in compose/compose.go — composition in compose/composition.go · 2.1"]
        model["Model = model.Build() · 2.2"]
        instr["Instruction = compose.Instruction() · 2.3"]
        tools["Tools = reads · actions · memory<br/>Toolsets = skills<br/>policy plugin on App · Ch. 3 / 4.5"]
    end
    runtime["Persistent runtime · 2.4<br/>Config.SessionService · A2A tasks · a2aserver/a2aserver.go"]
    loop["Dev loop · 2.5<br/>mise run test · run · web · a2a"]
    concepts --> agent
    agent --> runtime
    loop -. iterates .-> agent
  

What this chapter proved

The other five pages are where you break things and watch them fail. This one has settled four smaller questions you can check:

• mise run test passes in agents/go and reports every package above the 80% floor, with no model and no network.
• You can name the file that assembles the agent and the file that decides which composition gets built.
• You can say what that green run deliberately says nothing about, and where the course draws that line.
• When a later page surprises you, the table above names the page that owns it.

Continue to 2.0. Concepts once mise run test is green, because every page after this one assumes the agent already builds.