Contents5 sections
Five common agent scenarios
The previous agent-loop diagram contains a goal, observations, actions, tool results, and stopping conditions. Mapping those five positions to a real requirement shows whether an agent is justified.
A research agent searches, reads, compares sources, and gathers missing evidence. Search results determine the path, making an agent loop useful.
A support agent queries orders, knowledge, and policy, while high-risk refunds enter a fixed approval flow. Agents and workflows commonly coexist.
A coding agent reads a repository, edits files, runs tests, and iterates from errors. Rich tools and environment results continually change the next step.
A data-processing agent may interpret natural-language requests, but when cleaning, aggregation, and export are predetermined, a coded workflow is often more stable.
An approval assistant can organize material and explain risk, while the final approval remains with a person and business system rather than model discretion.
Ask five questions before choosing an agent
1. Does the task require external tools?
2. Do intermediate results change the next step?
3. Can code enumerate the complete path?
4. Can external rules accept the final result?
5. Can permissions and approval limit the loss from a wrong action?Tasks with no tool and one sufficient call use chat. Tasks with fixed paths and finite branches use workflows. An agent provides a clear gain when observations change actions, tools are constrained, and outcomes are externally verifiable.
Use three counterexamples to avoid overdesign
Translating one Chinese passage into English does not need an agent. A fixed SQL query, CSV export, and storage upload also need no model planning. Putting a model in every approval step reduces predictability, so approval nodes remain a coded state machine.
Agents handle open decisions without replacing all business code.
Define the research-brief agent's scope
The project used throughout later lessons is a technical research-brief agent. It accepts a topic and audience, starts with local retrieval, produces a structured brief with sources, connects to remote material only with explicit permission, and waits for approval before saving.
Version one excludes three capabilities: sending email, changing databases, and publishing automatically. A small boundary makes relationships among model, tools, and runtime visible to beginners.
Allowed
├── Search registered sources
├── Read an exact source_id
├── Generate a cited brief
└── Save to artifacts after approval
Forbidden
├── Arbitrary file access
├── Arbitrary network access
└── Automatic external send or publishFour project iterations
| Stage | Deliverable at completion |
|---|---|
| Understand agents | Concept map, technical background, requirement classification, project boundary |
| Write a simple agent | Stoppable loop, one tool, event log, offline tests |
| Make the agent useful | Tool registry, RAG, skills, state recovery, approval, security tests |
| Engineering extensions | Workflows, SDK, MCP, multi-agent, evals, production worker |
Chapter 3 creates brief-agent from an empty directory and connects one live model request. Chapter 5 later adds a fake model that needs no API key.
REFERENCES
References
Series
AI AGENT Beginner's Guide