“Assistant” and “agent” are used inconsistently across products. Instead of relying on a label, inspect what the system can initiate, what tools it can call, what state it can retain, and what actions a person must approve. This guide is a capability framework, not a market survey.
Compare behavior, not branding
- Initiation: Does the system respond only to a request, or can it run on a schedule or trigger?
- Tools: Can it search, read, write, send, purchase, or change records?
- State: Does it retain context between tasks, and can the user inspect or clear that state?
- Autonomy: Does it suggest a next step or execute it?
- Oversight: Can a person review the exact action and stop or undo it?
A feature can combine assistant-like conversation with agent-like tool calls. The useful question is how much authority it has in the workflow.
Choose the least autonomy that solves the task
For drafting, a response-only assistant may be enough. For retrieving a status, allow read-only access and verify the source. For making a change, require a person to review the proposed action before it is applied. For irreversible or consequential actions, keep a qualified human decision-maker.
Example decision
Suppose a team wants help triaging an incoming request. The system might classify the request and propose a queue. The next step—changing priority, contacting a customer, or closing a case—should be separately authorized. Test ambiguous and out-of-scope requests and define when it must ask for help.
Risk and governance
NIST’s AI Risk Management Framework offers a voluntary way to think about context, measurement, and risk management. Microsoft’s agent safety guidance discusses agent-specific safety controls. Neither source makes a product automatically safe; adapt controls to the actual permissions and harm of a failure.
Describe the capability you actually observe
Product labels are weak evidence because the same interface can combine a conversational assistant, retrieval, scheduled automation, and tool execution. Describe each capability independently and confirm it in current product documentation or a low-risk sandbox before granting access.
| Question | Record | Why it changes the boundary |
|---|---|---|
| What starts a run? | Person request, schedule, event, or another system | Unattended triggers need an owner and a way to pause them |
| What can it read? | Documents, messages, records, or only the prompt | Read access can still expose data beyond the task |
| What tools can it call? | Read, draft, write, send, delete, or purchase | Side effects need least privilege and explicit approval |
| What state persists? | History, memory, files, and logs, with their owners | Retention and deletion must be understood before use |
| How is a person involved? | Review before action, review after action, or no checkpoint | Consequential actions need a meaningful opportunity to stop or correct them |
Example: a help-desk assistant may answer from a document link while an agent can also open a ticket, change its priority, or send a reply. Test the same fictional request in a sandbox and document which actions are proposed versus executed. Start with read-only access; add a write permission only for a task with a named owner, approval, and recovery path.
This comparison answers “what can the system do?” The separate use-case matrix asks whether a task should be delegated; the workplace control guide explains how to set approvals and rollback.
Related reading
For a list of bounded, low-risk tasks, see the agent use-case guide. For human approval, logging, and rollback, read the controlled-use guide.
About the author
Femica Maydinda Harend writes practical technology guides for AILooma focused on transparent workflows and limitations.
Editorial note
Product definitions and controls vary by version and plan. Inspect current documentation and permissions before enabling tool access.
