Claude agent development that earns its place in production.
Anyone can wire a Claude demo that loops over a tool. Claude agent development is the gap between that demo and a system you can run, bill for, and trust — typed tool contracts, multi-agent orchestration where it earns its keep, guardrails in code, and the evals and observability that make it operable. We build on the Claude Agent SDK, ship it to your cloud, and stay on call.
The demo takes an afternoon. Production takes the rest.
Four things break the moment a Claude agent stops being a notebook cell and starts touching real systems and real users.
The loop runs forever
A demo answers once. A production agent loops over tool calls until it decides it is done — and that decision is where cost, latency, and runaway behavior live. You need budgets, step caps, and a kill switch that is part of the design, not a patch.
Tools fail in ways prompts don’t
The model is reliable; the API behind your tool is not. A 500, a timeout, a partial write — the agent has to retry, fall back, or surface the failure cleanly. Most demos never call a real system twice.
You can’t see what it did
When a multi-step run goes wrong, "it hallucinated" is not a root cause. Without traces of every tool call, input, and intermediate decision, you are debugging a black box in front of a customer.
Quality drifts silently
The same prompt that scored well last month degrades as inputs shift and models update. Without an eval set that runs on every change, regressions ship to production and nobody notices until support does.
Four layers. The model is the easy one.
We build on the Claude Agent SDK and add the parts that decide whether it survives contact with production — typed tool use, multi-agent orchestration, and guardrails written in code.
Claude Agent SDK as the spine
We build on the Claude Agent SDK rather than re-inventing the loop — context management, the agentic harness, and tool dispatch are battle-tested. We add the typed graph, the budgets, and the integration code on top.
Typed tool contracts
Every tool the agent can call is a typed schema with explicit inputs, outputs, and failure modes — wired to the systems your team already runs, or exposed over Model Context Protocol (MCP) so the same tools serve every agent.
Multi-agent orchestration with Claude
When one agent shouldn’t do everything, we split the work: a planner, specialist sub-agents, and a verifier. Each has a narrow tool set and its own eval, so you can reason about — and bound — what any one of them can do.
Guardrails, not vibes
Input validation, output schemas, PII and jailbreak checks, allow-listed tools, and hard budget caps. The agent operates inside a fence you can read in code, not a hope that the prompt holds.
If we can’t measure it, we won’t operate it.
The graph on the left is how we draw an agent — every node typed, every arrow a tool call. The panel on the right is the eval gate it has to clear before, and after, it ships.
- tracesEvery run is a span tree — prompt, each tool call, the inputs and outputs, the final decision. Wired to OpenTelemetry into your existing stack.
- evalsGolden sets and LLM-as-judge graders run nightly and on every pull request. A model or prompt change that drops a score blocks the merge.
- cost + latencyToken spend and p50/p95 latency per agent, per tool, per route — so a regression shows up as a chart, not a surprise on the invoice.
- drift alarmsLive grading of a sample of production traffic. When real-world quality slides below the line, we get paged before your users complain.
A bounded loop, a typed tool, an observable run.
Not a screenshot — the shape of what lands in your repo. A step cap and an honest failure path are part of the design, not bolted on later.
import { query, tool } from "@anthropic-ai/claude-agent-sdk";import { z } from "zod"; // A typed tool contract — explicit inputs, explicit failure mode.const lookupOrder = tool( "lookup_order", "Fetch an order by id from the orders service.", { orderId: z.string() }, async ({ orderId }) => { const res = await orders.get(orderId); if (!res.ok) { // Surface failure to the loop — do not pretend it succeeded. return { ok: false, error: `orders service returned ${res.status}` }; } return { ok: true, order: res.data }; },); // The agent loop, bounded: a step cap is a guardrail, not an afterthought.const run = query({ prompt: "Resolve the customer's refund request end to end.", options: { model: "claude-sonnet-4-6", tools: [lookupOrder, issueRefund, escalateToHuman], maxTurns: 8, // hard cap — the loop cannot run forever },}); for await (const event of run) { trace(event); // every tool call and decision is observable}We ship it to your cloud, then we stay on call.
The agent runs in your account, under your data agreement and keys — reachable via the Messages API, AWS Bedrock, or Google Vertex AI. Operate is not a handoff; it is the part most teams skip and the part that fails.
Ship guarded
First production traffic runs behind a feature flag with a fallback path. Budgets and the kill switch are live on day one.
Harden
Load, cost, and failure-mode testing. Retry and fallback policy proven. SRE review, runbook written, alarms wired.
Operate
We stay on call. Eval harness runs nightly, graders get tuned as the world changes, and a model update never reaches users before it clears the suite.
What teams want answered before they greenlight an agent.
A chatbot answers in one turn. An agent runs a loop — it calls tools, reads the results, decides what to do next, and repeats until the task is done. That loop is what makes agents useful and what makes them hard: cost, latency, failure handling, and observability all live in the loop, not the prompt.
We build on the Claude Agent SDK by default. The agentic harness, context management, and tool dispatch are solved problems we do not want to re-implement per client. Our work is the typed tool graph, the guardrails, the integration code, and the eval and observability layer on top of it.
A single agent is simpler and we reach for it first. We split into multiple agents — a planner, specialist sub-agents, a verifier — when one agent would need too many tools to reason about safely, or when steps have genuinely different tool sets and evals. Multi-agent orchestration with Claude is a means to bound blast radius, not a default.
Guardrails in code: allow-listed tools, output schemas, input validation, PII and jailbreak checks, hard budget and step caps, and a kill switch. Anything irreversible — a refund, a delete, a send — routes through an explicit confirmation or a human-in-the-loop step. The fence is readable in the repo, not implied by a prompt.
Evals: a golden dataset plus LLM-as-judge graders that run nightly and on every pull request, so a prompt or model change that drops quality blocks the merge. Observability: every run is a trace of its tool calls and decisions, with token cost, latency, and drift alarms wired into your existing stack. Production AI agents with evals and observability are the only ones we are willing to operate.
We pick from the current Claude family — Opus 4.8, Sonnet 4.6, Haiku 4.5, or Fable 5 — by routing the right model to the right step rather than using one everywhere. The model is a swappable dependency in the graph, so a newer model is a config change gated by the eval suite, not a rewrite.
Yours. We run in your cloud account, under your data agreement and key management. Claude is reachable directly via the Messages API or through AWS Bedrock or Google Vertex AI, so the agent fits your existing procurement and residency posture.