A Practical Guide to Building Agents (Start With the Loop)

Most guides to building agents start with a framework. Start with the loop instead — it's about eighty lines, it's what every framework wraps, and understanding it is the difference between debugging your agent and debugging someone's abstraction over your agent.

The whole thing:

1. Send the model the goal, the history so far, and a list of tools it may call
2. It returns either a final answer or a tool call
3. If it's a tool call, execute it, append the result to history, go to 1
4. Stop on an answer, a step limit, or a spend limit

That's an agent. Everything else — planning, memory, multi-agent coordination, durable execution — is an addition to that loop, and most agents need none of them.

Build the loop first

def run_agent(goal, tools, max_steps=10):
    history = [{"role": "user", "content": goal}]

    for step in range(max_steps):
        response = call_model(history, tools=tool_schemas(tools))

        if not response.tool_calls:
            return response.text

        history.append(response.message)
        for call in response.tool_calls:
            try:
                result = tools[call.name](**call.arguments)
            except Exception as exc:
                result = f"Error: {exc}"          # the model can recover from this
            history.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result),
            })

    return "Stopped: step limit reached"

Three details in there matter more than they look:

Errors go back to the model as text. Don't crash on a failed tool call — hand the error back and let the agent try something else. This one choice is most of what makes an agent feel capable rather than brittle.

The step limit is not optional. Agents loop. Without a ceiling, a confused agent runs until your budget notices.

History grows every step. A ten-step run sends the whole conversation ten times, so cost scales roughly with the square of the step count. This surprises people on their first real bill.

Tools are the actual product

The model is a commodity; your tools are what the agent can do. Four rules, in order of how much they affect reliability:

1. Descriptions are prompts. The model picks tools based on the description alone. search(query) — "searches the knowledge base" is worse than "searches internal support documentation. Use for product questions. Returns up to five excerpts with source URLs." Write them for a competent new hire.

2. Return structured, compact results. Dumping a 40KB JSON blob into history burns context and buries the answer. Return the fields that matter.

3. Make failures descriptive. "Error: no customer with id 4821. Use search_customers to find the right id." teaches the agent its next move. "Error: 404" teaches it nothing.

4. Fewer tools than you think. Past roughly ten, selection accuracy drops noticeably. If you need more, group them behind a router rather than listing them all.

Where possible, expose tools over the Model Context Protocol — it standardizes how applications connect to tools and data, so an integration you build survives a change of framework.

The four things that decide reliability

Not the model. These:

Scope. A narrow agent beats a general one every time. "Answer questions about our docs" works; "be helpful" doesn't. Cut the scope until the task has a checkable definition of done.

Chain length. Ten steps at 95% each is roughly a coin flip end to end. Three steps then a human check beats fifteen autonomous ones. When a task needs many steps, split it into several short agents with checkpoints rather than one long run.

Feedback. Can the agent tell whether it succeeded? If yes — tests pass, schema validates, the record exists — it can iterate toward correct. If no, it produces plausible output and you can't tell. Build the check if one doesn't exist; it's usually the highest-leverage work in the whole project.

Authority. What can it do unsupervised? Keep the agent read-only by default and make irreversible actions a human confirmation. This is the difference between a bad afternoon and an incident.

Evaluate before you optimize

The mistake almost everyone makes is tuning prompts against vibes. Build twenty test cases first — real inputs, expected outcomes, including the messy ones — and run them on every change.

Without this you cannot tell whether a prompt edit helped, and you will spend days moving sideways. Twenty cases in a file with a pass rate is enough; it doesn't need a platform.

Log every run's full history too. When an agent does something strange, the transcript is the only artifact that explains why, and you cannot reconstruct it afterwards.

When to add a framework

Add one when you feel a specific absence, not before:

If none apply, the framework is a layer between you and your bug. Vendor SDKs — the Claude Agent SDK and its equivalents — sit usefully in the middle, giving you the loop and tool handling without much ceremony.

For the wider landscape, agentic AI architecture covers the components and best AI agents covers what's already built.

A realistic first project

Pick something with all four properties: frequent, narrow, checkable, and reversible. Extracting fields from documents into a spreadsheet fits perfectly — you run it often, the scope is tiny, correctness is obvious, and a mistake costs nothing.

Build the loop, give it two tools, write twenty test cases, run it on real data with the final write disabled, then enable it. That project teaches more than any amount of framework comparison.

If the blocker is that you keep finding agent setups you can't get running rather than wanting to build one, that's a different problem. Taku mirrors a working AI setup into your own desktop workspace and runs it there, without reproducing someone's environment first. The free app library shows what's available to mirror. Taku is in Beta, and the Mac app is available now.

FAQ

How do I build an AI agent?

Start with the loop: send the goal plus tools, execute any tool calls, append results, repeat until an answer or a limit. That's about eighty lines against either major API and it's what frameworks wrap.

Do I need a framework to build an agent?

No. Add one when you need multi-agent shared state, durable execution across days, or provider portability. Before that it mostly stands between you and your bugs.

What makes an agent reliable?

Narrow scope, short chains, a real feedback signal, and bounded authority. None of them are model choices, which is why swapping models rarely fixes a flaky agent.

How many tools should an agent have?

Fewer than ten in one list. Selection accuracy degrades as the list grows; group larger sets behind a router.

What should I build first?

Something frequent, narrow, checkable, and reversible — document field extraction is close to ideal. Run it with the final write disabled until the test cases pass.

Key points

• The loop is eighty lines; understand it before adopting a framework.
• Return tool errors to the model as text so it can recover.
• Tool descriptions are prompts, and compact structured results beat raw dumps.
• Scope, chain length, feedback, and authority decide reliability — not the model.
• Write twenty test cases before tuning anything, and log every run's full history.