Skip to main content

Agents

Summary: An agent is an LLM that dynamically directs its own process and tool usage in a loop, rather than following a fixed sequence of developer-defined steps.

At a glance​

QuestionAnswer
What is it?An LLM that plans and acts on its own, checking real-world feedback as it goes
Why does it matter?It's the tier to reach for only when a task's steps genuinely can't be predicted in advance
When do I use it?Open-ended problems where the number of steps can't be hardcoded, in a trusted environment

How it works​

  • An agent begins with a command from, or interactive discussion with, a human user. Once the task is clear, it plans and operates independently, potentially returning to the human for further information or judgment.
  • During execution, it's crucial for the agent to get ground truth from the environment at each step — tool call results, code execution output — to assess its own progress. This is what separates a real agent loop from the model just generating plausible-sounding next steps.
  • It can pause for human feedback at checkpoints or when it hits a blocker.
  • The task usually terminates on completion, but it's common to also add a stopping condition (e.g. a maximum number of iterations) to keep it from running away.
  • Despite handling sophisticated tasks, the implementation is often simple: typically just an LLM using tools based on environmental feedback, in a loop. Most of the engineering effort goes into designing the toolset and its documentation clearly, not the loop itself.

Workflow vs. agent​

WorkflowAgent
Who decides the stepsThe developer, in advanceThe LLM, at runtime
PredictabilityHighLower — steps and tool calls aren't fixed
Best fitWell-defined tasksOpen-ended tasks where the path can't be hardcoded
Cost/latencyLower, more predictableHigher, and can compound on errors

Orchestrator-workers vs. agents​

Orchestrator-workers is the workflow pattern that sits closest to this line, and it's easy to mistake for an agent since both involve an LLM deciding what work needs to happen. The distinction is precise, not just a matter of degree:

Orchestrator-workersAgent
Code pathFixed: orchestrator call → worker calls → synthesis call, every runNot fixed — the LLM decides the next step each turn
What's dynamicThe plan's content (how many workers, what each does)The plan's shape itself (how many steps, in what order, whether to stop)
Ground-truth feedback loopTypically none — one decomposition, run once, synthesize onceCentral — reassesses progress against real environment feedback at each step
Stopping conditionImplicit — ends after synthesisMust be explicitly set (max iterations, completion check)
Still classified asWorkflowAgent

In short: orchestrator-workers changes what the fixed pipeline does each run; an agent changes whether there's a fixed pipeline at all.

When to use agents​

  • The task is open-ended and it's difficult or impossible to predict the required number of steps.
  • You can't hardcode a fixed path through the problem.
  • You're willing to trust the model's decision-making, since it will potentially operate for many turns.
  • The environment is trusted enough to tolerate the higher cost and the risk of compounding errors from a bad early decision.

Examples: a coding agent that resolves issues requiring edits across multiple files based on a task description; a computer-use agent that operates a computer (mouse, keyboard, screen) to accomplish a task.

Building agents well​

Three principles matter more than the framework you pick:

  • Simplicity — keep the agent's design as simple as the task allows.
  • Transparency — explicitly surface the agent's planning steps rather than hiding them, so failures are diagnosable.
  • Tool documentation — treat tool definitions with the same care as a human-computer interface; ambiguous parameter names or descriptions cause real mistakes, since the model has to infer usage the same way a person would.

Multi-agent systems​

Several agents with different roles coordinating (sometimes with one orchestrating the others) is generally treated as agents operating at scale, not a separate architectural tier — see AI Application Spectrum.

Remember​

  • The defining trait of an agent isn't sophistication — it's that the LLM decides the steps, not the developer.
  • Orchestrator-workers is a workflow wearing agent-like clothing: dynamic content, fixed shape. An agent has dynamic shape.
  • Ground truth from the environment at each step is what keeps an agent's plan grounded in what's actually happening, not just what sounds plausible.
  • Always set a stopping condition; don't rely on the model to know when to stop on its own.
  • Agents trade predictability and cost for flexibility — reach for a workflow first, and only move to an agent when the task's steps genuinely can't be predicted.

Sources​