An agent is a model in a loop with tools. It plans, calls a tool, observes the result and decides what to do next — repeating until the task is finished. The model supplies judgement; the tools supply facts, actions and side effects.
The loop
- Tool definitions. Each tool is described by a name, a purpose and a typed parameter schema. The model emits a structured call rather than prose.
- Execution. Your runtime executes the call — a search, a shell command, a database query, an HTTP request — and returns the result as the next observation.
- Iteration. The model reads the observation, revises its plan, and continues until it reports completion or hits a limit you set.
- Protocols. MCP and similar standards let one tool server be reused across many models and clients instead of bespoke glue per integration.
Patterns that work
- Small, sharp tools — a few well-named tools with clear schemas beat one overloaded do-everything endpoint.
- Verification in the loop — let the agent run tests, linters or type checks so failures are caught by machine, not by the user.
- Sub-agents — delegate a bounded task with its own context, and return only the summary to the parent.
- Budgets and checkpoints — cap steps, time and spend; persist progress so a long task can resume.
- Human approval gates — require confirmation before irreversible actions such as payments, deletions or production deploys.
Practical notes
- Treat tool output as untrusted input: it can carry prompt injection, so keep privileges least-scoped and validate arguments.
- Log every call and observation. Without traces, debugging an agent is guesswork.
- Non-determinism is normal — evaluate agents on task success over many runs, not on a single transcript.