Building AI agents in-house: outsourcing, FDE, or AI + RPA

The AI agent a contractor built is live. A few months later, the AI model it uses gets a retirement notice. A business partner’s site changes its screens. An internal rule changes. Each time, you get a quote and wait your turn for the change, and the work goes back to being done by hand.

AI agents need fixing long after they are built. So when you choose between outsourcing, an FDE (forward deployed engineer), and building in-house, what matters is less how fast it gets built than who can fix it, and how fast. This article compares four ways to build AI agents, and covers the real challenges of bringing them in-house and how to choose.

The short answer: choose by how fast it gets fixed, not how fast it gets built

• AI agents are never finished: AI models retire, model versions behave differently, and screens and business rules keep changing
• Judge each option by who can fix a change, and how fast: don’t choose on build speed or cost alone
• Use FDEs or outsourcing to get started or for hard integrations: settle the handover and how the engagement ends before you sign
• Make processes that change often fixable by the staff who know them: together with a way to record why things were fixed, who approved what, and what runs where

AI agents are never finished

Three kinds of change follow the build.

Change	Example	What to do
An AI model retires	Anthropic gives at least 60 days’ notice, and requests fail after retirement. On October 14, 2026, OpenAI notified developers that GPT-4o, GPT-4.1, and other models leave the API on January 14, 2027	Move to a replacement model, and test it on the work before switching
Behavior differs between model versions	OpenAI explains that even different snapshots in the same model family can produce different results	Pin the version, and compare results on the same inputs when you change it
Screens or business rules change	A business partner’s site is updated, a form gains a field, an approval threshold changes	Fix the steps or prompts, and rerun what stopped

Anthropic advises thorough testing of replacement models on your own tasks well before the retirement date. OpenAI also advises building tests and evaluations that measure prompt behavior, for when you change model versions.

Japan’s AI Guidelines for Business (version 1.2), from the Ministry of Economy, Trade and Industry and the Ministry of Internal Affairs and Communications, likewise expect organizations to track external changes, such as new technology or new regulations, re-evaluate in time, and improve their AI systems and how they run them.

The changes themselves can’t be avoided. What matters is who can fix things when they come, and how fast. Why automation stops when screens change is covered in Why RPA bots break when screens change, and how agents left unfixed fall out of use in AI agent failures: 5 reasons agents fall out of use.

Four ways to build AI agents

1. Outsourcing (contract development)

You give requirements to a systems integrator or development firm, and they build it. Changes after launch fall under a maintenance contract or a fresh quote each time.

2. FDE (forward deployed engineer)

The vendor’s engineers work in the customer’s environment, directly with the customer, to build and deploy the solution. Palantir pioneered the role, and it has spread with AI. In Japan, too, Nikkei xTECH reported that four major IT companies plan to expand their FDE teams, with Hitachi aiming for 1,000 in Japan within fiscal 2026.

3. Engineers in-house

Your own engineers build it with AI model APIs and development frameworks. It gives the most freedom, but you need to hire the engineers and set up how it will be run after launch.

4. Staff build with AI (AI + RPA)

The staff who know the work put the steps together by talking with an AI assistant, and AI learns screen operations and repeats them. This covers automating internal business processes. How AI and RPA fit together is covered in AI agents vs RPA: when to use which, step by step.

The four compared

	Outsourcing	FDE	Engineers in-house	Staff build with AI
Who builds	The contractor	The vendor’s engineers (with your team)	Your engineers	Your business staff
Getting started	After requirements and a contract	Fast	Fast, if you have engineers	Takes as long as staff need to learn
One change	Request, quote, rework, acceptance	Fast during the engagement; afterward, your team or a contractor	Fast once an engineer is free	Staff fix it on the spot
How you pay	For each build and each fix	For the time engineers are engaged, often at a premium	Engineers’ salaries	The tool and staff time
What stays in-house	The working system	Depends on the handover	The system, and engineers who can build	The system, and staff who can fix it
Suits	Work that won’t change soon	Work needing deep product knowledge or complex integration	AI built into your own products or services	Internal processes that change often

