What separates an assistant from a copilot?

Where it lives. An assistant has its own surface that you go to, so it knows nothing about your current work unless you tell it. A copilot sits inside a tool you were already using and can see the document, the code or the message. The same underlying capability, arranged so that one needs context supplied and the other has it.

Why do results vary so much between people?

Because the assistant assumes nothing, so almost all the variation comes from what was supplied. Somebody who attaches the relevant material and states the audience and the standard gets a usable draft; somebody who types one line gets something generic. That gap is a skill gap rather than a product one, and it closes with sharing examples.

Should a team standardise on one?

For an approved default with an administered account, usually yes, because that is what makes terms, visibility and support manageable. Insisting nobody may ever use another tends to relocate the behaviour rather than prevent it, so the workable position is a good default plus a route for asking about something else.

Is it safe to paste work documents into one?

It depends on the account and the material rather than on assistants in general. Administered organisational tiers commonly carry commitments about retention and training that individual accounts do not, so the question is which account is being used and what category the material falls into. Both belong in a written policy rather than in individual judgement.

How do we get past the first-fortnight plateau?

Move from asking to configuring. Fix the instructions for a recurring job, attach the reference material it always needs, and save it so the team uses the same setup. That step converts a general tool into a specific one and is where individual novelty turns into something a team can depend on.

Does it remember our previous conversations?

Only if the product implements that, and it varies. The model itself carries nothing between requests; any continuity is a feature the product built, whether by resending the thread or by storing material deliberately. Worth knowing which, because it determines both how useful the tool feels and what it is retaining.

Glossary

AI assistant

An AI assistant is a product with its own surface that you go to and ask, built to handle many kinds of task rather than one, and to hold a conversation rather than answer once.

In plain terms

It is the box you open and type into. You bring the work to it rather than it appearing inside the work, which is the practical difference between this and the help that shows up in your document editor. It will attempt almost anything you describe, which is its strength and the reason it disappoints people who expected it to be good at one thing in particular. It is a general instrument that rewards being told exactly what you want.

Why it matters

Because it is where nearly every organisation's AI use starts, and the habits formed in the first fortnight tend to persist. People who learn to give it context and specific instructions get results that make the case for everything after it; people who ask it one-line questions conclude the technology is overrated and stop. The gap between those two experiences is not the product and not the model. It is what the person put in, which means the assistant is as much a training question as a purchasing one.

How it works

You go to it, which sounds trivial and shapes everything. Because it has its own surface, it has no automatic knowledge of what you were doing, so every request has to carry its own context. That is the tax the general instrument charges and the reason attaching the relevant document changes the quality of an answer more than almost anything else you can do.

The conversation is the working memory. Each turn resends the thread so the model can follow it, which is why it can refer back to something from ten messages ago and why a long conversation gets slower and dearer. It also means a thread that has wandered carries its wandering forward, so starting fresh for a new subject is genuinely better practice rather than tidiness.

It is deliberately general, and generality is a trade. A tool built for one job encodes assumptions about that job and needs less from you; an assistant assumes nothing and needs more. Neither is better in the abstract, and the mistake is expecting an assistant to behave like a specialist without being told what the speciality is.

Most now reach beyond the conversation, and that changes the risk profile. Uploading a file, searching the web, running code or connecting to other systems all extend what it can do and extend what it can reach. A product that can act on your systems is a different purchase from one that can only talk, and the terms worth reading are different too.

Saved configurations are where teams get compounding value. Most assistants let you fix instructions, attach reference material and reuse the result, which turns a general tool into a specific one for a recurring job. That is usually the step between an individual finding it useful and a team relying on it, and it is the step most organisations skip.

The account decides the terms, not the product. The same assistant on a personal login and on an administered organisational tier can differ on retention, on training, and on whether anybody can see what was used. That distinction matters more than which assistant you chose, and it is the one most often left unexamined.

Where it sits in a working day decides how much it is used. An assistant in a separate tab competes with the work rather than joining it, which is why adoption tends to concentrate in tasks big enough to justify switching context and thins out for the small ones. Teams that put a shortcut where people already are, or that pick the moments worth switching for, get more out of the same licence than teams that simply grant access and hope.

It will always answer, which is the failure mode to plan around. There is no state in which it declines because it does not know, unless the product was built to recognise that case, so an absent fact becomes an invented one delivered in the same confident register as everything else.

Where the help appears

