At last, the final chapter. By now, you've come all the way to understanding an agent's structure, building your first one, connecting tools, splitting into several, measuring with evaluation, and protecting with guardrails. One theme remains — turning it into a "production system that keeps running every day." In this chapter, we cover how to choose a framework, the two paths for building with Claude, and the operational knacks of deployment, monitoring, cost, and reliability. The defensive design you learned in the previous chapter, Guardrails and safety, bears fruit here as operations.
The goal: "turn a prototype into a production agent that keeps running stably"
Build it yourself, or use a framework
"Should I build an agent with a framework, or write the loop myself?" — the question everyone wavers over first. The answer is simple: while it's small, build it yourself to learn the mechanism; once it grows, raise productivity with an SDK or framework. Hand-assembling the minimal setup in Chapter 2 was exactly that "understand it yourself first" stage. If you can see the insides, you can later swap it onto a framework and still operate it while grasping what's happening. Conversely, offload it to a framework without knowing the mechanism, and when you get stuck you're helpless.
💡 A rule of thumb for deciding. When continuing to write the loop, tool calls, and state management yourself becomes a burden, that's the sign to bring in a framework. Conversely, while you're still small and experimental, thin home-grown code is faster and deepens understanding. Bring one in "because it reduces duplication," not "because it's handy."
How to choose a framework
There are many frameworks, but before chasing names or the latest versions, it's important to have a yardstick for "what to choose by." Tools change, but this perspective stays useful for a long time. Try evaluating candidates by these five.
Higher means running on less code, but it's harder to see what's happening inside. Choose by balancing against learning and debugging.
Can you slot in your own loop or control? The more elaborate the requirements, the more a flexible design with escape hatches pays off.
The depth of integration parts, docs, examples, and community. Whether you can find information when stuck matters in practice.
Does it have mechanisms for tracing, logging, and evaluation? Does it support the "visibility" from Chapter 5 out of the box?
Is it over-bound to a particular model or platform? Ease of switching and the convenience of lock-in are a trade-off.
Roughly sorting the representative examples by category makes the landscape clearer. General orchestration (libraries that assemble LLM processing with chains and graphs — the so-called LangChain family), multi-agent (frameworks focused on division and coordination of multiple agents), and each vendor's official SDK (a development kit from a model provider, optimized for that model). In many cases these aren't exclusive and can be used in combination.
📊 Choose by "perspective," not by individual name. The balance of power among frameworks moves fast; last year's standard isn't necessarily this year's. That's exactly why using the five perspectives above as a yardstick and applying them to your own requirements is the reliable move. For concrete names by category and how to use them, check the latest lineup in AI agent frameworks compared.
Two options for building with Claude
This course has centered on Claude. When productionizing an agent with Claude, there are broadly two paths. Both are real options, and the essential difference is "who hosts the agent's loop and sandbox."
A kit for running the agent's loop, tool execution, and state management in your own environment (servers or containers). Control is fine-grained, and it can be deeply embedded into existing systems.
Good when: you want tight coupling to your own runtime, tools, and data.
An approach where Anthropic hosts the agent's loop and sandbox (an isolated runtime) on the server side. It reduces the operational burden of the execution platform and runs in an isolated, safe environment.
Good when: you want to reduce the hassle of the runtime and stand something up quickly and safely.
Roughly, it's easy to grasp along the axis of SDK if you want fine control yourself, managed if you want to offload the operational hassle. Both build on Claude's capabilities, and you can carry over the tool connection, evaluation, and guardrails you learned in earlier chapters as-is. Since the concrete setup and scope of support can change, we leave the details to the explainer articles and official docs.
💡 Concept first, details from primary sources. Just keep this contrast in mind — "turn the loop yourself (SDK)" or "have it hosted (managed)" — and that's enough. For implementation steps, see Getting started with the Claude Agent SDK; for the thinking behind the managed approach, What are Claude Managed Agents. Specs get updated, so ultimately checking the official docs as the primary source is the safe course.
The knacks of production operation
The difference between a prototype and production lies in the leap from "it runs once" to "it keeps running." A demo holds up if it works a few times, but production is exposed to daily, high-volume, diverse input. Let's pin down the knacks that count here in six boxes.
Manage keys with environment variables and separate config from code. Ship in a reproducible form (containers, etc.) so you can always roll back.
Connect Chapter 5's observability to production. Constantly watch per-step traces, success rate, and latency, and notice anomalies fast.
Make token consumption visible and set cap alerts. Trim wasteful reruns and overlong context, and use different models by purpose.
Anticipate API limits and transient failures, and persist with exponential backoff (retry with widening intervals). Avoid infinite retries; set a cap.
Save and restore the in-progress state of conversation or work safely. A design that can resume from where it left off, even after a crash, supports long-running tasks.
For model or SDK updates, check behavior on the eval set first. Compare before and after to not miss quiet quality shifts.
⚠️ Cost is decided by "design." Because an agent calls the model many times per task, it's structurally prone to cost spikes. Route stages where a cheap model suffices to a cheap model, and hand over only the context you need — these humble efforts pay off. For concrete reduction techniques, Cost optimization for AI coding is practical and applies directly to agent operation too.
Designing so it doesn't collapse
A production agent will inevitably, at some point, meet unexpected input, an external API outage, or the model's whims. What matters is not "never let it fail" but building it so that even when it fails, the damage doesn't spread and it recovers quietly. Let's finish the previous chapter's guardrails as operational mechanisms.
Rather than going fully public at once, start from a few users or a slice of traffic. Widen if there's no problem; roll back instantly if there is.
When a tool or model doesn't respond, retreat to an alternate path or a safe default response. Choose partial degradation over a total halt.
Insert a human check before irreversible, high-impact operations (see Chapter 6). Decide where to choose safety over speed.
Passing once isn't the end. Input trends and models change. Run the eval set periodically to detect quality degradation.
✅ Design for "quiet recovery." A good production system doesn't turn into a commotion when trouble strikes. Staged release keeps the impact small, fallback degrades partially, the approval gate prevents fatal blows, and re-evaluation gets ahead of degradation. Only when the four mesh does it become "collapse-proof."
Learning from here
Finally, a word about what's a little further ahead. The agent ecosystem — frameworks, SDKs, models, connection standards — will keep moving at a furious pace. Today's optimum isn't necessarily next year's. That's precisely why what you should chase is not the trendy tool name, but the fundamentals that don't change.
📊 It's the fundamentals that become assets. Chapter 1's four building blocks (brain, tools, memory, loop), Chapter 5's evaluation and observability, Chapter 6's safety design — these are a foundation that holds up whatever framework is in fashion. Each time a new tool appears, you can quickly see through "what is this abstracting?" with this yardstick. Tools come and go; the fundamentals remain. The understanding you've built up this far is your greatest asset.
All that's left is to actually put one out into production — small is fine. Running the loop of run, measure, and fix on your own project will do more for you than any teaching material.
- While small, build it yourself to learn; once it grows, use a framework for productivity. Bring one in for "reduced duplication," not "handy."
- Choose a framework by five perspectives — abstraction, flexibility, ecosystem, observability, vendor lock-in. Yardstick over individual names.
- For building with Claude, it's the self-hosted-loop Claude Agent SDK or the hosted Managed Agents. Choose by control vs. ease.
- The production knacks are deployment, monitoring, cost, retries, state management, and updates. And keep it from collapsing with staged release, fallback, approval gates, and re-evaluation.
- The ecosystem moves fast. The fundamentals — four elements, evaluation, safety — are the asset that pays off for the long term.
Well done making it through all seven chapters. You've walked the whole road — from designing, building, connecting, scaling, measuring, protecting, and operating an agent. From here, it's your turn to get your hands moving on your own product.
For those who want to step back from building and sharpen the perspective of putting AI to work.
To the AI at Work course →For those who want to master coding tools like Claude Code.
To the AI Coding course →For those who want to grow the agent they built into a solo-dev product to ship to the world.
To the Solo Development with AI course →