Steply
 Book a briefing
← Back to blog
steply / blog · o-que-e-um-agente-de-ia-definicao-tecnica.md
$ steply blog open o-que-e-um-agente-de-ia-definicao-tecnica
▸ loading article…
✓ ready

What is an AI agent: an honest technical definition, no mysticism

bySteply8 min read

'Agent' has become the most distorted word in the AI market. Every startup calls its product an agent. Every framework promises agents. Every vendor swears its chatbot evolved into an agent. The result: a senior dev opens the code and finds a while wrapped around a chat.completions, with two if statements for retry. This post defines agent with technical rigor, separates it from what it is not, shows what it needs to have to earn the name, and ends by classifying the archetypes that show up in production. No mysticism. Engineering.

The definition I will defend here, based on the line of Anthropic (Building Effective Agents, 2024) and Russell & Norvig (AIMA 4th ed): an agent is a system where an LLM autonomously controls its own execution flow, deciding which tools to use, when to use them, and when to stop, based on observation of the environment. The flow control lives in the LLM, not in the programmer. That is the axis. Everything else derives from it.

1. The difference that defines it: control flow in the LLM vs in the code

In 2024 Anthropic proposed a clean distinction that became a reference: workflows vs agents.

Workflow: the LLM and the tools are orchestrated along paths that are predefined by the code. The programmer writes the sequence: 'call LLM A to classify, if it is type X call tool Y, send the result to LLM B to summarize'. The graph is fixed. The LLM fills slots, it does not decide topology.

Agent: the LLM drives its own loop. On each iteration it decides the next action (call a tool, reason more, finish). The programmer does not know in advance how many steps there will be, in what order, or which tools will be invoked. The topology emerges from the execution.

This distinction has a direct practical consequence. A workflow is predictable, debuggable, cheap. An agent is flexible, expensive, and demands serious observability. If your problem fits in a workflow, use a workflow. An agent is overkill in 70% of the cases where it is used today. That statement is deliberately unpopular. It is true.

2. Minimum anatomy: what has to exist

For a system to be an agent according to the definition, it has to have five functional components. If one is missing, it is not an agent, it is something else.

  • Model: an LLM capable of tool calling (function calling). Today that means Claude 3.5+, GPT-4+, Gemini 1.5+, Llama 3.1+, or equivalent. A model without structured tool calling does not become an agent without a fragile hack.
  • Tools: deterministic functions that the LLM can invoke, with a declared schema. A tool can be a SQL query, an HTTP request, a file read, sandboxed code execution, or another agent.
  • Loop: the structure that receives the LLM response, runs a tool if one is requested, returns the result, and iterates. It has to have a stopping criterion (final answer, exhausted budget, fatal error).
  • Working memory: a representation of the execution history that is accessible to the LLM. Minimum: a list of messages with tool calls and results. Advanced: optimized KV cache, compaction, partial summaries.
  • Runtime/harness: the layer that assembles the prompt on each iteration, parses the response, dispatches the tool, manages errors, controls timeout. This is where 80% of the real complexity lives.

Miss two and you have an advanced chatbot. Miss the loop with control in the LLM and you have a workflow. Miss tool calling and you have pretty RAG. The five together, and only the five together, make an agent.

3. The cycle: perception, decision, action, observation

The inner loop follows OODA (Observe, Orient, Decide, Act), adapted.

  1. Observation: the user's initial input, or the result of the last action. It becomes a message in working memory.
  2. Orientation: the harness assembles the full prompt (system + history + available tools) and sends it to the LLM.
  3. Decision: the LLM generates a response. It can be tool_use (one or several, in parallel) or final text (end_turn).
  4. Action: the harness runs the requested tool calls, captures the result (success, error, returned data).
  5. Back to (1): the result becomes a new observation. The loop continues until end_turn, budget, or fatal error.

The fancy name for this structure is ReAct (Reasoning + Acting), formalized by Yao et al. in 2022. Today every serious implementation derives from it. The innovation is not in the pattern, it is in how each piece is executed: how to manage context so it does not blow up on tokens, how to return a structured error, how to parallelize independent tool calls, how to decide the budget.

4. Tool calling: what makes it possible

Tool calling is the mechanism that unlocks the agent. Without it, the LLM only generates text. With it, the LLM generates a structured request for an action, which the runtime intercepts and executes.

The protocol varies by vendor but the form is the same. You declare the tools in the request:

{
 "tools": [{
 "name": "get_weather",
 "description": "Returns current weather for a city",
 "input_schema": {
 "type": "object",
 "properties": { "city": { "type": "string" } },
 "required": ["city"]
 }
 }]
}

The LLM, instead of generating text, decides to call the tool and emits:

{
 "stop_reason": "tool_use",
 "content": [{
 "type": "tool_use",
 "id": "toolu_01A09",
 "name": "get_weather",
 "input": { "city": "São Paulo" }
 }]
}

