# Buy AI, build it or contract the outcome: how to decide > Buy, build or contract AI as a service: choose according to the operation, available team and responsibility you want to retain. - Canonical: https://arkatai.com/en/buy-vs-build-enterprise-ai/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: en - Published: 2026-07-18 --- “Buy or build” omits a third option made viable by AI: contract the completed work. The choice is no longer limited to a licence versus an owned codebase. A board can buy a tool, build an internal capability or contract an operation performed with software maintained by the provider. The difference is not how much AI each proposal contains. It is who performs the work, who maintains the technology and which outcome each party is accountable for. ## Three different contracts When buying SaaS, the company gets access to a tool. The vendor maintains the common product. The client supplies users, configures the workflow, integrates systems and remains responsible for performing the operation. The contract typically measures seats or consumption. When building, the company funds the software, controls its architecture and creates a team to operate it. It gains technical control while taking responsibility for hiring, maintenance, evaluations, security and integrations. The investment makes sense when the capability is part of the company’s product or a permanent pipeline justifies the team. In service as software, the provider retains the platform and sells an operating capability. Its agents perform part of the work and its team maintains the system. The client supplies rules, data, access and a process owner. The contract moves toward outcomes: prepared cases, resolved requests, detected opportunities or an operation delivered to agreed service levels. All three options may use the same models. Responsibility is what changes. ## Contract the common components AI models are already consumed by API. Compute, storage and much of orchestration are also bought. A company that does not sell models gains no competitive position by training a foundation model. Technical decisions still matter. The architecture should keep the model separate from the process, measure its behaviour and support a provider change when cost, quality or data policy requires one. That work does not need to happen inside the client. In a managed service, the operator absorbs model changes and protects operating continuity. The company should require visibility into cost and data-use rules. It does not need to build a team that tests every new market release. ## Buy product when the process can be standard Email, payroll, accounting, expenses and electronic signatures generally accept a common process. If the way a function is performed does not differentiate the company, adopting some of the product’s assumptions can reduce complexity. The question is what work remains after installation. An agent platform may handle the anticipated path while leaving the client to identify exceptions, create evaluations, integrate systems and monitor daily performance. That is a tool purchase, even if its marketing describes a digital worker. Before signing, ask for a specific list: who configures each rule, reviews failures, changes models, maintains connectors and responds when the process changes? If every answer points to the client, the platform requires a product and technology function. ## Build when owning the capability is the strategy Building makes sense when the software is part of the product being sold, the company already has technical leadership and a team will have work for several years. As a Chief Product & Technology Officer, I develop this capability internally because product and technology are established functions of the business. I would not apply the same decision to a distributor or professional-services firm that wants to change two operations and has no product department. Hiring engineers without the ability to evaluate their architecture creates another dependency: dependence on the first team hired. Agents also change quickly enough to make maintenance a continuing workstream. Owning a repository does not mean the company can operate the system. If nobody can review an evaluation, recover a failure or replace a model, formal ownership of the code provides little autonomy. ## Contract the outcome when you do not want to operate the technology Service as software fits when the process has volume, an observable result and rules that can be specified, but the client does not want to build the technical workforce that automates it. The company-specific layer still exists. Every organisation has its own sources, permissions, exceptions and decision criteria. The difference is where that work lives. A forward-deployed engineer incorporates it into a platform the provider continues to maintain. The FDE does not hand over a parallel solution or fill a client vacancy. The role connects a shared system to a real operation. At Arkatai, we map the process, connect the platform to the client’s systems and operate agents under agreed controls. The firm retains and maintains the software. FDEs incorporate company-specific logic without creating a codebase the client must operate. [The custom phase](/en/the-custom-phase/) explains the model. ## Dependency is not the same as lack of control A service creates dependence on its operator. That should be acknowledged and contracted deliberately. At Arkatai, ownership is separated: the platform, its source code and reusable components remain ours; the client-specific operating architecture belongs to the client, and delivery of its current version is part of the contractual exit. That architecture captures the process, rules, exceptions, controls, data contracts, integration specifications and evaluation criteria. At termination, it is delivered with the agreed export of data, results and traces. The client can take it to another implementer or build its own software. The technical layer will need to be reimplemented, but the company does not have to rediscover how its operation works. Compare the three options using full cost: licences, internal team, integration, human review, maintenance, exceptions and exit. Then measure the process, not technical activity. [The ROI of AI in operations](/en/ai-operations-roi/) starts from the same unit. ## Questions boards ask me ### We have no engineers to maintain agents. Does that rule out AI? It rules out building and operating a platform internally, not using agents. You can buy a simple tool for individual tasks or contract a managed operation. The latter needs a process owner, not an AI department. ### Is service as software just consulting under another name? Not if the provider retains and maintains a shared platform, remains accountable for a recurring service and turns deployment patterns into improvements to the core. If every client receives an isolated project and every improvement requires rebuilding it, the model remains consulting. ### How do we avoid getting trapped by the provider? Agree it before starting. The contract should state that the client-specific operating architecture belongs to the client and define how its current version is delivered at termination, together with the agreed data, results and traces. The relevant portability is the operating knowledge, which enables a change of implementer without presenting a repository that nobody can operate as a false guarantee of autonomy. ### Where should we start? Choose a process with volume, economic impact and an authorised owner. Document its baseline and exceptions. You can then compare a licence, an internal team and a managed service against the same outcome rather than comparing demos.