FDE vs agency vs in-house: how to choose an AI implementation partner

Picture a managing director with three proposals on her desk for the same problem: a sales team drowning in manual CRM updates and a pipeline nobody trusted. An agency offered a six-month programme with a discovery phase. A recruiter offered a shortlist for an in-house AI engineer, at roughly four months to start. A solo engineer offered to sit with the team for six weeks and build the thing in place. The proposals are not really competing on price; they are competing on who will own the system a year later.

That is the question this article tries to answer. Choosing an AI implementation partner is a decision about scope, speed, ownership and cost structure, and the three options, forward deployed engineer (FDE), agency and in-house team, trade those four things off in different ways. We run the FDE model at Tugam, so we have an interest; the framework below is written to be useful even if you conclude that one of the other two is right for you.

Why the choice of AI implementation partner matters more than the choice of model

Most AI projects fail on integration, adoption and ownership rather than on the model, which is why the partner you choose determines the outcome more than the technology does.

The evidence is consistent. MIT's NANDA initiative found in 2025 that 95 percent of organisations were getting zero return from an estimated $30 to 40 billion of generative AI investment, and that the core barrier was not infrastructure or talent but "learning": systems that do not retain feedback or adapt to context. Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value.

The same MIT report contains the finding that matters for this decision: pilots built through external partnerships reached full deployment 67 percent of the time, against 33 percent for tools built internally. Outside help doubled the odds, not because outsiders are smarter but because they arrive with patterns from previous deployments and with no stake in the internal politics of the project. McKinsey's 2026 State of AI survey of 1,719 respondents adds the other half of the picture: nearly nine in ten organisations use AI somewhere, 44 percent say it is scaling across the enterprise, and only 6 percent qualify as high performers. Three-quarters of that 6 percent have fundamentally redesigned workflows; one quarter of everyone else has.

The three options, described honestly

An agency sells a team and a process, an in-house hire sells permanence, and a forward deployed engineer sells speed and a handover; each is the right answer to a different question.

The agency

An AI or automation agency brings a bench: a project manager, one or two engineers, a designer, sometimes a data scientist, organised into phases with a statement of work. Its strength is capacity and predictability on well-specified projects. Its weaknesses are the discovery phase that precedes any building, the account-management layer between you and the engineer, and the fact that the system often lives in the agency's tooling and habits. Clutch's directory of AI development firms shows the most common pricing band at $25 to $99 per hour with minimum project sizes of $10,000, rising to $100 to $149 per hour for specialised boutiques. The right use: a large, well-defined build with a clear specification, or a company with no internal owner at all.

The in-house hire

An in-house AI engineer knows your data, your people and your politics, and stays after the launch. That is the strongest possible ownership. The costs are time and salary: Glassdoor's estimate for an AI engineer in the Netherlands is a median total pay of €67,000 a year, with a range of €49,000 to €87,000, before employer costs, tooling and the three to five months a hire typically takes. The harder problem is that one engineer alone has nobody to learn from, and a company that has never run an AI system cannot easily judge whether the hire is good. The right use: an organisation that has already shipped a first system and now needs someone to own and extend it.

The forward deployed engineer

The forward deployed engineer model comes from Palantir, whose engineers "embed directly with our customers to configure Palantir's existing software platforms to solve their toughest problems" and focus on enabling many capabilities for a single customer rather than one capability for many (Palantir, 2020). OpenAI stood up its own forward deployed team in 2024 and Anthropic is expanding its applied group; The New Stack reports an 800 percent rise in FDE job postings between January and September 2025. An anonymous FDE quoted there put the job precisely: "The model is usually the cleanest part. The hard part is finding the workflow nobody documented, the data source people actually trust, and the person who knows why the process works that way."

Applied to a mid-sized company, the model means one senior operator-engineer who sits inside your team for a fixed period, builds in your systems and your accounts, trains the people who will run it, and leaves. Its strengths are speed, direct contact with the work and a clean handover. Its weaknesses are real: it depends heavily on one person, it does not scale to a twelve-month, ten-workstream programme, and if your team has no one able to inherit the system, the handover lands on nobody. The right use: a growth or operations system that needs to be live in weeks, in a company with at least one person who can own it afterwards.

The proposals are not really competing on price; they are competing on who will own the system a year later.