This is the distinction people most often collapse, and collapsing it produces two predictable disappointments. Somebody expecting assistant-like range from a copilot finds it will not step outside the document it lives in. Somebody expecting copilot-like awareness from an assistant is puzzled that it has no idea what they were working on a moment ago, and concludes it is less capable than it is. Neither is a defect. The copilot trades range for knowing where it is; the assistant trades that knowledge for being able to attempt anything. Read practically, the distinction tells you where the effort goes: with a copilot the work is mostly reviewing what it suggests, and with an assistant a real share of the work is supplying what it needs before it can suggest anything worth reviewing.

Seen in the wild

Open a general assistant, paste in a long document and ask for the three points that matter to a specific reader.
ChatGPT
Give one a set of files and ask it to reason across them, where the answer depends on what you supplied rather than on general training.
Claude
Ask an assistant built around retrieval the same question, and notice that the answer arrives with sources attached.
Perplexity
Run one on your own hardware, where the surface is familiar and nothing you type leaves the machine.
LM Studio

Common misconceptions

People assume

It is a search engine that writes.

In fact

Search retrieves things that exist and shows you where they came from. An assistant produces an answer, which may or may not be grounded in anything retrievable. Some products combine the two and show sources; where they do not, the answer has no provenance and treating it as though it does is the commonest early mistake.

People assume

A better model would fix our disappointing results.

In fact

Early disappointment is usually about what was supplied rather than which model answered. An assistant given no context about your organisation, your standards or the reader cannot apply them, and a stronger model with the same gap produces a more fluent version of the same miss.

People assume

We should wait for the technology to settle before committing.

In fact

The surface has been remarkably stable even while the models underneath changed repeatedly: a box you type into, a conversation, attachments, saved configurations. What a team learns about supplying context and judging output transfers across products and across versions, which makes the waiting expensive and the skill durable.

People assume

Everybody in the team is using it the same way.

In fact

Usage varies enormously and quietly. One person is pasting whole documents and iterating; another is asking one-line questions and concluding it is a toy. Sharing what good use looks like inside a team is usually worth more than any feature on the roadmap, and almost nobody does it deliberately.

Telling them apart

AI assistant vs AI copilot

AI assistant

Has its own surface. You go to it, and carry the context with you.

AI copilot

Lives inside a tool you were already using, and can see what you are working on.

Ask where it appears. A separate place you open means the first; inside the work means the second.

Questions

What separates an assistant from a copilot?: Where it lives. An assistant has its own surface that you go to, so it knows nothing about your current work unless you tell it. A copilot sits inside a tool you were already using and can see the document, the code or the message. The same underlying capability, arranged so that one needs context supplied and the other has it.
Why do results vary so much between people?: Because the assistant assumes nothing, so almost all the variation comes from what was supplied. Somebody who attaches the relevant material and states the audience and the standard gets a usable draft; somebody who types one line gets something generic. That gap is a skill gap rather than a product one, and it closes with sharing examples.
Should a team standardise on one?: For an approved default with an administered account, usually yes, because that is what makes terms, visibility and support manageable. Insisting nobody may ever use another tends to relocate the behaviour rather than prevent it, so the workable position is a good default plus a route for asking about something else.
Is it safe to paste work documents into one?: It depends on the account and the material rather than on assistants in general. Administered organisational tiers commonly carry commitments about retention and training that individual accounts do not, so the question is which account is being used and what category the material falls into. Both belong in a written policy rather than in individual judgement.
How do we get past the first-fortnight plateau?: Move from asking to configuring. Fix the instructions for a recurring job, attach the reference material it always needs, and save it so the team uses the same setup. That step converts a general tool into a specific one and is where individual novelty turns into something a team can depend on.
Does it remember our previous conversations?: Only if the product implements that, and it varies. The model itself carries nothing between requests; any continuity is a feature the product built, whether by resending the thread or by storing material deliberately. Worth knowing which, because it determines both how useful the tool feels and what it is retaining.

Key takeaways

You go to an assistant, so every request has to carry its own context.
The conversation is the working memory, which is why long threads slow and cost more.
Generality is a trade: it assumes nothing, so it needs more from you than a specialist tool.
Saved configurations are where a team gets compounding value rather than novelty.
The account, not the product, decides retention and visibility.

Tools that use this

ChatGPT
The general case: one surface, many kinds of task, context supplied by you.
Claude
Reasoning across supplied files rather than from general training.
Perplexity
An assistant built around retrieval, so answers arrive with sources.