What Is an Agent, Really?

Not your grandmother's chatbot

A chatbot takes input and returns output. One turn. Stateless. You ask, it answers, done.

An agent does something different: it perceives its environment, decides what to do, acts via tools, observes the result, and loops until the task is complete. It has goals. It has the ability to change the world, not just describe it.

That's the fundamental distinction: a chatbot describes; an agent acts.

The four components of an agent

Every real agent system has these four things, whether you've named them or not:

1. A brain (the model) This is your LLM: Claude, GPT-4o, Gemini. It does the reasoning, decides what tool to call next, interprets results, and knows when to stop. The model is not "the agent" — it's the brain inside the agent.

2. Tools (the hands) Tools are the functions the model can call to interact with the world. Read a file. Write a file. Search the web. Call an API. Query a database. Send an email. Without tools, you have a very smart conversationalist. With tools, you have an agent.

3. Memory (the context) Agents need to remember what they've done. Short-term memory is the conversation history in the context window. Long-term memory is an external store — a database, a vector store, a key-value file — that persists across sessions. Most beginner agents only have short-term memory. That's fine to start.

4. A loop (the runtime) The agent loop is what makes an agent an agent: Observe → Think → Act → Observe → Think → Act… until the task is complete or a termination condition is hit. Claude Code runs this loop for you. If you're building your own, this is the scaffolding you write.

A concrete example

You ask: "Find all TypeScript files in this project that import from 'lodash', and tell me which functions they actually use."

A chatbot would explain how you could do that. An agent would:

1. Call list_files to find .ts files
2. Call read_file on each one
3. Parse the imports in memory
4. Return a structured answer with file names and function usage

The model orchestrates the calls. The tools do the actual work. The loop keeps going until all files are processed.

Why this matters for what you build

If your product is "a Claude wrapper with a nice UI," you've built a chatbot. That's fine — but it's not an agent, and it won't gain the reliability, autonomy, or capability jump that agents provide.

If your product can:

• Run tasks without per-step human approval
• Interact with external systems
• Recover from errors and try alternative approaches
• Handle tasks that take more than one turn to complete

...then you're building an agent. The architecture decisions are different. The testing approach is different. The user expectations are different.

The spectrum: chat → copilot → agent → autonomous

Not everything needs to be fully autonomous. There's a useful spectrum:

• Chat: Pure conversation, no tools
• Copilot: Suggestions, completions, code generation — human decides on every action
• Agent: Model calls tools, handles multi-step tasks, human approves key decisions
• Autonomous: Model runs a full workflow with minimal or no human-in-the-loop

Most production systems in 2026 sit in the "agent" zone with selective human checkpoints. Full autonomy is reserved for well-defined, low-stakes tasks where the blast radius of an error is small.

Your first step

Before you build anything: write down what your agent will do (not what it will say). List the tools it needs. Define what "done" looks like. That spec is your architecture. Everything else is implementation.

Next up: Guide 02 — Prompting Basics for Agentic Systems. We'll cover how to write system prompts that actually control agent behavior rather than just vibe-setting.