When a client asks 'why not Copilot?', don't compare models

Picture the second demo. Your agent has just run without a hitch, and someone on the client side speaks up: the company already pays for Copilot for every employee, so how is this different?

If you answer by arguing about which model is smarter, you will almost certainly lose. The person asking voted for a large purchase, and nobody wants to hear they bought the wrong thing. Nor is the question hostile. It is the most reasonable thing a budget holder can ask.

So don’t try to win an argument. Your job is to show precisely which work the existing tool already handles, which it doesn’t, and where your piece fits.

The problem is not the model

MIT’s GenAI Divide study, as reported by Fortune, argues that enterprise AI pilots fail mainly because of a “learning gap” in both tools and organisations, not because of model quality. General-purpose tools stall because they don’t learn from workflows or adapt to them.

That is exactly where the FDE comes in. OpenAI describes its FDEs as people who sit with customers to build, deploy and iterate on AI solutions, according to ZenML’s summary of a talk by Colin Jarvis. What you bring is not a better model but an understanding of a specific workflow, turned into software.

Tensoria, a company that builds custom AI solutions, observes that Copilot is very good at summarising, drafting and rewriting. It recommends a split: Copilot handles support functions, while a custom solution handles the core workflow. That is the view of a party with a commercial interest, but the split is clear enough to test on the spot at the client’s site.

Three questions before you say anything

Microsoft provides a framework you can reuse. Its lifecycle for building Copilot plugins starts by defining the work to be done, who will use the plugin and where they will use it. Those are the same three questions to ask when a client wonders “why not use what we already have”.

Ask what the work is, to separate generic writing tasks from business processes. Ask who does it, to learn whether the real users are general office staff or an operations team with its own workflow. The question of where they do it is the one most often skipped, even though it decides the form your solution takes.

Then check the data. Credal, another company with a commercial interest, argues that Copilot only integrates with data inside the Microsoft 365 boundary. Don’t repeat that as fact; treat it as a hypothesis to test on the client’s tenant: does the workflow data live in SharePoint, in Outlook, or in an entirely different system?

One more test is data sovereignty. According to Tensoria, the first case where a custom solution clearly beats a SaaS tool is when the client demands data sovereignty and won’t compromise. If the client requires that data never leave a particular infrastructure, the conversation changes completely.

A worked example, end to end

Picture an insurance company. The whole company already has Copilot. You are brought in to help the claims team, where each claim must be checked against the policy, scene photos and the customer’s history before approval.

Apply the three questions. What work: deciding whether a claim is approved, rejected or needs more documents, according to the exact terms of each policy type. Who: claims adjusters, not office staff in general.

Where: they communicate over Teams and Outlook, but policies and claims history sit in the company’s own policy management system.

The answer falls out. Drafting an email asking a customer for more documents is something Copilot does well, and you should say so plainly. Checking claims against policy terms using data outside Microsoft 365 is the part that needs you.

Now comes the most important step: you don’t build a new application that makes adjusters open another tab. Microsoft defines a Copilot plugin as an installable package that bundles capabilities for a specific job. That package can contain a declarative agent, skills, connectors and connection details for an MCP server, while the server itself runs separately outside.

So you write an MCP server that reads the policy system, host it on infrastructure the client permits, and package the claims agent as a plugin. Adjusters keep asking questions in Copilot as they always do. Ramp describes this approach as meeting customers inside the tools they already use, rather than forcing them into an entirely new workflow.

A script for the demo might run like this:

Client: We already have Copilot. How is this different?

FDE: Copilot remains where your team works, and it’s drafting claims emails very well. What it can’t yet do is check claims against the terms in your policy system, because that data isn’t in Microsoft 365. This part of the solution will run inside Copilot as a plugin, so adjusters don’t need to learn a new tool.

Client: Why not let our IT team build it?

FDE: That works, and your IT team will take over the handover and carry it forward. The question is who can measure whether this agent is learning the claims workflow correctly in the first three months.

That last answer deserves attention. According to the MIT research, buying tools from specialised vendors and building partnerships succeeds in about 67% of cases, far more often than building in-house. But the same figure is a reminder not to promise to build everything from scratch.

Five steps in one table

Step	Question	Output needed
Define the work	What work, who does it, where?	A one-page workflow description in the users’ own words
Map the data	Is the data inside or outside Microsoft 365?	A list of data sources, with external ones flagged
Check constraints	Is data sovereignty required?	A decision on where the server lives
Split the work	Generic writing or core workflow?	What goes to Copilot, what the custom solution handles
Choose the form	Where do users already work?	A plugin in Copilot, or a clear reason to stay outside

Mistakes that lose you the client

The most common mistake is running down Copilot. You may be technically right and still embarrass the person who signed the contract, and they will defend their decision by dropping you.

Next comes pulling out model benchmarks. If the real gap is learning the workflow, winning a benchmark answers none of the client’s questions.

Just as dangerous is quoting vendors’ claims as if they were fact. Credal and Tensoria both sell competing solutions, so use their points as a checklist, then check them in the client’s real environment.

Finally, there is pushing users onto a new interface when they already live in Teams and Outlook. A more accurate agent that nobody opens is still a failed pilot.

A skill worth putting on your CV

When reading FDE job ads, look for phrases such as Microsoft 365 extensibility, MCP or integration with the client’s existing systems. They signal that the company needs someone who can place a solution inside an ecosystem the client has already bought.

On your CV, don’t just write “built agents for clients”. Write that you identified the work the existing tool couldn’t do, then integrated the solution into that same tool. That sentence shows a hiring manager you understand both the technology and the client’s internal politics.

This week’s exercise: pick a workflow at a client you’re working with, write a five-sentence answer to “why not use what we already have”, and read it aloud to a colleague playing a difficult CIO. If any sentence mentions the model, rewrite it.