What Actually Makes Software an "Agent"?
An agent is software that repeatedly senses state, chooses an action, and acts on the world (or a tool-backed API) until a goal is met or a bound is hit.
That loop - not a chatbot UI, not a brand name, and not a single LLM call - is what separates agents from scripts and plain completions.
Summary
- Software becomes an "agent" when an LLM sits inside a perceive-decide-act-observe loop that can select tools, use their results, and continue without a human directing every step.
- Insight: Teams waste months shipping "agents" that are fixed pipelines with marketing labels. A clear definition keeps architecture, eval, and risk aligned with actual autonomy.
- Key Concepts: agent loop, tool use / function calling, observation, autonomy spectrum, stopping conditions, goal vs workflow.
- When to Use: Tasks where the next step depends on intermediate results, external data, or trial-and-error that you cannot fully hardcode.
- Limitations/Trade-offs: Agents trade determinism, cost predictability, and simple debugging for flexibility. Many problems still want a script, chain, or human-driven copilot.
- Related Topics: chatbots vs agents, autonomy levels, agent vocabulary, reliability bounds.
Foundations
Classical AI treated an agent as anything that perceives an environment and acts to pursue a goal.
Modern LLM agents inherit that idea and swap the decision engine for a language model that can emit either natural language or structured tool calls.
Three properties matter more than branding:
- Sensing (perceive): the agent receives user goals, conversation history, tool results, memory, and system constraints as context.
- Choosing (decide): the model selects the next action: call a tool, ask a human, or return a final answer.
- Acting (act + observe): code executes the chosen tool, captures the result, and feeds it back so the next decision is grounded in reality rather than pure generation.
A one-shot prompt that returns text is a completion.
A fixed sequence of steps (always search, then summarize, then email) is a workflow or chain, even if an LLM fills some steps.
An agent decides which step to take next based on what just happened, usually inside a loop with an explicit stop condition.
Autonomy is a spectrum, not a boolean.
A system can be "agentic" for one sub-task (pick among three APIs) and fully scripted elsewhere.
What makes the label useful is that control over the next action has moved into the model's decision, with your runtime only constraining tools, budgets, and stopping rules.
Mechanics & Interactions
At runtime the loop looks like this:
- Build context: system policy, goal, history, available tool schemas.
- Call the model.
- If the model returns a final answer, exit.
- If the model returns one or more tool calls, validate arguments, execute tools, append observations, and go to step 2.
- If max turns, timeout, cost budget, or policy gate fires, exit with a controlled failure or handoff.
Tool schemas are not decoration.
They define the agent's action space: names, argument types, and descriptions the model uses to choose correctly.
Bad tool descriptions produce wrong tool selection the same way bad APIs produce wrong client code.
Observations close the loop.
Without feeding tool results back into context, you only have structured output, not agency.
That feedback is also where failures compound: a wrong search result can send the next turn down the wrong path, which is why logging the full trace matters more than logging the final answer alone.
Stopping is part of the definition of a safe agent.
The model does not inherently know when to stop exploring.
Your host process must enforce max iterations, token or dollar budgets, idle timeouts, and often goal-completion checks.
def agent_step(state, model, tools, max_turns=8):
for _ in range(max_turns):
decision = model.decide(state, tools)
if decision.done:
return decision.answer
state = state + [tools.run(decision.call)] # observe
return "stopped: max turns"This sketch is intentionally tiny.
Production systems add retries, parallel tools, human approval, and durable state, but they still rest on the same loop.
Agents interact with non-agent software through clear boundaries.
Databases, browsers, shells, and ticketing systems stay ordinary APIs.
The agent is the policy layer that decides when and how to call them under constraints you set.
Advanced Considerations & Applications
Not every loop should be fully free-form.
Many production systems use bounded agency: the model may choose among a short allowlist of tools, or only replan inside a single stage of a larger plan-and-execute pipeline.
That design still counts as agentic where it matters, while keeping blast radius small.
Multi-agent systems do not change the definition.
They compose several loops with handoffs, shared memory, or an orchestrator.
Each specialist is still an agent if it can decide and act within its scope.
Evaluation should match the definition.
If your software only runs a fixed path, unit tests on each step may suffice.
If it chooses tools dynamically, you need task success rates, trace reviews, cost-per-success, and failure-mode tests (wrong tool, empty observation, injection in tool output).
Security follows from the action space.
An agent with shell and payment tools is not "just a chatbot with plugins"; it is a policy engine with side effects.
Least privilege, argument validation, and human gates on irreversible actions are part of treating the system as an agent rather than as text generation.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Fixed script / pipeline | Deterministic, cheap to test | Brittle when the path must branch | Known sequences with rare surprises |
| Single-turn tool call | Simple, low latency | No multi-step recovery | One lookup or one action per request |
| Multi-turn agent loop | Adapts to intermediate results | Cost, latency, harder eval | Research, multi-hop tasks, recovery from errors |
| Human-in-the-loop copilot | High control, lower risk | Human becomes the bottleneck | High-stakes or ambiguous work |
| Multi-agent handoff | Specialization and parallel roles | Coordination overhead | Large workflows with clear role splits |
Common Misconceptions
- "If it uses an LLM, it is an agent." Completions, classifiers, and fixed RAG pipelines use LLMs without deciding next actions in a loop.
- "If it has tools, it is an agent." A product that always calls the same tool on every request is tool-using software, not necessarily agentic.
- "Agents are fully autonomous by definition." Useful agents are almost always bounded by tools, budgets, policies, and stopping conditions.
- "More autonomy is always better." Extra freedom often reduces reliability. Match autonomy to task risk and eval maturity.
- "The model is the agent." The agent is the system: model + tools + loop + memory + guardrails. The model is the decision component.
FAQs
What is the shortest accurate definition of an AI agent?
Software that uses a model to repeatedly decide among actions (often tools), apply them, observe results, and continue until a goal or bound is reached.
How is an agent different from a chatbot?
A chatbot optimizes for conversational replies. An agent optimizes for goal completion through actions. A chatbot may call a tool once under user direction; an agent may take many internal steps before answering.
Is ReAct required for something to be an agent?
No. ReAct is one popular loop style (reason, act, observe). Plan-and-execute, tool-calling loops without free-text reasoning, and multi-agent handoffs are also agentic when they preserve decide-act feedback.
Does every agent need memory?
No. Short tasks can run entirely from the current context window. Memory becomes important when work spans sessions, users, or long horizons that exceed a single context budget.
Can a deterministic program be an agent?
Classical agents can be fully rule-based. In today's product language, "AI agent" usually implies an LLM (or similar model) in the decision seat. Rules alone are automation, not an LLM agent.
Where does RAG fit in this definition?
Retrieval is often a tool inside the loop. Plain retrieve-then-generate with no branching is a pipeline. When the model decides whether to retrieve, reformulate, or answer, the system becomes agentic RAG.
What must I implement before calling a prototype an agent?
At minimum: tool schemas, a loop that feeds observations back, and a hard stop (max turns or budget). Without those three, you have a demo completion with side effects.
Why do vendors disagree on the word "agent"?
Marketing stretches the term to any AI feature. Engineering needs a narrower meaning tied to action selection and loops. Prefer describing autonomy level and tool rights over arguing labels.
Is function calling the same as being an agent?
Function calling is the structured interface for actions. Agency appears when the system can call tools across multiple turns based on prior results, not merely emit one structured payload.
How do I know if I should not build an agent?
If you can write a reliable flowchart of every step, a script or workflow engine will usually be cheaper, faster, and easier to test than a free-form agent.
What is an "environment" for a software agent?
Anything the tools can read or change: files, browsers, APIs, databases, tickets, calendars, or chat platforms. The environment is defined by tool permissions, not by a physical world.
Do multi-agent systems change the core definition?
They scale it. Each agent still perceives, decides, and acts. The new problems are handoff protocols, shared state, and who owns the final answer.
How does autonomy relate to risk?
Higher autonomy expands the set of actions the system can take without asking. Risk scales with irreversibility and blast radius of those actions, not with model size alone.
What should I measure to prove something is working as an agent?
Task success under varied paths, average tool calls per success, cost and latency distributions, rate of stop-condition hits, and human intervention rate - not only final answer quality.
Related
- AI Agents Fundamentals Basics - first hands-on loop with a tool
- Agents vs Chatbots vs Assistants vs Copilots - term boundaries
- Autonomy Levels - spectrum from tool call to unsupervised runs
- Core Vocabulary Every Agent Builder Should Know - shared language for loops and tools
- Inside the Agent Loop - one full loop iteration in depth
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.