Build a Production Claude Agent: Step-by-Step Walkthrough

There are a thousand blog posts that show you a fifteen-line agent that calls one tool and prints a result. There are far fewer that show you what it takes to get that agent to the point where you'd let it touch a real customer account. This walkthrough is the second kind. We're going to build an order-status-and-returns agent on Claude, one layer at a time, and at each step I'll tell you what to add and why the naive version isn't enough.

You can follow this with the Claude Agent SDK or a hand-rolled loop against the Messages API; the steps are the same. Assume Sonnet 4.6 for the main loop and Opus 4.8 reserved for escalated cases. Let's build.

Step 1: Stand up the bare agent loop

Start with the minimum viable loop. You send Claude a system prompt and the user message along with a list of tool definitions. Claude either answers or returns tool-use blocks. You execute the requested tools, append their results, and call again. You repeat until Claude returns a final text answer or you hit a maximum-turns cap — set it to something like eight for a focused task.

The cap matters more than it looks. Without it, a confused agent can loop indefinitely, burning tokens and your budget, especially if a tool keeps returning ambiguous errors that the model keeps trying to "fix." The turn limit is your first guardrail, and you want it in from the very first commit. Log the turn count on every run so you can see when agents are running long — that's an early signal of a prompt or tool problem.

Step 2: Define tools the model can actually use well

Our agent needs two tools to start: get_order and initiate_return. The schema is part of the prompt, so write it like documentation a new engineer would read. Give each tool a one-sentence description of when to use it, name parameters in plain language, mark required fields, and describe the shape of what it returns. A tool described as "gets order" performs measurably worse than one described as "Look up a single order by its ID; returns status, line items, and whether it's eligible for return."

flowchart TD
  A["Customer message"] --> B["Assemble context + tool schemas"]
  B --> C{"Claude: answer or call tool?"}
  C -->|Answer| G["Validate & return reply"]
  C -->|get_order| D["Fetch order from system of record"]
  C -->|initiate_return| E["Policy gate: eligible & approved?"]
  D --> F["Append tool result"]
  E --> F
  F --> C
  G --> H["Trace + eval log"]

Notice in the diagram that initiate_return routes through a policy gate before it executes, while get_order is a plain read. That asymmetry is deliberate and it's the single most important design choice in the whole agent: reads are cheap and safe, writes need a gate.

Step 3: Separate read tools from write tools

Make every read-only tool freely callable and put every state-changing tool behind validation. For initiate_return, before you ever call the returns API, your code — not the model — checks that the order exists, that it's within the return window, and that the customer on the session owns that order. Only if all those pass does the actual write happen. If any fails, you return a structured error to the model so it can explain the situation to the customer instead of silently failing.

This is the practical expression of "the model decides, the harness enforces." Claude can propose a return for any order it likes; your code is the one that actually moves money or inventory, and it only does so when the deterministic checks pass. Treat write tools as a small, audited surface no matter how clever the prompt gets.

Step 4: Make tool execution resilient

Real APIs time out, rate-limit, and occasionally return garbage. Wrap each tool call with a timeout, a couple of retries with backoff for transient failures, and a clear mapping from raw exceptions to model-readable error messages. When the orders API returns a 503, the model shouldn't see a stack trace; it should see {"error": "order_service_unavailable", "retryable": true} so it can decide to apologize and offer a callback rather than hallucinate an answer.

Idempotency belongs here too. If initiate_return can be called twice — because of a retry or a model that re-proposes the same action — generate an idempotency key from the order ID and operation so the downstream service deduplicates. Nothing erodes trust in an agent faster than a customer getting two return labels for one request, and at enterprise scale duplicate writes are a when, not an if.

Step 5: Write the system prompt as an operating manual

The system prompt is where you set the agent's role, its boundaries, and its escalation rules. Be specific: state that it handles order status and returns only, that it must verify order ownership before discussing details, that it should escalate to a human for anything involving fraud or amounts over a threshold, and that it must never invent order details not returned by a tool. Give it one or two worked examples of good behavior, including an example of correctly refusing to act.

Resist the urge to cram every edge case into the prompt. Long, contradictory prompts confuse the model as much as they confuse a new hire. Put durable, reusable know-how into an Agent Skill the model loads when relevant, and keep the system prompt focused on this agent's core job and hard rules. A tight prompt plus a good skill beats one enormous prompt every time.

Step 6: Build evals before you build features

Before adding a third tool, assemble a test set of twenty to fifty real-ish conversations with known-correct outcomes: a valid return, an out-of-window return, a wrong-customer attempt, an order that doesn't exist, an API outage. Run the agent against all of them on every change and score whether it took the right action and gave the right answer. This is your regression net, and it's the difference between shipping confidently and praying.

The payoff compounds. When you later tweak the prompt or swap models, the eval set tells you in seconds whether you broke the wrong-customer check or the outage handling. Teams that build evals first move faster forever after, because they can change things without fear. Wire the eval run into CI so a regression blocks the deploy automatically.

Step 7: Roll out behind a gate and watch the traces

Don't flip the agent on for everyone. Start with internal users, then a small percentage of real traffic, with every run fully traced and every write action either shadowed or human-approved at first. Watch the traces for the patterns evals can't predict — weird phrasings, tools called in surprising orders, customers trying to jailbreak the policy. Promote to wider traffic only when the traces are boring.

Frequently asked questions

How many turns should an agent loop allow?

Set a hard maximum per task — often around six to ten for a focused agent — and log the turn count on every run. The cap prevents runaway loops and token burn, and rising turn counts are an early signal that a prompt or tool is unclear.

What's the right way to handle state-changing tools?

Put every write tool behind deterministic validation and an idempotency key. Let Claude propose the action, but have your code verify ownership, eligibility, and limits before executing, and dedupe repeated calls so retries can't double-act.

Why build evals before adding more features?

Agents are non-deterministic, so a change that fixes one case can quietly break another. A fixed eval set of real scenarios, run on every change and wired into CI, catches regressions in seconds and lets you refactor prompts and swap models without fear.

Should everything live in the system prompt?

No. Keep the system prompt focused on the agent's role, hard rules, and escalation policy. Move reusable, detailed know-how into Agent Skills the model loads on demand, and route authoritative facts through tools rather than baking them into the prompt.

Bringing agentic AI to your phone lines

These exact build steps — a capped loop, gated write tools, resilient execution, and evals first — are how CallSphere ships voice and chat agents that handle real customer calls and book work safely at scale. Watch them in action at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.