What Copilot Is and What It Isn't
Microsoft 365 Copilot is an assistant for a person working inside a Microsoft document or conversation. Most disappointment with it comes from asking it to do something outside that sentence.
Picture the common version. Licenses go out after a vendor demo that made the assistant look like it could run an office. A few weeks later the verdict is "it's useless." People had asked it to process incoming client documents, watch a shared inbox, and update a tracking spreadsheet. It did none of that, and it was never going to. Those are automation jobs, and the team had bought an assistant.
Then somebody points the team at assistant-shaped tasks, and the same license starts to earn its place. Nothing about the software changed. The expectations did.
Four boundaries in one sentence
Each part of that definition is a boundary.
An assistant. Copilot drafts, summarizes, suggests, and answers. A human decides what happens next. Expecting it to be accountable for an outcome, the way an employee or an automation is, takes it outside its territory.
For a person. Copilot acts when someone asks it something. It is not watching an inbox at 6 a.m. and noticing that a shipment file arrived. Microsoft's agent technologies loosen this boundary in specific ways, but for the Copilot inside Word and Outlook it holds.
Working inside. It helps with the work happening in the app in front of you. It has real reach into your organization's Microsoft content, but it is not an operations center watching your queue, your vendor portal, and your tracking spreadsheet at the same time.
A Microsoft document or conversation. Its home ground is email, Teams messages, documents, and SharePoint. Once the work depends on the ERP system or an industry database, you are at the edge of the map.
Two requests, one afternoon
An operations manager asks: "Catch me up on the vendor thread. What was decided, and is anyone waiting on me?" A person is present, asking about a Microsoft conversation. Every boundary holds, and Copilot can answer on request.
Later the same manager asks for this: "Whenever a PO arrives in the shared inbox, validate it against the ERP and update the tracker." No person is present for each instance. The work lives partly outside Microsoft content. Someone is accountable for the result. Three boundaries are crossed. This is a real problem with a real solution, but no phrasing will turn it into a Copilot prompt.
When Copilot disappoints you, check which boundary the task crossed. It is rarely a mystery for more than a minute.
The same task, prompted twice
Say a manager has a twelve-page vendor proposal to react to by 2 p.m. The request "Summarize this document" returns an accurate overview that is too generic to decide anything with.
Now try: "Summarize this proposal for a skeptical reader. What exactly are they committing to deliver, what does it cost fully loaded, and where is the language vague?" That version tends to surface the commitments, the real cost picture, and the soft spots, such as training listed as "up to four sessions," which is a ceiling and not a promise.
Same document, same AI, a minute apart. The answer can still miss things, like success metrics left "to be mutually agreed," so a human still reads. But the gap between "Copilot is generic" and "Copilot is useful" is usually the request, not the product. Our post on five prompt patterns covers the structures that close that gap.
What Copilot is not
- Not an automation engine. It will not watch for events and act on them. If a problem starts with "every time X happens," that is automation, which is a different tool family.
- Not a system of record. It does not maintain your data or enforce your business rules, and it does not guarantee that Friday's answer matches Monday's. Where consistency and auditability are the requirement, the work belongs in an application.
- Not a mind reader. It knows your content. It does not know your intent or your standards.
- Not a strategy. This one costs organizations the most. "We have Copilot" tends to become the answer to AI questions across the building, which quietly files real problems under "solved." They are not solved. They are unaddressed, with a license fee attached. Where an assistant ends and custom software begins is a question worth asking before that happens.
It will be wrong, confidently
Copilot delivers correct and incorrect answers in the same tone. Ask what the travel policy says, and it may summarize the 2022 version that nobody deleted, fluently and without any signal that something is off.
The countermeasure is a norm, not a feature: anything that feeds a decision gets checked at the source. In most grounded answers Copilot shows the documents and messages it drew from, though not uniformly in every app. Where sources appear, clicking through is the whole discipline. Where they don't, find the source the old way before acting.
The five-minute expectation conversation
Before a team gets access, or this week if it already has it, say something like this out loud:
"Copilot is an assistant, not an oracle. It will save you real time on catching up, first drafts, and finding things in our own content. Its first answer is a draft, and you own what you send. It states wrong answers as confidently as right ones, so anything feeding a decision gets checked at the source. And when you find a task it's surprisingly good at, tell the rest of us."
Teams that hear something like that start from realistic expectations. Teams that don't can swing between "this is magic" and "this is useless," and both moods lead to bad decisions.
PROCESS NOTE
This essay represents our original ideas and structural direction, with prose development and editing assisted by AI.
This post is adapted from Chapter 1 of Copilot at Work, our free guide for teams adopting Microsoft 365 Copilot. Download the full guide.