Building AI Agents With Claude: SDK, Tools, and Patterns

A small team with one well-built Claude agent can run the kind of automation an entire operations crew used to handle. The agent reads a folder, calls the right SaaS connector, writes a clean draft, posts it where the team works, and waits for the next trigger. No screen to babysit, no spreadsheet to copy data into, no engineer pulled off product work for two weeks to wire it up. The Claude Agent SDK is the surface that makes this kind of build practical for SMBs, and the patterns that work in 2026 are stable enough to commit to.

This post covers what the SDK gives you, the tool-use and sub-agent patterns that survive contact with real production work, and how to decide whether your team should build directly on the SDK or run on a higher-level surface that already has the patterns baked in.

What the Claude Agent SDK Actually Is

The Agent SDK is Anthropic's library for building Claude agents that go beyond a single chat turn. Under the hood it handles the loop that most homegrown agent frameworks reinvent badly: the model decides which tool to call, the SDK runs the tool, the result gets fed back into the conversation, and the cycle continues until the model returns a final answer.

The pieces a builder actually touches:

• A typed tool interface. You describe each tool the agent can call (its name, its parameters, what it returns) and the SDK handles the protocol Claude uses to invoke it.
• A built-in tool catalog. File reads, file writes, shell access, web fetch, and web search ship with the SDK so common building blocks do not have to be reimplemented.
• MCP integration. Any Model Context Protocol server (Slack, Gmail, Calendar, Drive, Atlassian, Box, and a long list of others) plugs in as a tool source without custom code.
• Sub-agent support. A parent agent can spawn child agents with their own tool sets and task scopes, and synthesize their results.
• Session state. Conversation history, tool outputs, and intermediate artifacts persist across turns so a long-running agent can pick up where it left off.

The SDK is available in Python and TypeScript. Same model behind it, same tool protocol, two language surfaces.

The Tool-Use Patterns That Work

How ScaleIT handles this: See AI Quick-Start

Three patterns cover almost every production agent worth shipping. Each one is a different shape of the same loop, suited to a different shape of work.

1. The Single-Purpose Worker

One agent, a small handful of tools, a tight scope. A daily report generator. A new-customer onboarding agent. A Slack triage bot. It runs, it produces an artifact or takes an action, it stops.

What makes this pattern hold up in production:

• A clear system prompt that names the job, the inputs, and the deliverable.
• A small tool set, not a sprawling one. Every additional tool widens the search space the model has to navigate on each turn.
• Strict schema on every tool input so the agent fails fast on bad arguments instead of silently producing wrong work.
• An explicit "when you are done, return X" instruction so the loop terminates cleanly.

Most SMB automation should start here. The single-purpose worker is the pattern you can put in front of a non-technical team and trust on day one.

2. The Parent-Child Sub-Agent

A coordinating agent spawns specialist sub-agents for parts of the work, collects their outputs, and produces a final result. The sub-agents do not see the parent's full context (which keeps each one fast and focused), and the parent does not see the sub-agents' tool calls (which keeps the final output clean).

Good fits for sub-agents:

• A research task where each sub-agent owns one source (one for the company website, one for a competitor scan, one for the customer interviews) and the parent synthesizes.
• A document-generation pipeline where one sub-agent drafts, another reviews against a style guide, and a third formats.
• A long task where one sub-agent fetches and structures data, then exits, freeing context for the agent that does the analysis.

Sub-agents earn their cost when the work has natural parallelism or when keeping each child's context tight materially improves quality. They are overkill for a short linear workflow.

3. The Always-On Listener

An agent runs as a background service, watches a queue or webhook, and acts when an event lands. New email in a shared inbox triggers a triage. A completed form in JSM kicks off an onboarding flow. A Slack mention pulls the agent into the thread.

The patterns that keep listeners healthy:

• A clean idempotency layer so a replayed event does not run the agent twice.
• A capped tool-call budget per event so a runaway loop cannot drain the day's quota.
• A logging path that captures the full agent trace per event for after-the-fact review.
• A heartbeat so silence is detected fast, because a listener that stops listening looks the same as a listener with no events.

This is the pattern that production automation tools (OpenClaw and similar) wrap for you. Building it from scratch is doable, and it is also the place most SMB teams should not spend their engineering time.

Configure for Scale Early (And It Is Not Too Late If You Did Not)

The cheapest time to set up agents the right way is the first one your team builds. That means: pick a single-purpose worker pattern for the first agent, give it a tight tool set, write a focused prompt, and put it behind a connector your team already uses. Get one working artifact in production before adding a sub-agent layer or a listener.

If your team started by giving one agent every tool you could think of, three jobs, and a shared system prompt that has been edited by four people, that is the normal path, and the cleanup is small. The fix is splitting one fuzzy agent into two or three sharp ones, which usually takes a focused day. Most ScaleIt engagements that touch agent builds start with this kind of consolidation rather than a from-scratch design.

Build on the SDK, or on a Higher Surface?

The SDK is the right surface when your team has the engineering capacity to own the agent in production. That means a developer who can read the trace logs when something goes sideways, a deployment target the agent can run on, and a willingness to maintain the prompt and tool set as the use case evolves.

A higher-level surface is the right call when the work is operational rather than engineering. Cowork already wraps the single-purpose worker pattern for desktop use. OpenClaw already wraps the always-on listener pattern with cron and webhook triggers. Both run on the same SDK underneath, with the patterns and the operational layer (auth, retries, logging, scheduling) handled for you.

A useful test: if the answer to "who maintains this agent" is a software engineer, build on the SDK. If the answer is a head of operations or a founder, run on a higher surface that lets them own the prompt and the tool selection without owning the deployment.

What To Watch in a Healthy Agent Build

A handful of operational habits keep an agent fleet quiet and useful instead of noisy and surprising:

• Cap the tool-call count per run. A bounded loop is the cheapest defense against a model that decides to keep trying.
• Log every tool call with arguments and a trimmed result. The first time an agent produces a wrong answer, the log is what tells you whether the prompt, the tool, or the input was at fault.
• Version the prompt in the same place you version code. Prompt regressions are real and they hide for weeks if no one is tracking them.
• Run a smoke test on every deploy. One canonical input, one expected output shape, run on every prompt or tool change.
• Pair every scheduled agent with a heartbeat in a low-volume channel. Silence is the failure mode you want to catch fast.

These are the same habits that keep any production system healthy. Agents do not get a pass.

Capabilities of an Excellent Agent Build

When the patterns above are in place and the right surface is doing the work, the day-to-day for a small team looks like this:

• Each agent has one job, one prompt, and a small clean tool set.
• Sub-agents appear only where parallelism or context isolation actually pays off.
• Listeners run on a real platform with retries, idempotency, and heartbeats handled for you.
• The Claude bill is predictable because the agent count and tool-call budget are bounded.
• The team adding new agents is the operations team, not the engineering team, for everything that does not need a custom integration.
• Engineering owns the SDK-level builds that genuinely require code, and stays out of the rest.

That is what a well-run agent layer looks like for an SMB.

Next Step

Are you looking to put Claude agents to work across your business without spending months learning the SDK? We can help. Contact ScaleIt for a free consultation.