Updated June 2026

“Agent” gets used for everything from a chatbot with a search button to science fiction. The working definition is much smaller, and once you have it, the rest of the agent notes on this site snap into place.

An agent is a model in a loop

That’s the whole thing. Give a model a goal and a set of tools. It responds with either a tool call or a final answer. Your code executes the tool call, appends the result to the conversation, and asks the model again. Repeat until the model says it’s done, hits a limit, or you stop it.

loop:
    response = model(conversation, tools)
    if response is a tool call:
        result = execute(it)
        conversation += [response, result]
    else:
        done

Everything that makes agents impressive (and everything that makes them fail) lives in this loop. The model supplies judgment about what to do next; the tools supply the ability to actually do it; the accumulating conversation supplies memory of what’s happened so far. There is no other magic ingredient.

Where the engineering actually goes

  • The tools. Their design shapes agent behavior more than the prompt does: what’s available, how descriptions trigger use, what gets gated behind confirmation. Covered in Designing an Agent’s Tools.
  • The stopping conditions. Loops need exits: the model declaring completion, a turn limit, a budget, a human interrupt. An agent without firm limits is an infinite loop with a credit card.
  • The context. Every iteration appends to the transcript, and every iteration re-reads all of it. Long runs accumulate sediment that degrades judgment and costs money; serious agents need pruning, summarizing, or delegation to sub-agents.
  • The error compounding. A step that’s right 95% of the time is sobering across twenty dependent steps. This is why verification (tests, checks, fresh-eyes review) matters more for agents than for single calls: errors don’t just occur, they propagate.

Do you actually need one?

The question that should precede every agent project: can you write the steps down? If the workflow is “extract the fields, look up the account, draft the reply,” that’s code with LLM calls in it: a pipeline, not an agent. Pipelines are cheaper, faster, testable, and fail in ways you can reproduce. Use them whenever the path is knowable in advance.

An agent earns its complexity when the path genuinely can’t be scripted: debugging (the next step depends on what the last command revealed), open-ended research, “make this test pass.” The model isn’t following your flowchart because no flowchart exists.

The honest checklist before building one: the task is multi-step and unpredictable, the outcome justifies the cost, the model is actually competent at this category of work, and errors are catchable before they’re expensive. A “no” on any of those means a simpler tier (one call, or a pipeline) will serve you better, and your future on-call self will thank you.