Four criteria: scope, speed, ownership and cost structure

The decision comes down to how bounded the scope is, how soon the result is needed, who must own the data and systems afterwards, and whether you prefer to pay per hour, per month or per outcome.

Scope. A bounded system, such as an outbound engine, a CRM rebuild, a reporting layer or an AI agent for one workflow, suits an FDE. A programme of many parallel workstreams suits an agency. An open-ended mandate to "make us an AI company" suits nobody; it needs to be cut into bounded pieces first.

Speed. An FDE typically ships a first working system inside six to eight weeks because there is no discovery phase separate from building. Agencies usually quote three to six months with a discovery phase up front. An in-house hire is three to five months to start, then a further period to learn the business.

Ownership. Ask where the code, the prompts, the data pipelines and the vendor accounts will live on the day the engagement ends. In the FDE model the correct answer is "in your accounts, from day one". With agencies, check whether the system is built inside your tenancy or theirs, and whether you can leave without a migration. With an in-house hire, ownership is total but concentrated in one person.

Cost structure. Agencies bill by the hour or by phase, so scope creep is paid for by you. In-house is a fixed annual cost whether or not there is work. An FDE is usually a fixed monthly retainer or fixed-scope fee, which is why it is the option that replaces a payroll rather than adding to one.

What to ask in the first call

The first call with any prospective AI partner should establish who will do the work, where it will live and what happens when they leave; the answers separate serious vendors from sales decks.

1. Who exactly will be building, and how many hours a week will that person spend inside our team? Ask for the name.
2. Which accounts will the code, the prompts and the data live in on day one, and will we hold the administrator credentials?
3. Show us a system you built that the client now runs without you. What broke in the first month after handover?
4. What is the first thing you would ship, and by what date? A vendor who cannot name a week-two deliverable has not thought about your problem.
5. Which of our people will need to own this afterwards, and how many hours of theirs will you need each week?
6. What will you not do? A partner with no boundaries has no method.
7. How is the price structured, and what happens to it if the scope changes in week three?

A scoring table for the decision

Score each option from 1 to 5 against the six criteria below, weight the criteria by what your situation demands, and let the total guide the shortlist rather than decide it.

The pattern the table shows is the honest one. If ownership and continuity dominate, hire. If breadth dominates, engage an agency. If speed and a clean handover dominate, and you have one person who can inherit, the FDE model wins. Many companies sequence them: an FDE to ship the first system and train the eventual owner, then a hire to extend it.

What we do at Tugam

Tugam runs the forward deployed model for growth systems: one operator-engineer builds and runs outbound, CRM, automation, reporting, market entry and partnership infrastructure inside the client's team, in weeks, and hands it over.

The engagement follows the Tugam Growth Engine. Enrich: in the first two weeks we audit the data you already have, connect the CRM, and build the account and contact layer with signals. Personalize: we set up the AI-assisted, human-reviewed messaging and the prompts that generate it, in your accounts. Branch: we design the persona- and behaviour-based sequences and the automations (n8n, the Claude API, Google Workspace) that route each reply. Deliver: we run the system with your team for the remaining weeks, build the reporting, document everything and leave. The founder has done this before as an employee: administering one HubSpot instance across a 60-plus office network, delivering CRM implementations for retail, hospitality and financial-services clients in the Gulf, and building an AI coordinator assistant and automated marketing operations for a global tourism group. Instead of hiring a ten-person marketing and sales team, a company gets one person and a system its people keep running.

A 90-day plan for choosing and starting

1. Weeks 1–2: write the problem as a workflow, not a technology. Name the people who touch it, the systems it lives in and the number that should change.
2. Week 3: decide whether the scope is one bounded system or a programme. This alone eliminates one of the three options.
3. Week 4: name the internal owner. If there is none and none can be trained, the in-house route or a longer agency contract is more honest than an FDE.
4. Weeks 5–6: hold first calls with two vendors of each remaining type using the seven questions above; score them on the table.
5. Week 7: negotiate ownership terms in writing: accounts, credentials, code repositories, prompts and documentation transfer at the end.
6. Weeks 8–12: start with a bounded first deliverable and a fixed date. Measure the number you named in week one, and decide on extension only against it.

If you are weighing these three options for a growth or operations system, we are glad to talk through the scoring with you, including the cases where the honest answer is that you should hire.