Part 1 — What is an agent, really?

Strip away the hype and an agent is a loop around a language model that can take actions in the world and decide what to do next based on what happened.

That’s it. A model receives some context, decides to call a tool — search a database, file a claim, send an email — sees the result, and loops again, continuing until the task is done or it hits a stopping condition. The “agentic” quality comes from the model controlling the loop: it chooses which action to take, in what order, and when to stop. Compare that to a traditional workflow, where a human engineer hard-codes those decisions in advance.

What “the model controls the loop” looks like in code. The whole definition collapses into about fifteen lines. There’s no framework here — just the model provider’s SDK — and that’s the point: the loop is the agent, not any library on top of it.

from anthropic import Anthropic

client = Anthropic()

def run_agent(user_input, tools, tool_functions):
    messages = [{"role": "user", "content": user_input}]

    while True:  # the loop that makes it an "agent"
        response = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        messages.append({"role": "assistant", "content": response.content})

        # The model decided it's done — natural stopping condition.
        if response.stop_reason != "tool_use":
            return response

        # The model chose a tool. We run it and feed the result back.
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = tool_functions[block.name](**block.input)  # engineer supplies the "how"
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": str(result),
                })
        messages.append({"role": "user", "content": tool_results})

Read the three decisions the model is making, not the engineer: which tool to call (block.name), with what arguments (block.input), and when to stop (stop_reason != “tool_use”). In a workflow, all three would be lines of your code instead. That single shift in who owns the control flow is the entire distinction.

Most SDKs now ship a helper that hides this boilerplate — the Anthropic SDK’s tool_runner iterates the same loop for you:

runner = client.beta.messages.tool_runner(
    model="claude-sonnet-4-5-20250929",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": user_input}],
)
for message in runner:  # same loop, managed for you
    ...

Convenient — but worth writing the loop by hand once. Every agent framework in this series is, underneath, a more elaborate version of those fifteen lines.

This framing comes from Anthropic’s “Building Effective Agents” guidance, which remains the canonical taxonomy in 2026. The practical lesson hidden in the distinction is the most important piece of advice in this whole series: most business problems do not need a fully autonomous agent.

A predefined workflow with one or two LLM calls is cheaper, faster, more predictable, and infinitely easier to audit. You should reach for genuine agency only when the task has so many branches that you genuinely cannot enumerate them ahead of time. Building a “fully autonomous multi-agent system” for a problem that a routing workflow would solve is the most common and expensive mistake teams make.

So the first design question is never “which agent framework?” It is: does this even need an agent, or is it a workflow?

The test I’d apply: can you draw the decision tree for the task on a whiteboard? If you can enumerate the branches — even twenty of them — it’s a workflow, and you’ll be happier with hard-coded paths. If the branches depend on information you won’t have until runtime, and you genuinely can’t draw them in advance, that’s when agency earns its cost.

Hold those six in your head. Everything that follows hangs off them.

Look back at the fifteen-line loop with those six in mind and you can already point to four of them: the model, the messages list is proto-context and proto-memory, the tools list, and the while loop is orchestration in its simplest form. The next four articles are the story of what each becomes under production pressure.