Skip to content

Agent SDK

  • An agent is a loop: call the model with messages and tool definitions, execute the tool calls it returns, append the results, and repeat until it answers or a limit stops it. Everything else is policy around that loop.
  • Providers stream deltas, not messages. Text and tool-call arguments arrive as fragments that must be reassembled, and a retry is safe only before the first content delta.
  • Tools are an attack surface. Arguments are validated against a JSON Schema, a gate decides allow, deny, or needs-approval before dispatch, and text that came from a retrieved document or a tool result never authorizes a write.
  • Long agent runs need durability. Each model call and tool call is a recorded step, so a killed worker resumes without calling the model or the tool twice.

Read Building effective agents first, then the ReAct paper. Port the safety gate of case study 02 to Go before ag.04. In the course, the SDK is built in Pass 10 against the learner’s own gateway and engine (SmolLM2-135M-Instruct with tool calls), with a frontier provider usable through the same Provider interface.


The model proposes; the program disposes. A language model can only emit text that names a tool and its arguments; the SDK decides whether that call runs, with what limits, and what happens when it fails halfway. Designing the SDK means designing those decisions as typed, testable code: a provider interface, a tool registry, a gate, a step runner, and a loop with budgets.

Key ideas:

  • Messages, tool calls, tool definitions, deltas as Go types, and a Provider with ChatStream returning a channel of deltas (ag.01).
  • One provider for every backend: the learner’s gateway and a frontier API speak the same OpenAI-compatible subset.

Key ideas:

  • Tool has a Definition (name, description, JSON Schema) and Execute; invalid arguments return a tool error to the model, never a panic (ag.02).
  • The loop (ag.03) bounds iterations, parallel tools (preserving result order), and spend, and stops before dispatch when a budget would break.

Key ideas:

  • Gate.Check returns Allow, Deny{Reason}, or NeedApproval{Marker} (ag.04); the deterministic SQL gate from case study 02 rejects every statement in the BLOCKED corpus.
  • Injection suite: instructions planted in retrieved chunks and tool results never trigger a gated or write tool without approval.

Key ideas:

  • AgentRun (ag.05) runs each step through a StepRunner on the learner’s durable engine; a write tool with an unknown outcome yields ErrIndeterminate and waits for a reconcile signal instead of guessing.
ModuleTopicKindPass
ag.01Types, OpenAI-compatible provider, retry wrapperbuild10
ag.02Tools, registry, JSON Schema argument validationbuild10
ag.03Agent loopbuild10
ag.04Tool gate and deterministic SQL safety gate (case study 02 ported)build10
ag.05Durable agent runs (AgentRun)build10

Retrieval (ag.06 to ag.08) lives in Retrieval & RAG and evaluation (ag.09 to ag.12) in LLM Evaluation; together they close milestone MS-agent.

#ModuleChapterKindPass
1ag.01Types, OpenAI-compatible provider, retry wrapperbuild10
2ag.02Tools, registry, JSON Schema argument validationbuild10
3ag.03Agent loopbuild10
4ag.04Tool gate, SQL safety gate, prompt-injection suitebuild10
5ag.05Durable agent runs (AgentRun)build10
TrackConnection
Retrieval & RAGsearch_docs, the agent’s retrieval tool
LLM Evaluationagent suites run the loop as their subject
Gatewaythe provider endpoint, keys, limits, and usage policy
Durable Orchestration & Workersthe engine behind AgentRun
Usage policywhat the gateway refuses before a request reaches the agent
CompanyPractice
Anthropic, OpenAItool use APIs and agent SDKs built on the same loop
Temporaldurable agent workflows where every model and tool call is a recorded activity