Choosing an AI tool: start with where the work lives, not a ranking

You have four capable AI assistants within reach and a task on your screen, and every comparison chart you find tells you something different. The charts do not help because they answer a question nobody at work is actually asking, which is "which model is smartest?" rather than "which one should I open for this?"

This guide replaces the chart with three questions, a rough map of where each tool fits, and a short list of cases where the answer changes. The tool-specific observations come from the author's side-by-side use up to late September 2026. Products change quickly, so treat the named tools as examples of a pattern and re-test the pattern when a tool changes.

The three questions

Going back and forth between Claude, Copilot, ChatGPT and Gemini for several weeks produced bigger and bigger comparison charts, and none of them made the choice faster. What did was cutting the decision to three questions and ignoring everything else until they were answered.

1. Where does this task already live? A document, a spreadsheet, an inbox. The tool built into that environment usually wins on convenience alone, before quality enters the conversation.
2. What does a bad first attempt cost? If it is cheap to fix, speed wins. If it is expensive to unwind, a slower, more careful tool is worth the wait.
3. Does this need pushback, or does it need output? Ambiguous work benefits from a tool that asks questions first. Well-defined work just needs something fast.

Three honest answers beat a twelve-row comparison chart, because the chart answers questions nobody actually asked.

A rough map, not a ranking

The best tool is rarely the "smartest" one. It is the one already where the work is.

Does the ecosystem rule hold?

The author's day-to-day work runs through Microsoft 365, so Copilot got most of the attention by default. To test the rule, the same handful of tasks went through Gemini for a few weeks. The finding was that the two are closer in quality than expected, and the difference shows at the edges, not in the middle of a task.

• Inside a Google Doc, Gemini had less friction: comments, suggested edits and version history stayed native, the same advantage Copilot has in Word.
• Inside a Sheet, asking Gemini to explain or rewrite a formula in place beat exporting the data elsewhere, mirroring what Copilot does in Excel.
• Switching ecosystems mid-task cost more than the quality gap between the tools. Moving a document from Google to Microsoft just to use a preferred assistant wasted more time than it saved.

The exception is long, reasoning-heavy writing. Neither ecosystem tool matched a purpose-built assistant working outside any document. The in-place advantage holds for what the ecosystem tool was built to help with, not for everything that happens to sit in that ecosystem.

When two tools can both do the job

Some tasks could go to either Copilot or Claude. Here the useful question is which tool fails more usefully when it gets things wrong.

• A draft that needs heavy editing anyway. Copilot's quick draft inside the document saved a round trip. The editing was happening regardless, so speed to a rough start won.
• A draft where a structural mistake is costly. Claude's slower first pass caught structural problems before they were baked into the document, which mattered more than the extra minute.
• Genuinely ambiguous instructions. Claude asked more clarifying questions before committing. Copilot tended to just produce something. When the ambiguity was the real problem, the tool that pushed back was more useful.

For short, low-stakes tasks such as an email reply or a quick rewrite, the difference disappeared. Some tasks reward being wrong fast. Others punish it.

If you are choosing for a team

Every rollout conversation eventually reaches "which tool should everyone standardise on?" It is the wrong first question. Teams that started there ended up relitigating the choice each time a new model appeared. Teams that started elsewhere did not. Ask these first:

• Where does the team's work already live? A team in Microsoft 365 gets more from Copilot on day one than from a technically stronger tool that requires leaving the document.
• Which failure can the team least afford? A team that ships fast and iterates can tolerate a confident but wrong first draft. A team sending anything to a regulator or client without review cannot.
• Who needs to be convinced? The rollout that sticks is the one the sceptical senior person actually uses, and that depends more on fit than raw capability.

Once those are settled, tool choice stops being trivial. Two tools that are both good enough can still differ in cost, security posture or admin controls. That is a real decision, but it is the second one. Standardising before agreeing how the team will work only moves the argument from "which tool" to "why isn't everyone using it properly."

Where the map breaks down

None of this holds for hard judgment calls with no clean factual answer. Every one of these tools will produce a confident-sounding answer to an unanswerable question. For a legal question, a financial one, or a decision that affects someone else, get a second opinion from a person. The three questions pick a starting point. They do not outsource the decision.

What to do next

• Write down the three or four tasks you do most, and note for each where it lives and what a bad first attempt would cost.
• Assign the default tool for each task by its home environment, then change it only after a real task goes badly.
• For a team, hold the workflow conversation before the tool conversation, and name the failure the team cannot afford.
• Include the sceptical senior person in the first trial, and ask them what would make the tool unusable.
• Keep a second-opinion rule for legal, financial and people decisions, whichever tool you use.