What a copilot actually is
Underneath, a copilot is a configuration rather than a personality. Four things are set in advance and applied to every turn of every conversation:
- A system prompt written for one field, which encodes what a practitioner in that field would ask before answering - your state, your timeline, whether there is a deadline attached.
- A model chosen for the job. Some domains need careful multi-step reasoning, some need speed, some need to hold a long document in context. Fixing one model for all of them means being wrong for most of them.
- Parameters tuned for the field. A copilot reading a contract should be low-variance and literal. One helping structure a marketing campaign should not be.
- An explicit boundary. On regulated topics the configuration includes what the copilot will not do, which is the part that stops it producing a confident answer to a question that needs a licensed professional.
Why not just write a prompt
You can, and for a one-off question it works. The reason it stops working is mechanical rather than a matter of quality.
An instruction you type at the start of a conversation is one message among many. As the conversation fills with your problem, its influence relative to everything else falls - which is why a model told to act as a lawyer in message one is producing generalist hedging by message fifteen, usually right at the point the conversation has become specific enough to matter.
A configuration is applied at every turn rather than competing for attention within the context. It also means the model choice and parameters travel with it, which a typed prompt cannot do at all - you cannot prompt your way into a different model or a different temperature.
And there is the ordinary practical point: nobody actually rewrites a good system prompt every time. The version people retype from memory is worse than the version they wrote once carefully, and much worse than one written by someone who structured it around how the field actually works.
Which models, and why it varies
Copilotly uses multiple providers - OpenAI, Anthropic, Google and others - chosen per copilot rather than fixed sitewide. That is not vendor diplomacy. Models genuinely differ at things that matter differently by domain: sustained reasoning over several steps, literal fidelity when reading a document, latency, and how much context they hold without degrading.
Being able to change that per copilot is also what stops the product ageing badly. When a better model ships for a particular kind of work, the copilot that needs it moves and the rest do not - which is a considerably smaller change than rebuilding around a new provider.
What it remembers, and what it does not
Within a conversation it holds the situation, so follow-ups do not need re-explaining. History is saved to your account, which matters more than it sounds: problems with deadlines are worked on across days, and starting from scratch each time is how the detail gets lost.
What it does not do is train on your conversations. They are encrypted in transit and at rest, are not used to improve models, and are deletable at any point - the detail is in the privacy policy.
Where specialisation stops helping
Worth saying plainly, because a page like this usually does not. Specialisation improves the shape of an answer - what gets asked first, what gets flagged, where the boundary is stated. It does not make the underlying model know your jurisdiction’s current statute, and it does not make an uncertain answer certain.
So for anything with a deadline, a filing, or a licence attached, the useful output is a prepared question rather than a conclusion. That is why every regulated domain page carries an explicit list of what the copilot will not do, and links to the primary source rather than asking you to take our word for it.
The honest claim is narrower than the marketing default and it is the one that survives contact with a real problem: this makes the hour you eventually buy from a professional shorter, cheaper and better spent.