Key takeaways
- An agent needs an objective, observable results and permission to use particular tools.
- Separate a proposed action from a completed action with a verifiable receipt.
- Judge usefulness by accepted outcomes and correction effort, including failures.
Overview
The useful distinction is control. An agent can decide which step to take next, while a conventional workflow follows a path its author specified. A production agent still needs boundaries: approved tools, a budget, a stopping condition and a record of what happened. Autonomy describes how decisions are made; it does not establish that the decisions are correct.
How it works
Translate the objective into a task with an explicit success condition.
Choose an allowed tool, inspect its result and decide whether another action is needed.
Return evidence and unresolved issues, or request human approval when the task exceeds its authority.
The parts of a useful agent
Consider an agent asked to find suppliers in a new territory. The objective defines the geography and product category; tools provide company search and evidence retrieval; working state records which firms have already been checked. The model chooses a next step, but the surrounding application decides which operations are available. A search result is information for a decision, not an instruction that can expand those permissions.
The output contract matters as much as the prompt. A useful supplier record might require a company domain, a product reference, a dated source and an unresolved-questions field. If the agent cannot establish one of those facts, it should return an explicit gap. A fluent paragraph that silently invents the missing field is harder to use than an incomplete record with a clear next action.
From suggestion to completed work
Keep reasoning, authorization and execution visible as separate stages. An agent can suggest a CRM update without having permission to write it. Once authorized, the tool response should identify the affected record and whether the update succeeded. A final message saying “done” is not sufficient evidence if the destination rejected the request.
For a first deployment, define the following contract for each tool. This makes failures recoverable and gives an operator enough information to distinguish a bad decision from an unavailable service.
| Operation | Required boundary | Completion evidence |
|---|---|---|
| Search companies | Territory and lookup budget | Candidate identifiers and source links |
| Enrich a record | Allowed fields and overwrite rules | Accepted fields plus unresolved statuses |
| Write to CRM | Workspace permission and approved changes | Destination record ID and applied version |
Measure an agent on the whole task
An illustrative evaluation might contain 100 research tasks: 75 accepted without changes, 15 accepted after correction and 10 unresolved. Report those groups separately. Calling all 90 eventually accepted tasks “autonomous successes” hides the human work. Measure completion time from submission to usable delivery, including review queues and retries, rather than only model response latency.
Keep a small set of difficult examples: identical company names, conflicting dates, an unavailable source and a revoked integration. Reuse it when prompts, models or tools change. Inspect both the final result and the sequence of operations so a plausible answer cannot conceal an unnecessary purchase, duplicate write or unsupported inference.
What this looks like in practice
For an illustrative prospecting task, an agent finds companies matching a region and industry, checks their domains, identifies relevant contacts and returns the source for each accepted field. Missing evidence stays missing.
Examples explain the concept; they are not reported customer results.What to check
Measure completed, correct tasks and cost per accepted result. Review tool logs, permission boundaries, failure recovery and how the agent handles contradictory evidence.
Common mistake
Giving an agent broad write access because its first demonstration succeeded. A plausible answer is not proof that the underlying actions or records are correct.
AI agent vs. Workflow automation
Workflow automation follows predefined transitions. An agent chooses some transitions at runtime. Many reliable systems combine a fixed outer workflow with narrowly scoped agent decisions.
Read the Workflow automation definition →Evidence and context
“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
Questions answered
What is an AI agent?
An AI agent is a software system that uses a model to choose actions, call tools and assess results while working toward an objective within defined permissions.
Can an AI agent work without human approval?
Yes, within permissions granted in advance. Actions such as publishing, changing important records or spending beyond a budget can still require explicit approval.
Does an AI agent need access to every tool?
No. Give it only the tools and data needed for its assigned task. Smaller permissions make behavior easier to test and incidents easier to contain.
Does an AI agent need several models?
No. One model can choose among several tools, while a larger system may use specialist models. The useful question is whether another component improves the result enough to justify extra coordination, latency and failure modes. Evaluate the complete task before adding components.
What happens when an agent cannot finish?
It should preserve completed work, explain the specific missing evidence or failed operation, and stop within the agreed budget. A recoverable result includes enough state for a person or later run to continue without repeating successful work or losing its sources.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
- Building effective agents ↗Anthropic
Architecture guidance; originally published December 2024.
- AI Risk Management Framework ↗NIST
Continue reading on the blog
Explore all articles and guides →Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.