Chapter 30

Ship an Agent Version, Not a "Live Prompt"

An agent isn't text in a dashboard but a version. A release pins the model id, the SDK lockfile, the prompt version, the tool schemas, the eval dataset, and the budgets. Any change of model or API passes the same suite, a canary, and observation of real failure modes - otherwise "we updated the model" will one day become an incident.

TypeScript

type AgentRelease = {
  agentVersion: "commerce-support-v1.3";
  provider: "openai" | "anthropic" | "google";
  model: string;
  promptSha256: string;
  toolSchemaSha256: string;
  evalDatasetVersion: string;
  sdkLockfileSha256: string;
  budgets: typeof AGENT_BUDGET;
};

Migration without the illusion of shared state is a discipline of several steps.

Run the offline suite on the new model and the new SDK version.
Compare the outcome, trajectory, latency, usage, and tool error rate.
Run shadow traffic with no side effects.
Give a small canary percentage with a fast rollback.
For a fallback between providers, start a new provider run from the normalized user context. Don't carry over an opaque response id or content blocks as if they were compatible.
After a stable window, expand traffic and keep the previous version until the end of the rollback window.

The whole final release gate can be assembled in the lab.

Interactive lab 6

Production release gate

The dataset includes ordinary and expensive edge cases
Ownership and tenant are checked inside the handlers
Commit is separated from the model tool loop
Max turns, timeout, tool budget, and result size are bounded
Traces are cleared of secrets and extra personal data
All three adapters pass a shared contract suite
Canary, rollback, and a provider-outage plan are verified
Model ids and API guidance are re-checked before deploy

0 of 8 checked. Open conditions remain before release.

Separately - how to read this book. Its claims were checked through lenses, and it's useful to do the same with your own agent.

Lens · What's checked · Critical prohibition

API protocol - Exact call ids, result blocks, continuation, and state; Don't mix the three APIs' formats
Application security - Identity, authorization, prompt injection, data minimization; Don't trust an actor id from the model
Transaction safety - Preview, approval, expiry, version, idempotency; Don't give the model a commit tool
RAG quality - ACL, effective date, citations, answerability; Don't answer without evidence
Reliability - Timeout, retry classes, loop caps, provider outage; Don't blindly repeat a side effect
Evaluation - Outcome, trajectory, safety, and operational metrics; Don't decide by one beautiful answer

Behind each lens sits a critical prohibition: don't mix the formats of the three APIs, don't trust an actor id from the model, don't give the model a commit tool, don't answer without an active source. If all four hold - the agent is built right.

And the honesty boundary, without which a book on live APIs goes stale.

TypeScript audit 2026-07-31. The shapes of the direct API calls were checked by the compiler with openai 7.2.0, @anthropic-ai/sdk 0.115.0, and @google/genai 2.15.0. The framework constructors were checked with @openai/agents 0.14.1 and @google/adk 1.5.0. This is a fixed verification set, not advice to pin exactly these versions forever.

The as-of date is part of the artifact. Model lines and APIs change faster than product logic. The claims and examples are verified against official materials as of 2026-07-31. Before a production deploy, re-check the model catalog, migration guides, feature maturity, and SDK release notes.

At this point the agent is assembled in full - from the task boundary to shipping a version. All technical claims are verified against primary sources; their full list is in the next chapter.

Knowledge check

What does an agent release pin?

Ship an Agent Version, Not a "Live Prompt"

Production release gate

Links