When the client has already hired Accenture or Deloitte, the FDE owns "done"

You arrive at your first kickoff with an enterprise client and find you are not the only technical person in the room. Across the table sits a team from Accenture or Deloitte, with a signed SOW, a timeline and its own project manager. The first question that comes to mind: so what am I here for?

This situation is increasingly common. When OpenAI launched its Frontier platform on 23 February 2026, consultancies such as Accenture and Capgemini joined as partners, working alongside OpenAI’s FDE team. Earlier, in December 2025, Accenture and Palantir formed a joint business group, built on more than 2,000 Accenture staff skilled in Palantir.

Working alongside a systems integrator (SI) has therefore become part of the FDE craft, no longer a matter for the sales side alone. Done well, it lets you lead the technical work without doing all of it yourself.

Done badly, one of two things happens: you become the SI’s ticket-answering service, or their rival inside the client’s office.

Two teams, two meanings of “done”

At first glance the division of labour looks clear: the SI builds and integrates, and you are the one who knows the platform best. But the two sides are scored against different yardsticks.

According to Webfuse, the scope and method of a consulting engagement are fixed in advance by the SOW, consultants are judged on completion against that scope, and the consultancy tracks utilisation.

FDEs, by contrast, are judged on real production usage and measurable impact on workflows. Entrans, a company that sells FDE services and should be read as offering a point of view, says the work is only done when the system actually delivers the intended business outcome. Success is not measured by conventional SLAs such as uptime or API latency either.

The space between those two milestones is often signed off by nobody.

Forgepoint Capital explains why that gap is hard to close by contract: quality in AI projects is very hard to write into clauses. If the two sides cannot even agree on what good looks like, it asks, how can they agree on the deliverables in an SOW?

That is an opinion, not a measurement. But it explains why the hardest parts to define, including evals, agent behaviour and handling model errors, tend to land on you even when the contract says nothing about them. Nick Johnston of Salesforce puts it bluntly: the agent era will be decided by business outcomes, not by pilots.

None of this makes the SI the slower party. In August 2026 Deloitte announced it was putting FDEs directly into its solution delivery teams on a Salesforce project. SD Times also argues that FDEs complement rather than replace traditional consultants, filling the places where they are weaker. Job titles matter less than the question of who is accountable for what.

A worked example: an agent for insurance claims

Suppose the client is an insurer that wants an agent to read claims files and recommend approval or referral to a human reviewer.

The SI’s SOW defines “done” as the agent integrating with the claims management system and passing a UAT of 20 scenarios. The client wants simple claims automated, on condition that the agent is right at least 95% of the time.

Now do the arithmetic. The agent passes all 20/20 UAT scenarios, because they are all happy-path cases. But when you run it on an eval set of 200 real, anonymised claims, it gets only 170 right, or 85%. Under the contract the project is finished; the outcome the client needs has not been reached.

Nobody here did anything wrong. The SI delivered exactly what was signed; the contract simply measured the wrong thing. Your job is to spot that gap in the first week, not discover it on go-live day.

The first tool is a responsibility matrix, completed before anyone starts writing code:

Area	SI	Vendor FDE	Client
Integration with the claims system, authentication, internal data	Primary owner	Advises on API limits	Grants access
Eval suite and the 95% threshold	Runs it in CI	Designs it, owns its quality	Labels data, approves the threshold
Agent design, model error handling	Implements	Primary owner	Confirms business rules
Platform limits and upcoming changes	Informed	Primary owner	Informed
Post-go-live operations runbook	Primary owner	Co-writes, co-rehearses	Approves

Each row has exactly one primary owner. The second row is where you lead: the eval suite becomes the shared acceptance document, and the SI team runs it on every change. That way, “done” by contract and “done” by business outcome end up being the same thing.

Raising the gap without stepping on toes

How you deliver the 85% figure matters as much as the figure itself. A script for the weekly meeting might go like this.

You: “UAT has fully passed, and your team’s integration work is very solid. We’ve just run another 200 real claims and got 85%, against a business target of 95%. The shortfall is mostly in the agent’s behaviour, which is our side’s responsibility.”

SI lead: “So does that affect our timeline?”

You: “Not for the integration. I’d just suggest adding these 200 claims to your CI so every build reports a score. We fix the agent, and you see the results straight away.”

The exchange does exactly three things, in order: it credits the work the SI did well, it takes ownership of the gap, and it proposes a shared mechanism, running the evals in CI, instead of blaming anyone.

Steps from week one

First, ask to read the SI’s SOW, or at least the scope and acceptance clauses. Write down in one sentence what “done” means under it, then compare that with the outcome the client actually needs. The gap between those two sentences is your work plan.

Next, draw up the responsibility matrix and ask the client’s tech lead to confirm it. Once the client has agreed, the SI will not feel you have assigned yourself a role.

Then build the eval suite from real data and propose it as the shared acceptance criteria. An FDE playbook published on dev.to advises defining “working” with a measurable number before writing production code. If quality is as hard to put into a contract as Forgepoint suggests, a runnable eval suite is the closest thing to a quality clause.

After that, set up a short weekly session with the SI engineers on the platform: its limits, its behaviour under failure and the changes coming up. This is knowledge only you have, and sharing it early often saves both sides days of debugging.

Finally, prepare the handover from the start. The same playbook describes what an FDE leaves behind as a running system, plus the organisation’s ability to operate it on its own.

When the SI will take over operations, write the runbook with them and rehearse an incident: the SI engineers handle it while you only observe.

Three traps that cost FDEs their role

The most common trap is treating the SI as a rival. In the client’s office, both teams win or lose together, and the view that FDEs complement consultants is the one to bring into the meeting room.

Another trap is quietly doing the SI’s work for them to speed things up. When progress is slow, impatience comes easily. But code you write on their behalf is code nobody knows how to run on the day you leave the project.

The hardest trap to see is keeping platform knowledge to yourself so that you seem indispensable. You are paid so that the client and the SI can run the system themselves, not so that they need you forever.

If you are interviewing for an FDE role at a technology vendor, ask directly how often you will work alongside integrators or consulting partners. The answer tells you which skills you will use every day.

On your CV, be specific: which eval suite you turned into shared acceptance criteria, and from when the SI team ran the system on its own.

Next time an SI sits beside you at a kickoff, don’t ask what you are there for. Ask how the contract defines “done”.