A company that wants to run operations with agents is usually offered two options. A vendor sells a platform and leaves integration, evaluations and maintenance to the client. A consultancy builds a custom system and hands over the code at the end. Both options assume the client can take responsibility for the technology.
Many companies have no product function able to track model changes, revise the architecture, maintain integrations and evaluate agents in production. They do not need to create one. A third contract is available: the provider keeps the software and sells the operation performed by that software. That is service as software.
The chain does not evolve as one block
A Wardley map places each component of a value chain in a phase: genesis, custom-built, product or commodity. Each component moves at its own pace. Electricity moved from the laboratory to generation inside factories, then to commercial generators and finally to contracted supply. The phase shapes how each component is obtained.
“Agentic operations” is not one component either. The chain includes models, orchestration, knowledge, business rules, integrations and controls. Applying one sourcing decision to the whole stack hides who must create and maintain each part.
Models are already utility. They are consumed by API and can be replaced when the architecture keeps the model separate from the process. For most companies, training a foundation model creates no operating advantage.
Orchestration is moving toward product. Components for coordinating agents, giving them tools, recording actions and running evaluations are standardising. An operator can buy or replace those components without moving the change onto the client.
The operating layer remains custom-built. The process, its exceptions, permissions, sources of truth and escalation criteria differ between companies. A product cannot contain decisions still known only by the people performing the work. That specificity does not disappear when a platform is purchased.
The FDE mandate matters
Model vendors are already deploying forward-deployed engineers to take their models into production inside customer companies. They can accelerate deployment, but the role has a defined mandate: deploy the stack its company sells. That is not a flaw in the role; it is the incentive the buyer needs to understand.
Lock-in does not require an exclusivity clause. It appears when process rules, evaluations, traces and integrations are expressed through provider-specific components. Changing the model then means rebuilding part of the operation, even if the original connection was an API call.
Arkatai separates those layers. We treat models as utility and evaluate them per task for quality, cost, latency and risk. If that balance changes, we replace the model and rerun the evaluations; the process, its rules, controls and traces remain. The FDE works for the operating result, not for adoption of a catalogue.
Custom describes the deployment, not the ownership
A custom operating layer does not mean that every client must fund and maintain a codebase. It means someone has to work with the actual operation before agents enter production. The relevant questions are who performs that work and who owns the technical lifecycle afterwards.
At Arkatai, a forward-deployed engineer works with the people who know the process, connects systems and codifies rules, controls and exceptions. The firm retains the software and remains responsible for models, agents, evaluations, observability and integrations. The client needs an authorised process owner, not an AI department.
The client contracts an operating capability
With a licence, the vendor is accountable for tool availability and the client for the work performed with it. In service as software, the unit of value moves toward the process: completed cases, cycle time, quality, errors and exceptions. The software stays in the background because the client does not need to operate it.
Adaptation remains part of the service. The FDE incorporates new rules, integrations and controls into the shared system while the Arkatai team maintains the technical architecture. The client does not buy licences, repositories or a technical team; it contracts an operation and retains authority over its business decisions.
The exit is designed at the start
Mapping produces a specific operating architecture: process, rules, exceptions, controls, data contracts, integration specifications and evaluation criteria. That content belongs to the client. It describes what an implementation must do without transferring the Arkatai platform, source code or shared components.
At contract end, the client receives the current operating architecture and the agreed export of its data, results and traces. It can take these to another implementer or use them to build its own software. The exit does not make a new implementation free; it avoids paying again to discover and decide how the operation works.
How this avoids becoming hourly consulting
Every deployment produces two kinds of knowledge. Client rules, data and decisions remain isolated. Repeated patterns — connectors, evaluations, controls and escalation paths — improve the Arkatai core. The FDE does not create a parallel solution that must later be maintained; the field case feeds the shared system.
Arkatai operates that final link. We supply and maintain the workforce; the client directs the process and measures the result. The model is detailed in Arkatai, the practice continues in the essays, and a specific operation can be discussed in Work with me.