For actual costs, see What outsourcing automation costs: hand-off vs guided.

What tends to go wrong with FDEs and outsourcing

In September 2026, Gartner predicted that by 2028, 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineering, trapped by soaring costs and unable to evolve it on their own. It notes that customers may see faster early progress but fail to build internal capability, and end up paying premium rates for work that, once the scope is clear, a traditional services model could deliver more cost-effectively.

In the same release, Gartner predicts that through 2028, fewer than 20% of FDE engagements will turn recurring customer needs into capabilities in the vendor’s core product. It also warns of “FDE washing”, where consulting services are marketed as FDE.

Gartner doesn’t dismiss FDE, though. It advises using FDE only for problems that require deep product expertise, rapid adaptation, or close integration between the vendor’s technology and your environment. Before signing, set the deliverables, knowledge transfer, intellectual property rights, and exit. Then execute the exit you planned, rather than extending the engagement because your teams aren’t ready. Success, it says, is measured not by finishing the implementation but by whether the enterprise can manage, optimize, and scale the technology itself.

With outsourcing, too, once a change goes beyond the maintenance contract, you wait for a quote and the rework. Either way, the same things are worth checking.

What to check:

• Who owns what was built (code, prompts, settings, evaluations)
• What is handed over, and by when (documents, procedures, how to fix it)
• Whether you or the contractor holds the AI model’s API account. Retirement notices go to whoever holds it
• Who fixes it when a model retirement notice arrives after the engagement ends

The real challenges of building in-house

The challenge is people. In JUAS’s IT Trends Survey 2026, the challenges companies named in bringing system development in-house were a shortage of developers (52.7%), a lack of developer skills (49.6%), a shortage of project managers (44.4%), and a lack of understanding of current business processes (38.2%) (fiscal 2025, 953 companies). In IPA’s DX Trends 2026, too, the top challenge in adopting and running AI was “a shortage of specialists” (50.1%).

In the previous year’s report, JUAS observed that companies hold back from building in-house because they don’t understand their current processes well enough, leave the work to their existing vendors, and so fail to build up knowledge internally.

That is the hard part of building in-house. Engineers are scarce and may not know the business. The staff who know the business can’t write code. For automating internal processes, AI can close that gap: staff describe the steps in the language of the work, and AI puts them together and learns the screen operations.

But if only the person who built it can fix it, building in-house ends up worse than outsourcing. You need a way to keep the reasons for each fix, record who approved what, and see everything that runs in a ledger (Taking over an RPA bot whose builder has left, How to build a robot ledger for RPA, with a template).

What to check:

• Who knows the processes that change often, and whether they have time to fix things
• Whether what they build stays fixable by someone else if they move on
• Whether there is a procedure for comparing results on the same inputs when you change models
• Whether a person approves before operations that are hard to undo

How to choose

1. Internal processes that change often, with staff who know them: staff build with AI
2. AI built into your own products or services, or complex system integration: engineers build in-house. If you use an FDE to get started, decide the exit first
3. Work that won’t change soon, or with no one to own it: outsource with a maintenance contract
4. Mixing is fine: in JUAS’s survey, too, what companies mainly aim for is a mix of in-house work and outsourcing

Example: when a model retirement notice arrives

Retirement notices go by email to whoever holds the AI model’s API account. If the contractor holds it, your team may not even notice. Here is what happens after the notice arrives under each approach.

Approach	Who fixes and tests	What you wait for
Outsourcing	The contractor	A quote, a slot for the rework, acceptance
FDE	The FDE during the engagement; afterward, your team or a contractor	If the engagement has ended, a new contract or a handover
Engineers in-house	Your engineers	An engineer with time
Staff build with AI	Your business staff	Only the time to test the replacement model

Every approach needs time to test the replacement model on the work. The difference is whether contracts or waiting lists come between testing and fixing.

Frequently asked questions

How is an FDE different from a systems integrator’s engineer on site?

An FDE is the vendor’s engineer placed in your environment to fit the vendor’s technology to it. Gartner points out, though, that some providers market implementation or consulting as FDE. Look less at the title than at whether the contract covers who owns what is built, the handover, and the exit.

