What are AI Agents?
A friendly introduction to AI agents for builders of all levels.
An AI agent is a language model running in a loop with tools: it reads a goal, takes an action (run a command, edit a file, search the web), observes the result, and repeats until the goal is done. That loop — not the model alone — is what makes it an agent.
The agent loop
Goal → Think → Act (use a tool) → Observe result → Think → Act → … → DoneA chatbot answers once. An agent keeps going: it runs your tests, reads the failure, fixes the code, and runs them again. Everything else in agent-land is about making this loop reliable.
The five building blocks
| Block | What it is | You control it via |
|---|---|---|
| Model | The reasoning engine (Claude, GPT, Gemini, Grok…) | Picking a model / runner |
| Context | What it knows right now: instructions + files + history | AGENTS.md, what you put in prompts |
| Tools | What it can do: shell, file edits, browser, APIs | MCP servers, runner built-ins |
| Memory | What persists between sessions | Memory MCP, notes files, project docs |
| Orchestration | One agent vs. several with roles | Multi-agent patterns |
The one constraint that explains everything: context
Models have a context window — a finite working memory (hundreds of thousands of tokens, but finite). Everything the agent knows during a task must fit: its instructions, the files it has read, tool outputs, and the conversation so far.
This is why:
AGENTS.mdmatters — it's the dense, always-loaded summary of your project- Agents read files selectively instead of ingesting the whole repo
- Long sessions degrade — old details get compacted or dropped
- Plans and scratch files work — externalized state survives when context doesn't
When an agent "gets dumber" mid-task, it's almost always a context problem, not a model problem. See the context engineering example for practical fixes.
Skills: process you don't re-explain
A skill is a reusable instruction package — a proven prompt with a defined process and output format. Instead of re-explaining how you want code reviews done in every session, you load the advanced-code-reviewer skill once.
Good skills give the agent a clear contract (inputs, steps, output format) and encode hard-won judgment. That's the difference between "review this" and a review that consistently checks security, performance, and tests. Browse the Skills directory or learn to write your own.
Quick glossary
| Term | Meaning |
|---|---|
| Agent runner | The harness that runs the loop: Claude Code, Codex CLI, Gemini CLI, Cursor… |
| MCP | Model Context Protocol — the open standard for plugging tools into agents |
| Tool call | A single action: run a command, read a file, hit an API |
| System prompt | The standing instructions the model always sees |
| Context window | The model's finite working memory for one session |
| AGENTS.md | A markdown file of project facts and rules that agents load automatically |
| Skill | A reusable, structured instruction package for one capability |
| Subagent | A child agent spawned for a subtask, with its own fresh context |
Single agent vs. multi-agent
Start with one agent. It's easier to debug, cheaper, and sufficient for most work. Move to multiple agents when tasks have genuinely separable roles (research vs. implement vs. review) or you need parallel exploration — see Multi-Agent Patterns for when and how.
Ready to build? Head to Getting Started.