The harness runs get_weather('São Paulo'), captures the result, and returns it on the next iteration as a tool_result. The LLM continues its reasoning with the new data. That is the mechanism. Everything that is called an agent today revolves around this.

5. What is NOT an agent

To make the definition operational, here is a list of what is falsely sold as an agent:

  • Chatbot with a big prompt: the LLM responds with text and the programmer parses it. No structured tool calling, no loop. Not an agent.
  • RAG: a pipeline searches docs, injects them into the prompt, the LLM responds. Fixed flow. It is a workflow, not an agent. (RAG can be a tool inside an agent, and then it changes.)
  • Chain of prompts: A generates, B critiques, C rewrites. Even with several LLMs, if the topology is fixed, it is a workflow.
  • n8n/Zapier with an AI node: a deterministic flow with AI in one step. Workflow.
  • Function calling without a loop: you call the LLM once, it decides on a tool, you run it, you return the answer straight to the user. No iteration. Not an agent, it is a function-augmented LLM.

The single criterion is flow control. If the execution path is decided at runtime by the LLM, it is an agent. If it is decided at design-time by the dev, it is not.

6. The archetypes that show up in production

Four patterns cover 95% of real agents.

Reactive single-turn agent: a short loop, few iterations, no explicit planning. The LLM decides the next action based only on the current observation. Good for tasks where the path is discoverable incrementally (support, web navigation, debugging). Anthropic calls it 'augmented LLM' in the degenerate case of 1 turn.

Agent with a planner: the first call generates a plan (a list of steps). The loop executes each step. The LLM can replan if a step fails. Useful when the task has a predictable structure (multi-source research, code refactoring, filling out a multi-page form).

Orchestrator-workers (multi-agent): a main agent decomposes the task, delegates sub-tasks to specialized sub-agents, synthesizes the result. Sub-agents have their own context window, reducing pollution of the main context. A pattern used in Claude Code, Cursor agent mode, and OpenAI's deep research.

Evaluator-optimizer: two LLMs in a loop. One generates a solution, the other evaluates. It iterates until the evaluator approves or the budget runs out. Useful for code generation, translation, and technical writing, where quality is measurable and iteration pays off.

7. Properties that separate an agent from a toy

An agent that goes to production has to demonstrate four operational properties. Without them, it is a proof of concept.

  • Convergence: the loop terminates in finite time on most inputs. Metric: the percentage of executions that reach end_turn within the defined budget.
  • Idempotency where it matters: tools with side effects must be idempotent (a deduplication key) or require explicit confirmation. The agent will retry. That is guaranteed.
  • Observability: each turn records the prompt sent, the response received, the tools called, the latency, the cost in tokens. Without a trace, debugging in production is guesswork.
  • Predictable failure mode: what happens when a tool fails? When the LLM hallucinates a nonexistent tool name? When the context overflows? Each of these has to have a designed answer, not an accidental one.

8. Cost: the variable that sizes viability

A 1-call workflow costs 1x. A typical agent makes 5 to 20 calls to solve a task. The cost per execution scales linearly with the number of turns, and the context grows with each turn (each tool result accumulates). The total cost can be 50x to 200x an equivalent workflow.

That changes the decision rule. An agent makes sense when: (a) the quality gain is measurable and justifies the cost, (b) the problem is not solvable by a workflow at design time, (c) the execution frequency is low enough to absorb the cost, or (d) the cost of human error is high enough to pay for the extra iteration.

It does not make sense when: the task is high frequency and low value, it has an obvious deterministic path, or the token budget does not support multiple attempts. 'Everything an agent' is the 2026 version of 'everything a microservice'. It will go wrong for the same reason.

9. The timeline: why agents work now

The idea of an agent is old (the 1980s, in symbolic AI). LLMs as the basis of an agent are recent (2022). Structured tool calling became first-class in 2023 (OpenAI function calling) and matured in 2024 (Anthropic tool use, structured outputs). Three things converged for agents to become reality:

  • Models with long-horizon reasoning: Claude 3.5 Sonnet, GPT-4o, and Gemini 1.5 Pro maintain coherence across 20+ turns. Models from 2023 lost the thread in 5.
  • Large context windows: 128k to 2M tokens allow keeping the entire history without aggressive compaction. In 2022, 4k tokens forced a workflow.
  • Tool calling trained in pre-training: modern models were trained to use tools. It is not prompt engineering, it is a native capability.

10. The reframe for those who are building

A final operational definition, to use in an architecture discussion: an agent is a workflow where the execution graph is decided at runtime by the LLM itself, using structured tool calling, inside a loop with an explicit stopping criterion. If you cannot draw the agent within that sentence, either the system is not an agent, or the definition you are using is different from the one the industry is converging on.

The next post in this series will go behind the scenes: how exactly the agent harness works, how to manage context that grows with each turn, how to run tool calls in parallel without a race condition, how to handle a tool that fails in the middle of the loop, and how to instrument all of it for observability. The definition is the axis. The implementation is where everything goes wrong.