Assistant, agent, copilot: sorting out the labelsAssistant, agent, copilot: sorting out the labels

Assistant, agent and copilot began as useful metaphors, then products accumulated one another’s features. A copilot can now call an agent; an assistant can plan several steps; an agent can appear inside a chat box. Product names describe how a vendor wants the experience to feel, not a standardised capability level.

Replace the label with five questions: what starts the work, what context persists, which tools are available, what can happen without approval, and how the result is supervised. Those answers determine both value and risk. They also let unlike products be compared on the same page.

A copilot generally assists inside a particular work surface. It drafts in a document, explains code in an editor or helps retrieve work information. The person remains at the controls. Microsoft describes Microsoft 365 Copilot Chat as a secure AI chat experience and separately describes declarative and custom-engine agents that can extend capabilities and actions.^[4][5] That illustrates why the umbrella name alone cannot tell you the autonomy underneath.

An assistant generally emphasises continuity. It may remember preferences, retrieve approved facts, maintain task state and use several tools. It can still require approval for every external action. An agent emphasises a model-directed loop: observe the current state, choose a step or tool, inspect the result and continue until completion, handover or a stop condition.

OpenAI and Anthropic both recommend selecting the simplest pattern that fits the job, adding agentic complexity only when the workflow benefits from flexible model-led decisions.^[1][2] A fixed sequence is easier to test than an open loop. If a rules engine can choose the next step correctly, it is often the better orchestrator.

Scope is the breadth of context, systems and people the software can touch. Autonomy is how much it may decide or execute before a person intervenes. They are independent: a broad assistant can see email, calendar and files while requiring approval for every action; a narrow scheduling agent can operate autonomously inside one calendar rule set.

Risk tends to rise when both increase. Broader scope creates more sensitive context and possible tool combinations. Higher autonomy gives errors more opportunity to propagate before review. This is why a product with a modest interface can require more governance than a feature-rich chat subscription.

For a copilot, ask what context it can see, whether it cites the current source and which actions happen only after acceptance. For an assistant, ask what it remembers, how task state is represented, who can access it and how memory is corrected or deleted. For an agent, ask how tools are allowlisted, what limits a loop, what stops a dangerous or repeated action and how partial work is recovered.

OWASP’s LLM risk catalogue includes prompt injection, sensitive-information disclosure, excessive agency and improper output handling.^[6] Those risks cross all three labels, but the consequence changes with permissions. An injected instruction that alters a draft is bad; the same instruction reaching a payment or messaging tool is materially worse.

• Show the exact data and systems visible to the software, including connected sources enabled by default.
• Show the difference between a suggestion, a prepared action and an executed action in the interface and record.
• Show how a user revokes access, corrects retained context and reconstructs a surprising outcome.
• Show a failed tool call, a conflicting instruction and an unsupported request — not only the happy path.

Capabilities should earn trust in stages. Start with a contained work surface or advisory task. Add persistent context only when there is a recurring benefit and a clear retention rule. Add tool use in preparation mode. Then allow narrow, reversible actions where evaluations show that the system handles ordinary and edge cases consistently.

IMDA’s agentic AI framework likewise emphasises early risk assessment, bounded autonomy and access, human checkpoints, lifecycle testing and accountability.^[3] The sequence is not bureaucratic overhead; it is how a team learns the real workflow before software silently encodes its assumptions.

1. Step 01

   Prove usefulness

   Use a copilot-like mode on a repeated task and measure review effort as well as speed.

2. Step 02

   Add continuity

   Introduce only the memory and task state the recurring outcome requires.

3. Step 03

   Connect safely

   Use read access first, then prepared writes, with separate credentials and logs.

4. Step 04

   Evaluate the lane

   Test realistic successes, boundaries, bad inputs and external failures.

5. Step 05

   Grant and review

   Allow a reversible action, monitor exceptions and withdraw permission if evidence changes.

A copilot works beside you, an assistant carries context for you, and an agent pursues a bounded goal through steps. A real product may do all three. Describe the workflow in verbs — search, prepare, decide, send, update, wait, escalate — then attach permissions and owners to each verb. That specification is more useful than winning a terminology debate.

If you are deciding what level of system the work actually warrants, use the Assistant Finder. It can recommend an ordinary tool, a subscription, a specialised product or an integration rather than assuming the most agentic option.