Most software follows a path that developers define in advance. An AI agent differs in one important way: a model can choose the next action from the information available during the run.
This ability helps with tasks whose steps cannot be known before the work begins. A coding task may require one file or twenty. An investigation may end after one query or require evidence from several systems. The agent adapts its next action to each result.
The same flexibility adds cost and uncertainty. Each model call can make a wrong choice, and one wrong observation can affect later choices. A useful agent system combines model capability with clear tools, controlled execution, and feedback from the environment.
An agent uses tools in a loop
A language model produces a response. An agent gives the model tools and repeats the process after each tool result.
A basic agent run follows these steps:
- The system provides a goal, instructions, relevant context, and available tools.
- The model returns text, a tool request, or both.
- The application checks the tool request and decides whether to execute it.
- The tool returns an observation from the environment.
- The application adds that observation to the next model call.
- The run continues until it succeeds, stops, or needs human input.
The model does not execute the external action. It produces a structured request. Application code validates the arguments, applies policy, supplies credentials, calls the tool, and records the result. The model then uses that result when choosing the next action.
Repeated observations let the model revise later actions. A coding agent can inspect a repository, edit a file, run a test, and respond to the failure. A research agent can search for a primary source, detect a conflict, and narrow the next query.
This leads to a practical definition. An AI agent is a system in which a model selects tools and directs part of a goal-oriented process over several turns. The broader system supplies the harness, tools, and environment required to turn model requests into controlled actions.
The base component is often an augmented language model. Retrieval gives the model access to current documents or records. Tools let it request defined operations. Memory can provide selected information from earlier work. These features do not make a system an agent by themselves. The model becomes part of an agent when it uses them to direct a multi-step process.
Keep these capabilities easy to inspect. A retrieval result should identify its source. A memory item should keep its owner and verification status. A tool should state its inputs and effects. The model needs enough information to choose among them, while the application retains control over access and execution.
The loop can also use structured model output without exposing every internal step. A tool request, concise plan, progress update, or completion claim gives the harness something it can validate. Hidden reasoning is not a substitute for observable actions and results.
Workflows and agents provide different kinds of control
In a workflow, code defines the order of operations. A model may classify a request, extract data, or draft text, but the application chooses what happens before and after each call.
Workflows can use several patterns. Prompt chaining sends the result of one model call into the next fixed step. Routing sends different inputs to different handlers. Parallelization runs independent work at the same time. An orchestrator can assign work to a known set of workers. An evaluator can review a result and request another fixed iteration.
These systems can be useful without giving the model control over the full route. They are easier to inspect when the task has a stable sequence and known decision points.
In an agent, the model can decide which tool to call, whether another search is needed, and how to respond when an action fails. This supports open-ended work, but each turn adds latency, cost, and another chance for error.
Start with the simplest design that completes the task. A single model call with retrieval may be enough. Use a workflow when developers can define the sequence. Use an agent when the value depends on choosing a path from new evidence.
Use agents where feedback can guide the work
Agents fit tasks with three properties. The route cannot be fixed in advance, the environment can provide useful feedback, and the system can check whether the task succeeded.
Coding is a strong example. Tests, compilers, version control, and file inspection provide concrete observations. Customer support can also fit when the agent has current account data, controlled actions, clear resolution criteria, and access to a person for exceptions.
Tasks with weak feedback are harder. If the environment cannot show whether an action helped, the agent may continue from an incorrect assumption. Long runs also increase the chance that early errors affect later decisions.
Human oversight should match the consequence of each action. An agent may search and draft without review, then request approval before sending a message, changing production, or moving money. Approval should describe the exact proposed action and its target.
Autonomy is not one setting for the whole product. The system can grant different permissions for reading, drafting, reversible changes, external communication, and irreversible actions. This provides flexibility where it helps and review where an error would matter.
Confirm results with environment feedback
Agents can report the intended result instead of the observed result. A model may request a tool and then write as if the call succeeded. It may edit code and assume the tests now pass. It may use a plausible search result without checking the source.
For consequential steps, the application should return direct feedback from the environment. A file operation should identify the file it changed. An external write should return the provider's operation ID and status. A test should return its exit status and relevant failures.
The application should also keep authoritative run state outside the model conversation. This state records completed actions, pending approvals, budgets, errors, and confirmed external effects. The model can refer to it, but model text should not determine whether an operation occurred.
Completion requires evidence. A coding task may require the requested behavior and independent tests. A research task may require primary sources for each material claim. A customer operation may require the correct state transition and an audit record.
Planning can help expose dependencies before action. Plans should remain short enough to update when observations change. A two-step task may not need a written plan. A long migration may need milestones, checkpoints, and separate verification.
The system around the model controls execution
Anthropic separates an agent system into the model, harness, tools, and environment. The model chooses responses and tool requests. The harness provides instructions and guardrails. Tools define the operations the model may request. The environment contains the systems and state where the work occurs.
Each component affects behavior. Tool names and schemas affect which action the model selects. Environment feedback affects whether it can recover. Harness instructions define the task and operating rules. The model affects reasoning, planning, and tool use.
Deterministic code must enforce permissions. A prompt can tell the model that production changes require approval, but the deployment tool must reject an unapproved request. Credentials should remain outside model context and should be scoped to the acting user, organization, resource, and task.
Side effects need retry protection. Network timeouts can leave an unknown outcome: the provider may have completed the request even though the agent did not receive the response. Idempotency keys and provider operation IDs can prevent or detect duplicate actions.
The system also needs stopping conditions. Common limits include turns, time, cost, repeated failures, and action classes. The agent should preserve partial work and report why it stopped. It should ask for help when the required information or authority is missing.
Add more agents only for a measured reason
A multi-agent system assigns work to more than one model-directed process. It can support parallel research, independent review, or separate permission domains.
It also adds communication, coordination, and evaluation work. A delegated task needs a clear input, expected output, budget, and owner. The parent agent needs evidence for the result rather than relying on an unsupported summary.
Begin with one observable agent loop. Record the goal, component versions, context sources, tool requests, policy results, observations, cost, and final state. Build evaluation cases from representative tasks and confirmed failures.
Add another agent when an evaluation shows that parallel work, independent judgment, or permission separation improves the result. Do not add agents to reproduce an organization chart or to make a simple workflow appear more advanced.
Multi-agent evaluation should include delegation failures. Test whether the parent gives each worker the correct context and whether the worker returns evidence in the expected form. Measure duplicate work, conflicting changes, total cost, and the final result. Parallel execution is useful only when the coordination cost remains lower than the benefit.
An agent is useful when a model must choose actions from new evidence during a task. A reliable agent also needs tools with clear contracts, an environment that returns accurate observations, deterministic controls, and tests that measure the final state. The product should increase autonomy only when these controls support it.