UnderstandExplainer
AI agents, assistants and automations: what is the difference?
Follow a task from suggestion to action, and see why permissions, approval and recovery matter more than the agent label.
The short version
The key question is who chooses the next step—and what the system is allowed to change without asking you.
The important difference is who chooses the next step
An ordinary automation follows a defined route: when something happens, perform specified actions. A conversational assistant may help you think or draft without changing anything outside the conversation. An agent can select tools and decide how to continue towards a goal. Products often combine these patterns, so the label alone tells you very little.
Anthropic's Building effective agents distinguishes predefined workflows from systems in which the model dynamically directs its process and tool use. The article also recommends starting with simpler solutions and considering the additional cost and complexity of agentic approaches. Its original publication dates to December 2024; it is a conceptual foundation, not a current product catalogue.
For a non-developer, the useful questions are straightforward. Can the system only suggest an answer, or can it act? What can it read? What can it change? Which decisions are fixed in advance, and which will it make along the way?
Follow one task through three designs
Imagine you want help organising an event. In an assistant workflow, you paste fictional planning notes and receive a draft checklist. You decide what to copy into your own tools. The assistant's output is a proposal.
In a fixed automation, a submitted form might create a draft task using predefined fields. If a required field is missing, the workflow stops or follows an explicitly configured exception. The route is known even if an AI model helps classify the incoming text.
In an agentic workflow, the system might inspect information, notice a missing venue, search permitted sources, compare options and propose another step. That flexibility can be useful. It also means you must think about the boundaries of its choices, rather than only the final goal.
Explore the idea
The approval boundary
Simulated event planning. No accounts or tools are connected.
01Read input
02Draft proposal
03Human approvalApproval gate
04Verify result
Simulation only · no message is sentObserve
Inspect the supplied plan
A bounded system reads only the fictional notes it was given. No wider account access is needed for this stage.
Permission: read this input
1 of 4 · choose any step
Drafting and acting are different permissions
“Help me organise the event” is not a precise permission model. It could mean suggest a schedule, edit a shared plan, contact attendees or pay a deposit. Those actions have different consequences. Separate them explicitly.
A sensible trial might allow reading a fictional document and drafting a plan, while requiring approval before editing a shared file or sending a message. Approval should show the actual proposed action: recipient, message, attachment, destination or change. A vague “continue?” prompt provides little basis for a decision.
Keep the permissions as narrow as the task allows. If a workflow only needs to read one folder, access to an entire account adds exposure without an obvious benefit. The specific controls depend on the product, so confirm what the connected service actually permits rather than assuming a prompt can enforce every boundary.
Plan for the uninteresting failure cases
Demonstrations tend to show the happy path. Real workflows also encounter missing fields, duplicate requests, ambiguous names, unavailable services and partial completion. Those cases often matter more than the impressive first run.
Suppose a system creates a task but times out before reporting success. If it retries without checking, it might create the same task again. Or suppose two people have similar names; a confident choice could assign work to the wrong person. A useful trial includes these cases rather than treating them as surprises for later.
Ask how you can inspect the action history, stop a run and recover from a mistake. For each consequential step, know what success looks like in the destination system. “The agent says it sent the message” is weaker evidence than checking the sent message and its recipients.
Start with a reversible sandbox
Use invented records and a test destination. Give the system a small job with a clear finish, such as preparing three draft tasks from a sample form. Include one incomplete input and one duplicate. Decide in advance what it should do with each.
Observe whether it asks for missing information, exposes uncertainty and respects the approval boundary. Do not evaluate only the final appearance of the output. Inspect the intermediate changes and the permissions it used to get there.
The interactive example above is a scripted illustration of this boundary. It cannot read your accounts, create tasks or send messages. It is intended to make the difference between a proposal and an approved action visible before you connect a real system.
Autonomy is a setting to justify, not a prize
More autonomy is not automatically a better experience. If a task is predictable, a short fixed workflow may be easier to understand and maintain. If the next step genuinely depends on what is discovered, a bounded agent may be more appropriate.
Consider a newsletter process. Collecting submissions into a folder can be straightforward automation. Suggesting themes may benefit from a model. Publishing the finished edition is a separate action with a reputational consequence. There is no requirement that all three stages have the same level of autonomy.
This mixed design is often easier to reason about: deterministic steps where the rules are clear, model assistance where interpretation helps, and human approval where responsibility matters. The exact arrangement should follow the task, not the desire to call the product an agent.
Decide what would justify expanding access
Before a pilot, write acceptance criteria: no duplicate tasks, no invented owners, explicit handling of missing dates, and no external messages without approval. Run examples that challenge each criterion. Keep the failures visible.
A few successful attempts are encouraging, but do not prove the system is reliable under every condition. Expand gradually: a larger test set, a longer supervised trial, or one additional permission with a clear rollback. Stop if you cannot explain an unexpected action.
Also count supervision. If you need to watch every move and repair the output, the workflow may not be saving effort yet. That is a useful finding, not a reason to hide the checking time from the comparison.
Ask five questions before connecting anything important
What information can it read? What actions can it take? Where does approval happen? How do I see what actually happened? How do I stop and recover?
If the answers are clear, you can design a meaningful trial. If they are unclear, begin with drafting and fictional data. The opportunity in agents is not removing people from every step. It is deciding carefully which steps a system can handle, which need supervision, and which should remain yours.
Anthropic: Building more effective AI agents
A technical discussion from Anthropic about agent patterns, tools and system design. Optional further viewing; the plain-language explanation above stands on its own.
Go to the source
Primary sources checked on 23 September 2026. Publication dates and product details may differ; check the source for its scope.
About this article
This is an explanatory guide with illustrative examples, not a product benchmark or a report of hands-on test results.