Building AI Agents That Actually Work

An AI agent is not a mysterious thing. Strip away the hype and it is a loop: the model looks at the situation, picks an action, a tool runs that action, the result comes back, and the model looks again. It keeps going until something tells it to stop. That is the whole idea. Model plus tools plus memory plus a stopping condition, run in a circle.

I build these for a living. The content engine I run is full of them, agents that read a store, decide what to write, check their own work, and publish. I have also watched plenty of them spiral into infinite loops, burn through a budget on a task a single call could have handled, and confidently call a tool that does not exist. This guide is the tactical version: what an agent really is, when you actually need one, and how to keep the loop from eating itself.

What an agent actually is

Four parts, no magic.

The model is the decision-maker. Each turn it looks at everything so far and decides the next action. The tools are what it can do: search a database, call an API, run code, write a file. Each tool has a name, a description, and a typed input schema, and the model emits a structured request to use one. Your code runs the actual function and hands the result back. The memory is what persists across turns, at minimum the running conversation, sometimes a scratchpad file or a store the agent reads and writes. And the stopping condition is the part everyone forgets: the rule that says the loop is done, whether that is the model declaring the task complete, a verification check passing, or a budget running out.

Take any of those away and it is not an agent. A model with no tools is a chatbot. Tools with no loop is a single function call. A loop with no stopping condition is a runaway process with your credit card attached.

When you actually need one

Most things that get called agents should not be. Reach for an agent only when the task is genuinely open-ended, when you cannot write the steps in advance because they depend on what the model discovers along the way. "Investigate this bug across the codebase and propose a fix" is a real agent task: you do not know which files matter until you start looking. "Summarize this document" is not. It is one call.

Before you build an agent, run four checks. Is the task actually multi-step and hard to fully specify up front? Is the outcome valuable enough to justify higher cost and latency? Is the model genuinely capable at this kind of work? And can you catch and recover from errors, with tests, review, or rollback? If any answer is no, drop down a tier. Use a single call, or a scripted pipeline where your code controls the sequence and the model fills in each step. A pipeline you control is more reliable and far cheaper than an agent deciding its own path, and most "agent" products are really pipelines wearing a costume.

The mental discipline here is the same one from the field guide on building with LLMs: use the simplest tier that does the job. Agents are the most powerful and the most expensive and the most fragile. Earn your way up to them.

Designing the tools

The agent is only as good as the tools you give it, and tool design is where most agents quietly fail. A few rules I follow.

Keep the tool set small per step. A model staring at thirty tools picks worse than one staring at five. If you have a large library, load only the relevant ones into context for the current task rather than dumping all of them every turn.

Write descriptions that say when to use the tool, not just what it does. "Searches the order database" is weak. "Call this when you need a customer's past orders to answer a question about their history" is strong, because it gives the model the trigger condition. The newer models reach for tools more conservatively, so a prescriptive description earns real lift in whether the right tool gets called at the right moment.

Make the input schemas tight and validate them. A loose schema invites the model to pass garbage; a strict one with required fields and enums constrains it to valid calls. And promote an action to its own dedicated tool when you need to gate it, log it, or render it specially. A generic "run this shell command" tool gives you no hooks; a specific "send_email" tool you can intercept, require confirmation for, and audit. For anything irreversible, like sending a message or deleting data, gate it behind a confirmation step rather than letting the loop fire it automatically. Good tool design is the same discipline as good prompt engineering for production: be precise, be explicit, and demonstrate the shape you want.

Keeping the loop from spiraling

This is the part that separates an agent that works from an agent that runs up a bill at three in the morning. Left alone, a loop wants to run forever. Your job is to bound it on every axis.

Budgets. Cap the number of steps and the number of tokens. A max-iterations counter is the single most important line of code in any agent: if the loop hits it, the agent stops, full stop, no matter what the model wants. Without it, one confused model can spin indefinitely.

Termination. Define explicitly what "done" means and check for it every turn. Sometimes that is the model emitting a final answer with no tool call. Sometimes it is a verification step you run in code. Never leave "when to stop" entirely to the model's judgment, because a stuck model will happily decide it is not done yet, again and again.

Verification. Before you trust the agent's "I finished," check. Run the tests. Validate the output against a schema. Have a separate, cheaper model judge whether the work meets the bar. The agent declaring success is not the same as the work being correct, and the gap between those two is where production agents embarrass you.

Here is the skeleton I keep coming back to, with the bounds baked in:

import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();

