This document is a decision checklist for a company with one concrete AI problem and four ways to get it done: a consultancy, contracted developers, a platform or a forward deployed engineer. It compares the four on what each is accountable for and what you keep when it ends, then gives eight questions to ask any provider before you sign.
1. The gap this decision has to close
McKinsey's 2026 survey (1,719 respondents across 97 countries, published August 25, 2026) reports that nearly nine in ten organizations use AI in at least one function and 44% are scaling it across the enterprise, while 37% report any effect on earnings, a share unchanged from the year before. 80% of respondents say AI improved their own productivity. The 6% McKinsey calls high performers did one thing the rest did not: they redesigned workflows rather than inserting AI into existing ones, nearly three quarters of them against one quarter of everyone else.
Inside an IT department, or a SaaS company whose backlog grows faster than its team, the gap has an address. The mandate is real, the individual gains are real, and nobody on the team can take one process from request to production and then operate it. The decision in this document is about who closes that gap, and the wrong answer is the one that leaves the gap where it was with a vendor's logo on it.
2. Four options, compared on what matters after the engagement ends
| Consultancy | Contracted developers | Platform | Forward deployed engineer | |
|---|---|---|---|---|
| Accountable for | A recommendation, a roadmap, sometimes a pilot | Hours and tickets delivered | The tool working as sold | The outcome in production, inside your systems |
| Who writes the code in your repository | Nobody, or a separate implementation team | They do, to your specification | The vendor's, in their system | They do, with your team, to a spec written together |
| Who decides how to solve it | You, after reading the recommendation | You, ticket by ticket | The vendor, within the product | The engineer, with your owner, after discovery |
| Who operates it in production | Your team, from a handover | Your team, from a handover | The vendor, for a fee | Your team, after operating it beside the engineer |
| What you keep when it ends | A document | Code you specified | A subscription | Code, spec, tests, pipeline and a person who can run it |
| Where it fails most often | Implementation never happens, or happens without the authors | Nobody owned the result; the spec was the problem | Integration with your real systems and data | Postings that carry the title and describe a different job |
The Pragmatic Engineer's deep dive of August 12, 2025 draws the line this way: consultants make one off recommendations, forward deployed engineers work with the customer long term, write code on the customer's infrastructure with the customer's tooling and are measured by impact on the customer's goal. Vinoo Ganesh's guide of February 5, 2026 adds the buyer's view: after decades of software bought and never properly deployed, enterprise buyers are starting to demand implementation guarantees, engineers on site who own the deployment and not just the sale.
3. The eight questions
Ask these of any provider, including an internal team. Write the answers down before the decision.
- What is the observable result, in one sentence, that will define done? If the answer is a deliverable (a report, a pilot, a license) instead of a change in a process you can measure, you are buying an input.
- Who does the discovery, and where? Sitting with the people who run the process today, reading the systems and the data as they are. A proposal written without that has scoped the wrong problem more often than not.
- Who writes the spec, and where does it live? In your repository, approved by your owner, with acceptance criteria a test can check.
- Who writes the code, and where does it run? In your repository and your environment, or in the provider's. This decides what you keep.
- What passes before code reaches production? Tests, security analysis, review. If the checks are not in your CI, they leave with the provider.
- Who handles the first incident? The provider, beside your team, or your team from a document.
- Who on your team will operate it, and when do they start pairing? A name and a date before day 60, not a handover on the last day.
- What do you keep if the engagement ends tomorrow? Code, spec, tests, pipeline, handbook, and a person who has run it. Anything less is a dependency.
4. How to tell the real role from the relabeled one
The Pragmatic Engineer reported on March 26, 2026, citing The Wall Street Journal, that postings for forward deployed engineers on Indeed grew more than tenfold in 2025 compared with 2024, while about 10% of the engineering market wants the job. The engineers who took it and left describe why: the work was integrating what a product team had already built, closer to the deal than to the code, with nothing contributed back. One left after four weeks.
A buyer faces the same relabeling from the other side. The test is the answers to questions 3, 4 and 8. A real forward deployed engagement puts the spec and the code in your repository, runs the checks in your CI, and ends with your people operating the system. A relabeled one delivers the provider's product configured for you, with your team trained to use it.
5. When each option is the right one
A consultancy, when the decision itself is the problem: which processes, in which order, with what budget, and you have a team that can execute once it is decided.
Contracted developers, when the spec exists, is good, and the only thing missing is hands; someone on your team owns the result and reviews every change.
A platform, when the problem is generic enough that a product solves it as sold, the integration with your systems is documented and tested, and you accept operating it as a dependency.
A forward deployed engineer, when the problem is specific to your systems and your data, nobody on your team can take it from discovery to production, and you want to keep the result and the ability to run it. That is the case McKinsey's numbers describe for most companies: the mandate exists, the individual gains exist, the redesigned workflow does not.
6. What we do
On our own engagements, discovery is done inside the client's systems and ends with the one sentence result approved by the client's owner. The spec and every line of code live in the client's repository from day one. The agents that write the code do not open a pull request until the client's gates pass, and the gates are in the client's CI. Someone from the client's team operates the system beside us before we leave, and what stays is the code, the spec, the tests, the pipeline and that person. We answer the eight questions in writing before an engagement starts, because they are the questions we would ask.
Questions and answers
When is a consultancy the right choice for an AI problem?
When the decision itself is the problem: which processes, in which order and with what budget. It works if you already have a team that can execute once the decision is made. If nobody on your side can take the work to production, a recommendation tends to stay a document.
When are contracted developers enough?
When a good specification already exists and the only thing missing is hands. Someone on your team has to own the result and review every change. If the specification was the real problem, contracted developers deliver exactly what was asked and the outcome still does not arrive.
When is a platform enough?
When the problem is generic enough that a product solves it as sold, the integration with your systems is documented and tested, and you accept operating it as a dependency of the vendor. It fails most often at the integration with your real systems and data.
How do you tell a real forward deployed engagement from a relabeled one?
Look at three answers: who writes the specification, who writes the code and where it runs, and what you keep if it ends tomorrow. A real engagement puts the specification and the code in your repository, runs the checks in your CI and ends with your people operating the system.
Sources
- McKinsey, The state of AI in 2026: On the road to ROI, August 25, 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- The Pragmatic Engineer (Gergely Orosz), What are Forward Deployed Engineers, and why are they so in demand?, August 12, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- The Pragmatic Engineer (Gergely Orosz), Is the FDE role becoming less desirable?, March 26, 2026, citing The Wall Street Journal. https://newsletter.pragmaticengineer.com/p/is-the-fde-role-becoming-less-desirable
- Vinoo Ganesh, The Definitive Guide to Forward Deployed Engineering, published by Next Play, February 5, 2026. https://nextplayso.substack.com/p/the-definitive-guide-to-forward-deployed
Analysis and conclusions by yaab, based on the published reports listed above.