Autonomous agents, defined by who picks the next step
Where the term came from, the two things it now means, a worked example with named tools, and four tests for whether the thing in front of you qualifies.
- Autonomous agent
- An autonomous agent is a software system that pursues a goal by choosing its own next action — usually a tool call — at each step, rather than following a path fixed in code.
Where the term came from
Russell and Norvig built Artificial Intelligence: A Modern Approach (first edition, 1995) around the agent: something that perceives an environment and acts on it. The multi-agent systems literature of the same decade used "autonomous" to mean operating without direct human intervention, with control over its own internal state. The word predates the current wave by thirty years.
The modern usage dates to March 2023, when AutoGPT appeared on GitHub and wrapped GPT-4 in a loop that generated its own next subtask. It mostly did not work. It did fix the vocabulary.
Then the tooling arrived. Anthropic published the Model Context Protocol on 25 November 2024, standardising how an agent reaches tools and data. In December 2024 Anthropic's engineering team drew the line the field now uses: workflows orchestrate LLMs and tools through predefined code paths; agents are systems where the LLM dynamically directs its own process and tool usage. OpenAI shipped the Responses API and the Agents SDK in March 2025, with a max_turns argument that raises MaxTurnsExceeded — a step cap enforced outside the model, in the runner.
The term means two different things
Most buying conversations go wrong right here.
| Label | Meaning | What qualifies |
|---|---|---|
| Operational autonomy (1990s sense) | Runs without a human intervening during operation | A cron job. A thermostat. A daemon. |
| Decision autonomy (2023– sense) | The model, not the surrounding code, selects the next action | An LLM loop with tools and an exit test |
| Marketing autonomy (not a sense) | Unattended — nobody clicks a button | Scheduled automation with a chat box on it |
Almost every vendor claim uses the first sense and prices it as the second. When someone says "our autonomous agent", the only question worth asking is: what part of the trajectory is decided at runtime? If the answer is "none, we just don't need a human to press go", you are buying a scheduler.
I took Metadata.io from $0 to $15M ARR selling automation to marketers, and I am publicly building a zero-human company on top of decision-autonomous systems. The distinction is not academic to me. It is the difference between software I can predict and software I have to instrument.
What it is not: a workflow
A workflow is the neighbour people confuse it with. The confusion is expensive, because the workflow is the better choice most of the time.
In a workflow, you wrote the path. Fetch the invoices, summarise them, post to Slack — three steps, every run, in that order. The model is a function call inside step two. Cost is predictable. Failures are localised. You can unit-test it.
In an agent, you wrote the tools and the stopping condition, and the model writes the path. Two runs on two inputs take different numbers of steps. That is the property you are paying for, and it is also the property that makes cost and behaviour harder to bound. A multi-agent system is this same loop with more than one decision-maker in it, which multiplies both.
A worked example
Take payout reconciliation — matching a Stripe payout against the invoices it settled.
Give the loop three tools and nothing else: stripe.list_balance_transactions(payout_id), db.find_invoice(amount, date_range, customer), and ledger.write(match). The goal is stated once: every transaction in the payout is either matched to an invoice or written to an exceptions file with a reason.
A workflow version would iterate the transactions and do one lookup each. Fixed. Predictable.
The agent version behaves differently on the messy ones. A transaction of $4,812.00 finds no invoice at that amount, so the model calls db.find_invoice again for two invoices summing to $4,812.00. Still nothing, so it widens the date range by 14 days. Still nothing, so it writes an exception with the reason and moves on. Nobody coded "try the sum, then widen the window, then give up." That branch is the autonomy, and it is also the part that can spiral: the same freedom that produced three sensible retries can produce three hundred.
So the runner carries a step cap — 12 tool calls per transaction, enforced in code, not in the prompt — and the loop appends one JSONL line per step: timestamp, tool, arguments, tokens, outcome. That log is the only thing that makes the run auditable afterwards. The three-tools-and-a-step-cap build is the smallest honest version of this shape.
Four tests for whether it qualifies
| Test | Question | If no, it is |
|---|---|---|
| Next-step choice | Does the model pick the next tool call, or does an if/else in your code? | A workflow |
| Variable trajectory | Do two runs on different inputs take a different number of steps? | A pipeline with a model in it |
| Owned termination | Does it decide the goal is met, inside a hard cap it cannot edit? | A chain |
| Real side effects | Does it write anywhere other than the chat transcript? | A chat feature |
Three of four is a workflow with good marketing. All four and you own something that needs a meter on it from day one, because spend now scales with steps rather than with requests.
Unbounded consumption is a named risk class in OWASP's Top 10 for LLM applications, not a rare surprise: a loop that cannot terminate burns tokens until something external stops it. The step cap belongs in the runner, outside the model. A model asked to police its own step count is still the thing being policed — and I would not hand any of these spend authority over a company card yet, cap or no cap.
Sources
- Artificial Intelligence: A Modern Approach (official site) — Russell & Norvig organised AI around the agent — perceives an environment, acts on it — from the 1995 first edition onward.
- AutoGPT (GitHub repository) — The March 2023 project that popularised wrapping an LLM in a self-directed loop; supports the dating of the modern usage.
- Anthropic — Building effective agents — December 2024 engineering post drawing the workflow-vs-agent line: predefined code paths versus an LLM dynamically directing its own process and tool use.
- Anthropic — Introducing the Model Context Protocol — MCP announcement, 25 November 2024; standardised how agents reach tools and data.
- Model Context Protocol documentation — Primary spec and docs for MCP servers and clients.
- OpenAI Agents SDK documentation — Ships the agent loop with a max_turns argument that raises MaxTurnsExceeded — a step cap enforced outside the model.
- OpenAI — New tools for building agents — March 2025 release of the Responses API and Agents SDK; dates the tooling layer.
- OWASP Top 10 for Large Language Model Applications — Unbounded Consumption is a listed risk class; supports the claim that runaway loops are a documented failure mode rather than an anecdote.