Building Your First AI Agent
with Claude: A Practical Guide

An engineer at a Series A startup told me last week that his team had been asked to "build an AI agent" for their sales workflow. He had read the Anthropic docs, understood tool use conceptually, and was staring at a blank Python file trying to figure out what to write next.

That is the state of most first agent builds in 2026. The concept is documented, the API works, the demos are impressive. The gap between "I understood the docs" and "I have something running in production without blowing the budget" is where most engineering teams spend their first month.

This article is a practitioner's guide for engineers building their first agent with Claude. What you actually need to install and configure. How Claude tool use actually works when you strip out the marketing. Three agent patterns that ship reliably in production in 2026. How to handle memory without blowing your token budget. Realistic cost per interaction and how to cut it. And why the evaluation harness is the part nobody ships but everyone should.

If you are the engineer or CTO staring at a blank file trying to decide what to write next, this is written for you.

What You Actually Need to Build an Agent with Claude

The minimum stack for a production agent, not a weekend demo.

An Anthropic API key with billing set up and rate limits confirmed. Sonnet-class models are the default choice for most agent workloads. Opus for complex reasoning; Haiku for cost-sensitive routine steps.

A tool schema in JSON. Each tool your agent can call has a name, a description, and an input schema. Descriptions are prompts. Write them clearly. A vague description gets you vague tool selection.

A client library. The Anthropic Python and TypeScript SDKs handle streaming, retries, and structured tool responses. Do not roll your own HTTP layer for a v1; use the SDK.

An execution environment for your tools. When the model asks to call a tool, your code runs it, catches errors, and returns a result. Tools that hit external APIs need retry logic, timeouts, and circuit breakers.

A logging and observability layer. Every prompt, every tool call, every response, every latency figure. Without it, you are debugging blind and finance cannot cost you.

An evaluation harness (from day one, not day thirty). More on this below. Non-negotiable if you plan to ship.

Everything beyond this list is optimisation. Anything less than this is a demo.

How Claude Tool Use Actually Works

The mechanics are simpler than the discourse suggests. See Anthropic's tool use documentation for the technical detail; here is the practical version.

You send Claude a message plus a list of available tools with their schemas. Claude reads the message, decides whether it needs a tool, and either replies directly or emits a structured tool-use request. Your application catches that request, runs the tool, and sends the result back to Claude in the next message. Claude reads the result and decides what to do next: reply, call another tool, or give up.

That loop is the agent. Not the model, the loop.

Two things worth naming.

Tool descriptions are the most important thing you write. A description like "gets the weather" is not enough. "Returns the current temperature, humidity, and precipitation for a specific city and date. Only use for cities you can name; do not guess or ask the user to confirm the city name" gives Claude the information it needs to select correctly.

Loops need termination logic. If your agent can call tools forever, it will. Set a hard maximum on tool calls per interaction (10 is a reasonable default). Log every loop that hits the cap so you can inspect what went wrong.

Three Agent Patterns That Ship in 2026

Not everything called "an agent" needs the full agent loop. Three patterns cover most production use cases.

Single-turn tool use. The user asks a question, Claude decides whether to call one or two tools, returns an answer. No multi-step planning. Best for question-answering with structured data lookups. Fastest, cheapest, most predictable.

Agent loop with tool calling. The user gives a goal, Claude plans a sequence of tool calls, executes them, and returns a completed outcome. Best for workflows with defined tools but variable execution order (support ticket resolution, research tasks, code refactoring).

Chained specialised agents. A main agent orchestrates several sub-agents, each with narrower tool access. Best for complex tasks where a single monolithic prompt would be too large or too generic. Anthropic's Building Effective Agents essay covers the trade-offs in detail.

Start with the simplest pattern that solves your problem. Most teams jump to chained agents first because it sounds impressive. It is almost never the right first choice. Ship single-turn or the standard agent loop, learn where it breaks, then move to chained agents only if the failure mode genuinely requires it.

Handling Agent Memory Without Blowing Your Budget

"Agent memory" is doing four different jobs at once in most engineering discussions.

Session context. Everything in the current conversation, sent with every request. Grows quadratically. Manage with prompt caching (Anthropic supports it well) and periodic summarisation.

Scratchpad. Short-term working memory the agent uses within a single interaction. Usually just tool call history plus intermediate observations. Lives inside the API request.

External memory (retrieval). A vector store (Pinecone, Weaviate, pgvector) or a database the agent queries as a tool. Persists across sessions. Best for user preferences, past interactions, and domain knowledge.

Long-term learning. The model itself does not learn between requests. Long-term learning means either fine-tuning on your data (rare for agents, expensive, hard to evaluate) or storing patterns in external memory the agent retrieves next time.

The mistake we see most often: teams put everything in session context. The bill triples in month two. Move persistent memory to a retrieval tool the agent calls only when needed.