Can business staff build AI agents?

For automating internal processes, yes. Describe the steps in the language of the work, and AI puts them together. Deciding how to handle exceptions and where to place approvals goes faster at first with someone experienced. AI built into your own products, where design decisions pile up, is engineers’ work.

How do we bring an outsourced AI agent in-house?

Start by listing what runs where, and move the ones that stop often or change often first. The steps are in RPA migration steps. Before you move anything, check in the contract who owns what was built and what documents are handed over.

Keep fixing it with Kitewell

Descarty’s Kitewell is AI RPA that AI builds and AI fixes. Business staff build by conversation, and fix by conversation.

• Build and fix by conversation: ask the assistant, and it shows the change and a preview of the flow. Nothing is saved until you choose Apply, and Undo takes it back
• Change a model in one place: AI models are registered under Agents & models, and workflows refer to the registration. When a retirement notice arrives, change the registration, and every workflow that uses it follows. Test model confirms the new model answers
• Learned operations survive a model change: screen operations that worked are remembered and repeated without AI. They are not tied to a model, so changing the model does not mean relearning them
• AI says why a run stopped: with failure diagnosis on, the first failure in a streak is sorted into Try again, Needs you, Workflow change, or Unclear, with the cause and the next step. Fix it from Fix in editor, choose Save and continue, and the run carries on from the failed step
• Test before production: test steps one at a time, compare an earlier version in Edit history and choose Restore this version. A release is a frozen copy of a project’s workflows that you apply to another project, and applying an older release rolls back
• Knowledge keeps the reasons: what each workflow is for, the rules it follows, and what broke and how it was fixed are kept, and the assistant reads them before every answer
• Fixes reach the whole team: with projects synced through Dagu Cloud, workflows and knowledge someone fixed reach every computer
• See everything in a ledger: export a robot ledger to Excel
• AI agents as steps: fifteen AI agents, including Claude Code and Codex, run as steps in a workflow. Send the work back and the agent tries again with your comments

Descarty’s support is not FDE. In the PoC, Descarty builds the workflows together with your team to prove the effect. In production, your staff build and fix the workflows by talking with Kitewell’s assistant. Build support helps you choose what to automate and design exceptions and approvals. Under an enterprise plan, maintenance support finds why a run stopped when the AI could not fix it, and checks each update against your workflows. What you build, and the ability to fix it, stay with you from the start.

You can start by choosing one process a contractor fixes for you, or one that changes often, and verifying it with us as an early access partner. See Early access partners for details.

Summary

• AI agents need fixing after launch: models retire, versions behave differently, and screens and business rules change
• Choose between outsourcing, FDE, and in-house by who can fix a change and how fast, not by how fast it gets built
• If you use an FDE, set the handover and exit before signing, and carry out that exit
• The challenge of building in-house is people. For internal processes, staff who know the work building with AI makes up for both the shortage of engineers and the gap in business knowledge
• Whatever the approach, keep the reasons for fixes, the approvals, and a ledger of everything that runs

Sources

• Gartner: Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028 (September 29, 2026)
• Anthropic: Model deprecations
• OpenAI: Deprecations
• OpenAI: Prompt engineering
• Ministry of Economy, Trade and Industry and Ministry of Internal Affairs and Communications: AI Guidelines for Business, version 1.2 (March 31, 2026; in Japanese, with a tentative English translation). Responding to external change is action goal 6-1 in the appendix
• Palantir: Forward Deployed Software Engineer, New Grad - Commercial
• Nikkei xTECH: Four major IT companies keen to expand FDEs; Hitachi aims for 1,000 in Japan within fiscal 2026 (August 17, 2026; in Japanese)
• JUAS (Japan Users Association of Information Systems): IT Trends Survey 2026, report briefing (April 10, 2026; in Japanese). The challenges of bringing development in-house are on page 38
• JUAS: IT Trends Survey Report 2025 (in Japanese). Bringing system development in-house is section 8.2
• IPA (Information-technology Promotion Agency, Japan): DX Trends 2026 (July 30, 2026; in Japanese). The challenges of adopting and running AI are figure 3-16