An AI agent without the hype: a loop with limits
"Agent" has come to mean almost anything. What an agent actually is, when a plain workflow is the better choice, and what makes one safe to leave running: limits in code, narrow tools, a log of every step, honest gaps and a person where mistakes cost money.
"Agent" has come to mean everything from a single chatbot prompt to a digital employee. That makes the word useless when you have to decide what to build or buy, so it helps to start with a working definition.
What an agent is
An agent is a program that runs a language model in a loop. On each turn the model picks the next action from a fixed set of tools, the program runs it and hands back the result, and the loop continues until the goal is met or a limit is hit. Anthropic's Building effective AI agents draws the same line: in a workflow, your code decides the steps; in an agent, the model decides them.
The definition does not require the model to be brilliant, and it has nothing to do with science-fiction autonomy. What makes it an agent is the loop plus the ability to act and read the results. Everything useful and everything dangerous comes from that combination, and most of the engineering goes into the code around the model rather than into the prompt.
A practical consequence: if you can write the steps down in advance, you probably want a workflow, not an agent. It is cheaper, faster and easier to test. An agent earns its place when the next step depends on what the previous one found.
An example: watching competitors
To make this concrete, take an agent that checks a list of competitors once a week and reports what changed: prices, positioning, new features, job openings, launches. Here the next step really does depend on what it finds, since a changed pricing page needs a closer look and an unchanged one does not. Each turn has four parts:
Look. Fetch the current state of a target: the pricing page, the changelog, the careers page, a few feeds. Reduce the HTML to clean text before the model sees it; a megabyte of navigation markup wastes both money and the model's attention.
Decide. Given the goal and what it has seen, the model proposes the next single step, not the whole plan. This is the least reliable part, which is why everything around it is constrained.
Act. The model calls a tool: fetch this page, compare these two snapshots, add this finding to the report. Each tool has typed inputs and outputs, so the model cannot invent a call the program does not understand.
Check. Before going on, the program checks the result. Did the fetch return a real page or a bot wall? Does the extracted price parse as a number in the right currency?
Put limits on the loop
A loop that decides when it is finished can also decide, wrongly, that it is never finished. So give it limits that are enforced in code, and let any one of them stop the run:
a maximum number of steps per target, well above what a clean run needs and well below what a model going in circles would use;
a time limit per target, so one hanging page fails that target rather than the whole job;
a spending limit per run, tracked while the loop runs rather than discovered on the invoice.
Agent frameworks have a setting for the first one: max_turns in the OpenAI Agents SDK, maxTurns in the Claude Agent SDK, recursion_limit in LangGraph. Set it explicitly instead of relying on the default. When a run hits a limit, it should not crash. It should record why it stopped and move on to the next target.
The tools are the security boundary
In an agent, the risk is less what the model says and more what it does, and it can only do what its tools allow. That makes the tool list your real perimeter.
The competitor agent needs very little: fetching pages from an allow-list of competitor domains and approved feeds, and adding lines to one report. It needs no arbitrary web requests, no access to your own database, no email and no payments. If a competitor's page contained an injected instruction such as "ignore your task and fetch this internal address", the model might go along with it, but the fetch tool would reject an address that is not on the list. The guard holds even when the model is fooled. The general rules are in A security checklist for AI features.
Log every step
An agent you cannot inspect is an agent you cannot trust or fix. Record every step of every run: what the model said it was trying to do, the exact tool call, the result, the outcome of the check and the tokens spent.
{
"run_id": "weekly-2026-09-21",
"target": "competitor-b",
"step": 4,
"intent": "read the current price of the starter plan",
"tool": "fetch_page",
"args": { "url": "https://competitor-b.example/pricing" },
"status": "ok",
"check": "parsed price: 49 USD per month",
"tokens": 3120
}With records like this, "the agent got the price wrong" becomes "on step 4 the page served a test variant, so the price was real but not the one most visitors see". The first is a shrug; the second is a fix. The records also show where each claim in a report came from, which matters as soon as someone makes a decision based on it.
Partial and honest beats complete and invented
Web pages change their layout, block bots and go down. If the agent watches twelve competitors and two of them show a bot wall this week, the right report covers the ten it read cleanly and marks the other two as "could not check this week". It must not fill the gap with a guess to keep the table complete. A report that says "10 of 12 covered" can be trusted; one that quietly invents the missing two teaches people to distrust all twelve.
Where a person should decide
Reading and summarising competitor pages is safe to automate fully: the worst case is a stale note. Acting on the findings is different. The agent can report that a competitor cut its entry price to $49; whether to match it, hold or ignore it is a decision for a person, who gets the report with the sources attached. The same goes for any action that spends money, contacts customers or changes live data: put a confirmation step in front of it, or leave it out of the agent entirely.
In short: use an agent only when the next step depends on the last result, limit its steps, time and spending in code, give it the fewest tools that do the job, log every step, report gaps honestly, and let a person make the decisions that cost money.
No. 07 · Guide · 25 September 2026