async function runAgent(task: string, tools: Anthropic.Tool[]) {
  const messages: Anthropic.MessageParam[] = [{ role: "user", content: task }];
  const MAX_STEPS = 15;

  for (let step = 0; step < MAX_STEPS; step++) {
    const res = await client.messages.create({
      model: "claude-opus-4-8",
      max_tokens: 4096,
      tools,
      messages,
    });
    messages.push({ role: "assistant", content: res.content });

    if (res.stop_reason !== "tool_use") break; // model is done

    const results = [];
    for (const block of res.content) {
      if (block.type === "tool_use") {
        const output = await runTool(block.name, block.input); // your code
        results.push({ type: "tool_result", tool_use_id: block.id, content: output });
      }
    }
    messages.push({ role: "user", content: results });
  }
  return messages;
}

That loop is the entire agent. The model decides, the tools run, the results feed back, and the MAX_STEPS counter guarantees it ends. Everything sophisticated you add, memory management, verification, parallel tool calls, is built on top of this bones.

Managing context and memory

As the loop runs, the conversation grows. Every model decision, every tool result, every step piles into the context, and two things go wrong. First, you pay for all of it on every turn, so a long-running agent gets more expensive per step the longer it runs. Second, past some point the model loses the thread, the original goal gets buried under tool output and the agent starts wandering.

Handle it deliberately. For long agents, trim or summarize the history as it grows: clear out old tool results that no longer matter, or compact earlier turns into a summary that preserves the goal without the bulk. Current models have huge context windows, but bigger is not free, and a focused context produces better decisions than a bloated one. For anything that has to persist across separate runs, not just within one loop, give the agent an actual memory: a file or store it reads at the start and writes to as it learns. A scratchpad the agent maintains itself is often enough, and the newer models are genuinely good at using one if you tell them where it is and to check it.

The principle: the context is a resource you manage, not a place you dump everything and hope. The best long-running agents I have built keep their working context lean and lean on external memory for the rest.

Observability and common failure modes

You cannot fix what you cannot see, and an agent is a black box unless you instrument it. Log every step: what the model decided, which tool it called with what inputs, what came back. When an agent misbehaves, that trace is the only thing that tells you whether the model reasoned badly, a tool returned junk, or the context drifted. Track token usage per run too, because cost is invisible until you measure it and an agent is the easiest way to get a surprising bill.

The failures cluster into a few shapes, and each has a fix. Hallucinated tool calls, where the model invents a tool or passes malformed arguments, almost always come from vague schemas or too many tools at once; tighten the definitions and cut the count per step. Infinite loops, where the agent repeats the same action expecting a different result, are what the step budget exists for, and a good trace shows you the repetition so you can fix the underlying confusion. Lost context, where the agent forgets the goal partway through, is the signal to add summarization or memory before the conversation outgrows what the model holds coherently. Silent wrong answers, where the agent confidently reports success on work it botched, are why verification is not optional; the model declaring victory means nothing until you check.

None of these are exotic. They are the standard failure set, and once you have seen each one a couple of times you start designing against them by reflex: budget the loop, verify the result, instrument everything, keep the tools tight and the context lean.

An agent that works is not a smarter model. It is a well-bounded loop around a capable model, with tools you designed carefully, a stopping condition you enforce, and a harness that catches the model when it is wrong. Build that, and the agent finishes the job. Skip it, and you have built a very expensive way to spin in circles.

FAQ

What actually makes something an agent versus a normal LLM call? An agent runs a loop: the model picks an action, a tool executes it, the result feeds back in, and it repeats until a stopping condition is met. A normal call is one shot in, one answer out. The loop and the model deciding its own next step are what make it an agent.

When should I build an agent instead of a single call or a pipeline? Build an agent only when the task is genuinely open-ended and you can't script the steps in advance. If you can write the sequence of calls yourself, do that instead. Agents cost more, run slower, and fail in more ways, so they have to earn it with real complexity.

How do I stop an agent from looping forever or running up a huge bill? Give it a hard budget on steps and tokens, a clear termination condition, and a verification step that checks whether it actually finished. Cap the loop with a max-iterations counter so a stuck agent stops instead of spinning. Never rely on the model to decide on its own when to quit.

Why does my agent hallucinate tool calls or lose track of the task? Hallucinated tool calls usually come from vague tool schemas or too many tools at once. Lost context comes from a conversation that grew past what the model can hold coherently. Tighten the tool definitions, reduce the tool count per step, and manage the context with summarization or trimming as the loop runs.