Understanding
AI Agents
Learn what makes an AI agent different from a chatbot, workflow, or simple tool call. Then play with a deterministic agent simulator and watch planning, tool calls, observations, approvals, memory, and final answers unfold step by step.
An agent is not just a bigger prompt
An agent is a system that can reason about a goal, choose actions, use tools, inspect results, and decide what to do next — repeatedly, until the task is done or the budget runs out. The key idea is the loop: goal → plan → act → observe → adjust → finish.
Unlike traditional software where you write the if/then logic, in an agentic system the LLM acts as the routing engine. It reads the tool result, weighs it against the goal, and decides the next move. This is powerful — and risky. The model can recover from surprises, but it can also go off-course if tools, constraints, or prompts are poorly designed. Think of an agent less like a program and more like a junior employee: capable, but needs guardrails, a clear brief, and approval on consequential decisions.
Chatbot
Usually answers in one turn from the prompt and model knowledge. It may be helpful, but it is not automatically doing work in external systems. It has no agency to affect the real world.
Best for: Q&A, summarization, drafting. Not for: multi-step tasks, real-world actions.
Answer focusedWorkflow
Follows a fixed path. Great for predictable automation. The logic decides the next step, not the model. If a step fails unexpectedly, the workflow usually breaks.
Best for: scheduled jobs, ETL pipelines, form processing. Not for: tasks with variable paths.
Fixed pathAgent
Chooses steps dynamically. It can call tools, read outputs, recover from partial failures, and stop when the goal is satisfied. It can adapt to edge cases.
Best for: open-ended research, debugging, triage. Requires: constraints, approvals, budgets.
Goal directedMulti-Agent Systems
For complex tasks, a single agent often becomes overwhelmed or confused — too many tools, too long a context, too many competing sub-goals. Multi-agent systems solve this by splitting work among specialized sub-agents, each with their own prompt, tools, memory scope, and constraints. Think of it like a small engineering team: one person plans, others execute, a reviewer checks the output.
The tricky part is communication: agents must hand off structured results, not freeform prose. You also need to decide who has final authority, how failures bubble up, and how to prevent agents from contradicting each other. These systems are powerful but harder to debug — start single-agent, and only go multi when you hit a real complexity ceiling.
Supervisor / Orchestrator
A main agent receives the user goal, breaks it into sub-tasks, and delegates each to a specialized worker agent. The supervisor collects results, resolves conflicts, and delivers the final answer. Example: a research supervisor delegates web search to a Search Agent, citation checking to a Fact Agent, and final synthesis to a Writer Agent.
Watch out for: supervisors that don't validate sub-agent output, leading to hallucinated citations or partial results being presented as complete.
Network / Peer-to-Peer
Agents communicate with each other directly to solve problems collaboratively. For example, a Coder Agent writes code, a Reviewer Agent critiques it, and a Tester Agent runs it — looping until all gates pass. There is no single boss; agents negotiate through shared state.
Watch out for: infinite critique loops, runaway token cost, and agents that agree with each other too easily (echo chamber failure).
The parts that make agents work
Before picking a framework, understand the primitives. Every agent — regardless of which library powers it — is assembled from these eight components. Miss one and you get surprising failures: runaway loops (no stop condition), data leaks (no guardrails), or useless plans (wrong tools). Master these and framework choice becomes secondary.
Goal
The user asks for an outcome, not just a text answer. A good goal is specific and bounded — "Find the failing test and draft a fix plan" is better than "help me with CI." Vague goals produce vague plans and wasted steps.
Planner
The model proposes a sequence of actions before executing. Making the plan explicit (not hidden in the prompt) lets your system inspect it, reject bad plans early, and show humans what the agent intends to do — before any tool is called.
Tools
Functions the agent can call: search docs, read calendar, query tickets, run tests, draft emails. Each tool needs a typed schema. The fewer tools you expose, the easier it is to reason about safety. Start with read-only tools and add writes one at a time.
Observation
The raw result returned by a tool. The agent uses observations to update its understanding of the world before deciding the next step. Observations should be structured (JSON or typed output), not freeform text, so the model can parse them reliably.
Memory
Information saved across steps or sessions. In-context memory is everything in the current prompt window. External memory (vector stores, databases) lets agents recall past sessions. Risky if it stores sensitive or irrelevant data — always scope what gets remembered.
Constraints
Hard limits built into your code, not your prompt: allowed tools list, maximum step count, time-out per tool call, spending cap, and approval gates. Constraints enforced in software are reliable. Constraints written only in the system prompt can be bypassed.
Guardrails
Security controls that intercept calls before execution: block disallowed tool names, validate argument schemas, strip prompt injection payloads from retrieved content, and rate-limit repeated identical calls. Guardrails are your last line of defense when the model reasons incorrectly.
Stop condition
The agent must have a clear way to finish — either a final_answer signal, a max-steps budget, or a goal-achieved check. Without one, agents loop, accumulate cost, and produce no result. Always define done before you define the plan.
Agent Flow Simulator
Pick a mission, set the autonomy level and safety policy, then run the agent. Everything is deterministic and client-side. No external APIs are called.
Agent Simulator
Local demo data • No model calls • Safe sandboxExecution trace
Agent plan
Final result
Learn by making decisions
These small games are intentionally simple. They teach the instincts behind good agent design: when to use an agent, how to pick a safe tool, and how to validate tool calls.
Game 1: Agent or workflow?
Game 2: Pick the safe tool call
Mission: help a user prepare for a meeting. The user mentions private notes and asks for a summary.
Game 3: Validate a tool call
The agent wants to call a tool. Decide if the call is valid for the schema.
Useful agent patterns
Most production systems are not fully autonomous agents. They combine deterministic software with small agentic loops where flexibility actually helps.
Router agent
Classifies the request and sends it to the right workflow or specialized agent. Good for support, internal tools, and multi-domain assistants.
Research agent
Searches, reads, compares sources, and produces a grounded summary. Needs citations and strict source handling.
Code investigation agent
Reads files, runs tests, inspects logs, and proposes fixes. Write actions should require approval.
Inbox triage agent
Groups emails, flags action items, drafts replies, and asks before sending. Great example of supervised autonomy.
Form filling agent
Extracts data and fills fields. Needs validation, confidence thresholds, and human review for sensitive fields.
Tool orchestrator
Chains multiple tools together. The hard part is not calling tools, it is deciding when to stop and how to handle failures.
The basic agent loop
This is the shape behind many agents. The model chooses an action, the app validates it, a tool runs, the observation returns, and the loop continues until done.
async function runAgent(goal, tools, policy) {
const state = { goal, observations: [], steps: 0 };
while (state.steps < policy.maxSteps) {
const decision = await model.decideNextAction(state, tools);
if (decision.type === "final_answer") {
return decision.answer;
}
const validation = policy.validate(decision.toolCall);
if (!validation.allowed) {
state.observations.push({
type: "blocked",
reason: validation.reason
});
continue;
}
const observation = await tools[decision.toolCall.name](decision.toolCall.args);
state.observations.push(observation);
state.steps++;
}
return "Stopped because the step budget was reached.";
}
Autonomy is not free
More autonomy can solve harder tasks, but it also increases cost, latency, uncertainty, and risk. Good systems choose the smallest amount of autonomy that gets the job done. Don't build an autonomous agent when a simple script will do.
Low autonomy
Best for high-risk work. The agent suggests actions but waits for the user. Slower, safer, easier to audit.
Safe defaultSupervised autonomy
Best for most internal assistants. Read actions can run automatically, write actions need approval. Perfect balance.
Practical defaultHigh autonomy
Best only in narrow, well-tested domains. Requires strict tool scopes, monitoring, rollback, and rate limits.
Use carefullyAgent risks and guardrails
Once an AI can use tools, prompt quality is not enough. You need software controls around what tools exist, what arguments are allowed, and which actions need approval.
Expose only the tools the agent truly needs.
Reading data and changing data should have different policies.
Require confirmation for sending, deleting, purchasing, deploying, or changing records.
Validate tool arguments with schemas before execution.
Use the user's real permissions. Do not give the agent admin power by default.
Log goal, plan, tool calls, observations, approvals, and final result.
Limit loops to avoid runaway actions and cost spikes.
Treat retrieved content as untrusted data, not instructions.
Before shipping an agent
Use this as a practical checklist before turning a demo into a real product feature.
Design
- Define the task boundary
- Decide what counts as done
- Choose the minimum autonomy
- Design failure states
Tools
- Define schemas
- Validate arguments
- Separate read and write tools
- Return clear observations
Safety
- Add approvals
- Rate limit actions
- Log every step
- Test prompt injection cases
AI agents questions
Short answers to the questions developers usually ask when they first build agents.
What makes something an agent?
Is every chatbot an agent?
Do agents need memory?
What is tool calling?
What is an observation?
Why do agents loop?
Why can agents be risky?
What is the safest default?
How do I test an agent?
What is the difference between RAG and agents?
Where does MCP fit?
Should agents be fully autonomous?
Agent terms in plain English
Agent
A system that can pursue a goal by planning, using tools, reading results, and deciding the next step.
Tool
A function the agent can call, such as search, read file, query database, draft email, or run tests.
Tool schema
The contract that defines tool name, required arguments, allowed values, and expected output.
Plan
The agent's proposed steps. Plans are useful because humans and software can inspect them before actions happen.
Observation
The output from a tool call. The agent uses observations to update its next decision.
Scratchpad
Internal working state used during a task. In real products, avoid exposing private reasoning directly.
Memory
Stored information used later. It can be session-only or long-term.
Guardrail
A software rule that blocks unsafe or invalid actions.
Approval gate
A step where the user must confirm before the agent performs a sensitive action.
Related concepts
These cards are written as internal guide placeholders. Replace links with your real guide paths when integrating into the site.