The AI agent vs AI assistant debate stays vague when the definition rests on words such as “autonomous” and “proactive.” Published specifications give us a firmer line. Across 152 live Oasis agent templates, every agent has a per-run turn limit between 20 and 60, while 30 have cross-run memory turned off. Memory helps an agent, but it does not make one. Control of the workflow does.
The shortest useful definition
An AI assistant helps you do a task. An AI agent works toward a goal.
The practical test is who chooses and executes the next step. With an assistant, the user normally directs the interaction step by step: summarize this document, revise this draft, or retrieve this record. With an agent, the user sets a goal and a boundary. The system can then choose intermediate steps, use permitted tools, inspect the results, and continue until it finishes or meets a stopping condition.
NIST's analysis of tool use in agent systems describes the prevailing design as a general-purpose model inside software that lets it operate tools and take actions beyond text output.
That definition holds even when both systems use the same model or chat interface. OpenAI defines agents as systems that independently accomplish tasks on a user's behalf and excludes applications where the model does not control workflow execution. IBM makes the overlap explicit: tool access alone does not turn an assistant into an agent. The system must also decide when and how to use those tools toward the goal.
Compare the operating contract
The most useful comparison is a review of what the system is allowed to do after the initial request.
| Dimension | AI assistant | AI agent |
|---|---|---|
| Autonomy | The user chooses most meaningful next steps. | The system chooses intermediate steps inside a defined scope. |
| State | Conversation context may persist, but the user carries the task forward. | The system maintains workflow state across model turns and tool results. Cross-run memory is optional. |
| Execution | Produces an answer, draft, recommendation, or specifically requested action. | Sequences permitted actions and checks their results without a new prompt for every step. |
| Run boundary | Usually ends when the requested response or action is complete. | Ends at a goal, turn or time limit, blocked dependency, error condition, or approval gate. |
| Human role | Directs the work and reviews the immediate output. | Defines the goal, permissions, and decisions that must return to a person. |
These dimensions describe system design. An assistant can search files, call a function, or remember your preferences. An agent can operate through a chat window and still pause before a consequential action. The label becomes useful only when you can inspect the loop, state, tools, and stopping rules behind it.
What published agent specifications reveal
The current Oasis template library represents one implementation. It does not serve as an industry benchmark. It is still useful because every listing exposes the same operational fields.
A real agent run is bounded
Every template in the supplied library snapshot declares a turn budget. The most common setting is up to 30 turns, used by 58 templates. That field makes the limit on “keep working” inspectable. It says nothing about reliability by itself.
Other agent platforms may express the boundary as elapsed time, tool calls, cost, retries, or a workflow checkpoint. Anthropic's guide to building effective agents similarly describes completion, maximum iterations, blockers, and human checkpoints as run boundaries. The name of the limit matters less than whether operators can see and change it.
Long-term memory is optional
Cross-run memory is enabled for 122 of the 152 templates and disabled for the rest. That split corrects a common oversimplification. An agent needs enough state to connect actions within a run, but it does not always need to learn from earlier runs.
A research agent can search, compare sources, and produce a report without remembering next week's request. A pipeline agent may benefit from retaining preferences or prior outcomes. Match state to the job.
Browsing does not define an agent
Only 42 templates can read the web. The other 110 have browsing off because their jobs use connected business systems, local files, or other bounded inputs. An agent that works entirely inside a CRM remains an agent if it controls a multi-step workflow there. An assistant with a search tool remains an assistant if the user still controls each step.
Approval boundaries are part of the specification
“Human in the loop” is too vague unless the documentation names the decision. A useful agent spec says what it may read, what it may write, and which result must be escalated.
The published templates make those boundaries concrete. They also show that agency does not mean unrestricted action.
Worked examples: the boundary changes with the job
Inbox triage can be agentic without sending email
The Outlook Inbox Manager has a run limit of up to 30 turns, retains cross-run memory, requires Outlook, and can optionally use Microsoft Teams. It can triage messages, gather context, and draft replies as a workflow. The approval boundary is unambiguous: drafts remain in the Drafts folder until a person sends them.
An email assistant could draft a reply when asked. This template is agentic because it owns the intermediate triage and context-gathering loop after kickoff. It still does not own the send decision.
A CRM agent can diagnose without changing the forecast
The Salesforce Pipeline Hygiene template can use Salesforce within a run of up to 30 turns. Its published instructions say it reports pipeline problems by owner, writes nothing without approval, and does not touch fields that affect the forecast.
This is a narrower form of agency than “manage the pipeline.” The system can inspect records and organize findings, but a person owns the write boundary. That constraint makes the workflow easier to evaluate because success is a reviewable report, not an undefined promise to improve the CRM.
A research agent does not need cross-run memory
The Research Assistant template can work for up to 45 turns, read the web, and use Exa, Firecrawl, Perplexity, and Google Docs. Its cross-run memory is off. Within a run, it can choose sources, open them, compare disagreements, and synthesize an answer without asking the user to direct every search.
This example separates workflow state from long-term memory. The agent needs the former to carry a research plan through tool results. The published configuration shows that it can do the job without learning across separate runs.
Do you need an AI agent or an AI assistant?
Start with the workflow, then answer these questions.
- Does the work repeat? A one-off request that ends in text or analysis usually fits an assistant. A recurring process with the same goal and variable inputs may justify an agent; these examples of AI agents across business functions show how the boundaries vary by job.
- Who should choose the next step? If a person should decide after every output, keep the interaction assistant-led. If the system can safely choose among documented next steps, an agent can own that loop.
- Must it act in another system? Retrieval alone does not settle the question. Look for a sequence of reads or writes that the system must coordinate without a fresh instruction each time.
- What state must survive? Conversation history may be enough for an assistant. A resumable workflow needs explicit state for completed steps, pending approvals, failures, and remaining work. Cross-run learning is a separate choice.
- Which decision belongs to a person? Name it. “Approval required before sending email” is implementable. “Keep a human involved” is not.
- Could fixed rules handle the job? If the steps are stable and exceptions are easy to enumerate, workflow automation for a small business may be simpler than an agent. OpenAI's agent-building guide recommends checking whether deterministic software is sufficient before adding an agent.
If you cannot state the goal, allowed tools, stop condition, and approval boundary, you are not ready to delegate the workflow. Use an assistant to help a person perform it while you learn where the repeated decisions actually occur.
Turn an “agent” claim into a testable specification
Before adopting or building a system, ask the vendor or owner to expose the following:
- Goal and completion condition: What observable result ends the run?
- Run limit: What caps model turns, time, retries, tool calls, or spend?
- Workflow state: What does the system remember inside a run, after an interruption, and across future runs?
- Tools and permissions: Which systems can it read or change, and at what access level?
- Approval and escalation rules: Which action pauses for a person, and what happens when the system is uncertain or blocked?
- Execution record: Can an operator inspect tool calls, results, failures, and the reason a run stopped?
This specification also provides a clearer evaluation plan. You can check whether the goal was reached, whether the system stayed inside its permissions, whether it stopped at the declared boundary, and whether a person received the cases reserved for human judgment. OpenAI's current agent guidance similarly treats tools, instructions, guardrails, and execution tracing as explicit system components.
The AI agent vs AI assistant choice is therefore less about intelligence than delegation. Use an assistant when a person should carry the workflow from step to step. Use an agent when the system can own that loop inside visible limits, with named decisions that still belong to a human.