Real Cost Per Interaction and How to Cut It

Real cost bands for a completed agent interaction in 2026.

Sonnet-class agent workflow. $0.05 to $0.30 per interaction depending on tool count, context size, and loop length. Ballpark for typical support-ticket or research-task workflows.

Opus-class agent workflow. $0.20 to $2.00 per interaction. Use only when Sonnet genuinely cannot solve the problem.

Haiku-class routine steps. $0.005 to $0.05 per interaction. Great for classification, extraction, and simple tool selection.

Three levers cut cost meaningfully.

Prompt caching. Anthropic supports caching of the system prompt and repeated context. Typical saving: 30 to 70 percent on runs that share context.

Model routing. Use Haiku for routine steps (intent classification, tool selection when the choice is obvious), Sonnet for the main reasoning, Opus only for edge cases. Blended cost drops significantly.

Termination logic. Cap tool calls per interaction at 10. Log every capped run. Fix the underlying cause. Runaway loops are the single largest source of unexpected bills.

Instrument cost per interaction from day one. If you cannot see per-user or per-workflow cost by month two, you will spend month three in an emergency meeting with finance.

Testing and Evaluation: The Part Nobody Ships

The reason most agent projects fail in production is not the model. It is the absence of an evaluation harness.

Three components you need.

A golden test set. 100 to 200 real cases from your domain with known correct outcomes. Cover the full range of your workflow: routine, edge, and adversarial. Build it before v1 ships.

A weekly re-run. Every week, re-run the golden set against your current agent configuration. Track accuracy per case category. When it drops, investigate.

Drift monitoring after every model upgrade. Anthropic ships model updates. Your agent's behaviour will shift, sometimes materially. The golden set catches this before your users do.

None of this is optional. Every agent programme we have seen fail at year one skipped one or more of these three.

What We Learned Adding AI to IELTSArena

IELTSArena is our AI IELTS preparation platform. The AI writing feedback feature uses a language model to evaluate student essays against IELTS band descriptors. Here is the honest bit: we did not build it as an agent.

Students want structured feedback (task response, coherence, vocabulary, grammar), not autonomous rewriting of their essays. A single-shot LLM call per essay is expensive but predictable. An agent loop that tried to "improve" feedback would have cost several times as much and would not have made the output better for the user.

What we did build, and what transfers directly to agent work, is a serious evaluation harness. A set of essays graded by trained IELTS examiners is our golden set. We re-run our AI feedback against this set weekly and after every model upgrade, tracking whether our band predictions correlate with the human grades. Twice in the last twelve months we caught meaningful drift between model versions that we would not have seen from user feedback alone.

The lesson for engineers building agents: the harness is what keeps you honest. Not the model. Not the tool schema. The harness.

You can see IELTSArena and our other work at our portfolio page. If you want to talk about how to design an agent programme with the harness built in, book an AI agent implementation call with WhiteStone.

Frequently Asked Questions

What do I need to build an AI agent with Claude?

Anthropic API key, a tool schema in JSON, a client library (Python or TypeScript SDK), an execution environment for your tools, a logging layer, and an evaluation harness. Anything less is a demo, not a production system.

How does Claude tool use actually work?

You send Claude a message with a list of available tools. Claude decides whether to call a tool, emits a structured request, your code runs the tool and sends the result back, and Claude decides what to do next. The loop continues until Claude replies directly or hits your termination cap. Tool descriptions are prompts; write them precisely.

How do you handle agent memory?

Four types of memory do different jobs. Session context lives in the request and grows quadratically (manage with caching). Scratchpad is short-term working memory. External memory is a vector store or database the agent queries as a tool. Long-term learning means external memory, not fine-tuning, for most teams. Do not put everything in session context.

How much does running an agent cost per user?

Sonnet-class agent workflow: $0.05 to $0.30 per completed interaction. Opus-class: $0.20 to $2.00. Haiku for routine steps: $0.005 to $0.05. Prompt caching cuts 30 to 70 percent. Model routing (small model for routine steps, larger for hard ones) is the second biggest lever. Instrument cost per interaction from day one.

How do you test an agent?

Build a golden test set of 100 to 200 real cases with known correct outcomes before v1 ships. Re-run the set weekly and after every Claude model upgrade. Track accuracy per case category. Investigate any drop. Every agent programme that failed at year one skipped this.

The One Thing to Remember

Building an agent with Claude is not the hard bit. The API works, the docs are good, and the loop is straightforward once you strip out the discourse. The hard bit is the evaluation harness, the cost controls, and the humility to start with the simplest pattern that solves your problem. Ship single-turn tool use first. Move to the full agent loop when you need it. Only reach for chained agents when the loop genuinely cannot handle the task.

If you want a conversation about your specific agent build, browse our AI development services or come straight to the implementation call.