# In-house team, consultancy or forward-deployed engineers: how to decide > In-house team, consultancy or forward-deployed engineers: who maintains the AI, owns the operation and fits each delivery model. - Canonical: https://arkatai.com/en/inhouse-consultancy-or-boutique/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: en - Published: 2026-07-18 --- Choosing an AI provider starts with deciding which capability the company wants to keep inside. An in-house team creates and maintains technology. A consultancy executes a project. A service-as-software company delivers an operation through its own platform and uses forward-deployed engineers to adapt it to the client’s context. These are not three sizes of the same supplier. They distribute software ownership, maintenance and accountability for results differently. ## In-house team: control in exchange for a permanent function An internal team makes sense when AI is part of the product, there is a multi-year pipeline and someone can direct and evaluate specialists. The company is hiring architecture, integrations, evaluations, observability and maintenance, not just the first agent version. The first cost arises during selection. If nobody inside has operated agent systems, it is difficult to distinguish a good presentation from an architecture that will support real data, permissions and failure recovery. The first hire may set decisions inherited by everyone who follows. The second cost is keeping the practice current. Models, prices, limits, evaluation methods and risks change. One specialist inside a company without a product function has few peers and an uncertain career path. When that person leaves, the code remains but part of the capability goes with them. As a Chief Product & Technology Officer, I build teams and products with agents because that function already exists and affects the product the company operates. I would not recommend reproducing the structure in a company that only needs to change a few operations. ## Consultancy: scope, team and an end date A consultancy sells a project. It can mobilise dozens of people, coordinate countries, meet complex procurement requirements and integrate systems during a time-bounded programme. That scale fits rollouts, migrations and implementations of defined products. Its economics usually follow billed effort. A partner frames the work and a pyramid of roles executes it through a shared method. When the case requires undocumented rules to be discovered, buyers should verify who attends process sessions and who makes technical decisions. A template can coordinate the work but cannot contain the client’s exceptions. At the end, the client receives deliverables and must decide who will operate what was built. It can buy maintenance, extend the project or create an internal team. If the company did not want a technology function, the project may have postponed the same decision it was meant to avoid. ## Service as software: the provider retains the workforce In service as software, software is not the deliverable. It is the workforce through which the provider delivers the service. The company contracts an operation or capability. The provider retains the platform, maintains the agents and absorbs technical change. The client still has responsibilities. It must appoint a process owner, decide business rules and permissions, open the required sources and review cases that require judgment. It does not need to hire a team to switch models, maintain connectors or run evaluations every week. This model fits processes with volume, a measurable result and enough continuity to improve the system with execution data. It fits poorly when the client wants to own technology that is part of its product, when the process changes without an owner or when the scope is a multinational programme requiring hundreds of people. ## What a forward-deployed engineer does The FDE works between the shared system and the client’s operation. The engineer understands the process, connects sources, turns rules into executable behaviour, defines controls and takes a capability into production. Repeated patterns then feed the core product. This is not staff augmentation. A rented engineer receives tasks from the client backlog and works inside its structure. An FDE preserves the provider’s responsibility for deployment and avoids a fork for each account. The aim is for the shared platform to solve the case, not for hours to accumulate in a separate solution. The role does not need to become a seat inside the client. In Arkatai, the FDE is part of how the system is deployed and evolved. Its scope should be clear: integrate a new need into the shared platform, not become a parallel development team. The FDE title does not guarantee technology neutrality. When the engineer works for a model vendor, the mandate is to take that vendor’s stack into production and adoption forms part of success. It may be the right option when the company has already selected that ecosystem, but the buyer should measure the later switching cost. At Arkatai, the FDE works for the operating result. Models are treated as replaceable components and selected per task through evaluations of quality, cost, latency and risk. Rules, controls, traces and integrations remain outside the model. Changing provider requires reevaluation, not rebuilding the process. ## What the board should ask First, who maintains the system after deployment. An answer that depends on “your future AI team” turns the offer into a tool or a project waiting to be internalised. Second, which components are part of the shared platform and which are created for one client. If every account creates a different codebase, a recurring-service promise may conceal maintenance consulting. The provider should explain how repeatable connectors, evaluations and controls return to the core without mixing client data. Third, how the work is measured. Milestones are useful during diagnosis and deployment. In operation, the measures are completed volume, errors, escalations, cycle time, unit cost and economic effect. [The ROI of AI in operations](/en/ai-operations-roi/) develops that measurement model. Fourth, what happens at exit. At Arkatai, the specific operating architecture belongs to the client: process, rules, exceptions, controls, data contracts, integration specifications and evaluation criteria. At termination, the current version is provided with the agreed export of data, results and traces. The client can take that package to another implementer or build its own software. It does not receive the Arkatai platform, but it does not lose the codified knowledge of its operation either. ## Starting with one operation avoids a blind commitment A service contract should not start with a broad promise based on a demo. First map one process, define the architecture, calculate the business case and test behaviour against representative data. That sequence tests whether the team understands the operation, whether the data is available and whether the result can be measured before scope expands. It is the practical application of [the custom phase](/en/the-custom-phase/). ## Questions boards ask me ### Should we hire a head of AI first? Only if you want a permanent internal function and can evaluate that person. To contract a managed operation, you need a business process owner with authority. The provider supplies the technical capability. ### Does an FDE become another consultant? It can if all value depends on specific work that never returns to the product. Check that patterns feed the platform core. FDE work should reduce future client-specific effort rather than expand it indefinitely. ### When would you choose a large consultancy? For a standard rollout across countries, a fixed-date migration or a programme requiring many coordinated roles. To run a continuing process without creating a technology team, I would evaluate a service-as-software provider. ### What is the main risk of the managed model? Dependence on an operator with limited capacity. Review continuity, data isolation, service metrics and exit terms. Client ownership of the operating architecture reduces the cost of changing implementer, but it does not remove the cost of building and operating another solution.