Building AI Agents with the Claude API & Agent SDK

The most expensive mistake in agent engineering is building an agent where a workflow would do. A workflow is a fixed sequence of LLM calls your code orchestrates — classify, then extract, then draft. Deterministic, testable, cheap. An agent hands the model the steering wheel: given a goal and tools, Claude decides which steps to take and when it is done.

Reach for a true agent only when the path genuinely cannot be predetermined — debugging, open-ended research, multi-system investigations where the next action depends on what the last one revealed. A useful decision test:

• Can you draw the flowchart in advance? Build a workflow.
• Does the branching depend on intermediate results in ways you cannot enumerate? Build an agent.
• Unsure? Start with a workflow and promote the genuinely dynamic segment to an agent later.

Autonomy is a cost — in tokens, latency, and verification burden — so spend it only where it buys capability.

Strip away frameworks and every agent is the same loop: send the conversation with tool definitions, execute whatever Claude requests, append results, repeat until the model stops calling tools or a budget runs out.

for turn in range(MAX_TURNS):
    resp = client.messages.create(model=MODEL, tools=tools,
                                  system=goal, messages=history,
                                  max_tokens=4096)
    if resp.stop_reason != "tool_use":
        return resp  # agent is done
    history += [assistant(resp.content),
                user(execute_all(resp.content))]
raise AgentBudgetExceeded(history)

The interesting engineering is in the budgets and the transcript. Cap turns, wall-clock time, and token spend explicitly — an agent without limits is an incident waiting for a pager. And treat the message history as your primary debugging artifact: persist it per run, because “why did it do that?” is answered by replaying the transcript, not by re-reading your prompt.

You can hand-roll the loop above, and for a single-tool assistant you probably should. The Claude Agent SDK earns its place when agents get real: it provides the production agent loop with context management built in, so long-running sessions compact history instead of overflowing the window; a tool and hook system so you can intercept, permit, or deny actions before they execute; sub-agent spawning for parallel work; and session persistence for tasks that outlive one process.

The architectural shift is subtle but important — with the SDK you stop writing orchestration code and start writing policy: which tools exist, what requires approval, how much budget each task class gets, what gets logged. That policy layer is where enterprise requirements live, and it is far easier to audit than bespoke loop code scattered across services. Our Claude Code bootcamp covers the SDK hands-on, from first loop to multi-agent systems.

Agents are only as capable as their tools, and tool sprawl is a genuine failure mode: every team hand-wiring bespoke integrations into every agent. The Model Context Protocol (MCP) is the standard answer — an open protocol for exposing tools and data sources through servers that any MCP-capable client, including the Agent SDK, can consume.

The enterprise payoff is separation of concerns. The team that owns your ticketing system publishes one MCP server with search, read, and comment tools; every agent in the organisation connects to it rather than reimplementing the integration. Security posture improves too, because the server is a single choke point for authentication, authorization, and audit logging.

• Expose capabilities, not raw APIs — “find_customer_orders” beats a generic SQL tool.
• Keep read and write tools separate so permissions can differ.
• Version servers like any API contract; agents are consumers.

An agent’s blast radius is defined by its tools, so guardrail design is mostly tool design. Apply least privilege ruthlessly: an agent that summarises tickets needs read access to tickets, not write access to anything. From there, layer controls by consequence:

• Reversible, low-stakes actions (searches, reads, drafts) run autonomously.
• Consequential actions (sending external email, modifying records) pause for human approval via SDK hooks or your own gate.
• Irreversible or financial actions stay outside agent reach entirely, surfaced as recommendations for a human to execute.

Treat every tool result as untrusted input: a web page or document an agent reads can contain adversarial instructions, and prompt-injection resistance comes from constraining what tools can do, not from hoping the model ignores hostile text. Log every action with its justification — the transcript — so security review is a query, not an archaeology project.