AI Agents
An AI agent is an LLM that runs in a loop, deciding its own next step: it observes the situation, chooses a tool to call, acts, observes the result, and repeats until the task is done. Where a single API call answers one question, an agent pursues a goal — "turn this issue into a pull request," "research this topic and write a brief" — choosing actions dynamically rather than following a fixed script.
That autonomy is powerful and expensive. Agents shine on open-ended, multi-step tasks that are hard to specify upfront, but they cost more, run longer, and can go wrong in compounding ways. The discipline is knowing when an agent is actually warranted versus when a simpler workflow (code-orchestrated steps with LLM calls) would be more reliable.
TL;DR
- An agent runs an observe → decide → act loop, choosing tools to reach a goal.
- Built from tool use + memory + a loop around an LLM.
- Use agents for open-ended, multi-step tasks — not what a fixed workflow handles.
- Design for safety: guard destructive actions, bound the loop, keep humans in the loop.
Quick Example
The agentic loop, in essence — keep calling the model, executing the tools it requests, until it's done:
The Agentic Loop
An agent is, at its core, an LLM plus three things:
- Tools — actions it can take (search, run code, query a DB, call an API).
- A loop — repeatedly call the model, execute the tool it requests, feed the result back.
- Memory/context — the running conversation, plus optionally persistent memory across sessions.
The model decides each step from the goal and what it has observed so far, which is what makes the trajectory dynamic rather than hard-coded. See AI APIs & Tool Use for the underlying mechanics.
Workflows vs Agents
Not everything that uses an LLM should be an agent:
- Workflow — you orchestrate the steps in code, calling the LLM at fixed points (classify → route → summarize). Predictable, debuggable, cheaper. Prefer this when the steps are known.
- Agent — the model decides the steps. Use only when the task is genuinely open-ended and hard to specify in advance.
💡 Start with the simplest thing that works: a single call, then a workflow, and only reach for an agent when the task truly requires model-driven exploration.
When to Build an Agent
Check all four before committing:
- Complexity — is the task multi-step and hard to fully specify upfront?
- Value — does the outcome justify higher cost and latency?
- Viability — is the model actually capable at this task?
- Cost of error — can mistakes be caught and recovered (tests, review, rollback)?
If any answer is "no," a simpler tier (single call or workflow) is the better choice.
Best Practices
- Give a focused tool set — fewer, well-described tools beat a sprawling menu.
- Gate destructive/irreversible actions behind validation or human confirmation.
- Bound the loop — cap iterations/tokens so a confused agent can't run away.
- Manage context — long runs need summarization/compaction or memory, not unbounded history.
- Make it observable — log each step (tool calls, results) so you can debug and audit.
Common Mistakes
Building an agent when a workflow would do
Letting an agent take irreversible actions unchecked
FAQ
What's the difference between an AI agent and a chatbot?
A chatbot responds to messages turn by turn — text in, text out. An agent pursues a goal by acting: it runs a loop where it chooses and executes tools (search, code, APIs), observes results, and decides the next step autonomously until the task is complete. A chatbot can become agentic once you give it tools and a loop. The defining trait of an agent is model-driven, multi-step action toward an objective, not just conversation.
When should I use a workflow instead of an agent?
Use a workflow — code that orchestrates LLM calls at fixed steps — whenever the steps are known in advance. It's more predictable, cheaper, easier to debug, and less likely to go off the rails. Reserve agents for tasks that are genuinely open-ended and hard to specify, where the model must decide its own path. Most "AI features" are better served by a workflow or even a single well-designed call than by a full agent.
How do I keep an AI agent safe and under control?
Treat tool use as a security boundary: give a minimal, well-scoped tool set, validate tool inputs, and require human confirmation for irreversible or high-impact actions (deleting data, sending messages, spending money). Bound the loop (max iterations/tokens) so it can't run away, sandbox where the tools execute, and assume prompt injection is possible. Log every step for auditing. Recoverability (tests, review, rollback) is what makes autonomy acceptable.
Do I need a special framework to build an agent?
No — at its core an agent is a loop around a tool-use-capable LLM, which you can build directly with an SDK's tool runner or a manual loop (see AI APIs & Tool Use). Frameworks and managed agent platforms add conveniences (orchestration, memory, hosted tool execution, observability) that help at scale, but they're not required to start. Build the simple loop first; adopt heavier tooling when complexity justifies it.
Related Topics
- AI APIs & Tool Use — The tool-calling mechanics
- Large Language Models — The reasoning engine
- Retrieval-Augmented Generation (RAG) — A common agent capability
- Prompt Engineering — Steering agent behavior
- Event-Driven Architecture — Triggering agents