Three months after a successful launch, the service catalogue changes. A system permission expires. The person who understood the original workflow moves to another role. The AI still responds when someone opens Teams.
Who is keeping its work correct?
That question belongs in the buying decision. A Digital Employee performs a defined business responsibility inside an organisation that will continue to change. Its operating conditions include information, permissions and human decisions that cannot be frozen at procurement.
Somebody must maintain those conditions. The responsibility can sit with the customer, the provider, an implementation partner, or a combination of them. The arrangement should be visible before a successful trial becomes a recurring commitment.
Capability has moved forward
Buyers now have credible alternatives to assembling every workflow themselves. Microsoft describes Copilot Cowork in terms of multi-step work, business context and approval checkpoints. OpenAI’s workspace agents extend shared, long-running work across teams. These are vendor descriptions rather than an independent comparison, but they make a simple point: the market already offers systems that can act and operate within organisational controls. Microsoft and OpenAI describe their respective capabilities.
Configurable platforms also address supervision. Relevance AI documents approval and escalation mechanisms for its workforces. Buyers should evaluate how such mechanisms fit their responsibility, rather than assume that approval support distinguishes one category of product from another. Relevance AI’s documentation gives a concrete example.
The purchasing question therefore becomes more specific. Which parts of this business role will the supplier operate, and which parts must the customer continue to run?
An interface demonstration rarely answers that in full.
The work continues after configuration
Take a hypothetical Digital Employee preparing corporate healthcare proposals. Its original scope covers standard packages and routes commercial exceptions to a sales manager.
When the provider introduces a new package, somebody must decide whether it belongs inside that scope. The approved information must be updated. Representative cases should establish whether the change affects existing behaviour. If the new package requires a different approval, that decision route must be reflected in the work.
A model update raises a different question. The language may improve while a previously reliable extraction becomes less consistent. The company needs a way to detect the change and determine whether the new version is acceptable for the role.
Access failures are different again. They can stop work without changing the model or its instructions. The operator needs to distinguish a temporary system outage from a revoked permission and avoid repeated actions that create duplicate records.
Calling all of this “maintenance” hides the allocation of judgement. Some decisions belong to the business owner. Others belong to whoever operates the service. The contract and operating process should agree about the boundary.
Put the responsibilities on one page
This proposed matrix shows an allocation a buyer could negotiate. It is not a statement of Outcome1.AI’s current service commitments. A real agreement must name organisations and people, define its hours of coverage and price the scope.
| Responsibility | Accountable party in this example | Required contribution and evidence |
|---|---|---|
| Define the role and acceptance | Customer business owner | Approves the permitted work, exceptions and acceptance cases. Provider documents the implemented scope. |
| Maintain business sources | Customer source owner | Publishes approved changes and resolves contradictions. Provider maintains the agreed ingestion and change checks. |
| Maintain integrations | Provider or named partner | Detects failures, preserves safe retry behaviour and tests interface changes. Customer maintains its own system access and licences. |
| Grant and review permissions | Customer system owner | Authorises access. Provider records the role’s actual access and supports removal when scope changes. |
| Evaluate releases | Provider, with customer acceptance for material changes | Runs agreed cases, records results and provides a reversal route. Customer decides changes to business authority. |
| Handle operating exceptions | Named service owner | Routes each exception to an accountable resolver, tracks age and escalates missed response targets. |
| Manage incidents and recovery | Provider service lead with customer incident owner | Supplies impact, containment and recovery records; confirms which business cases need correction. |
| Support exit | Provider with customer successor owner | Supplies agreed exports and transition support, with format, timing, exclusions and fees stated. |
For each row, ask two further questions: what response is included, and what causes an additional charge? A service may include routine source updates but charge for a new market or a redesigned integration. That can be reasonable. Ambiguity is the problem.
One accountable party per responsibility does not mean one party does every task. It means the customer knows who must bring the work to a resolution.
Test the service with a change
A useful procurement exercise is to introduce a realistic change during the trial.
For example, remove a permission the role needs. Observe who notices the failure and how the affected work is contained. Establish what the customer must do next. Ask for the record that would accompany the change in ordinary operation.
The exercise should be agreed and safe. Its purpose is to expose the operating arrangement while the buying team can still evaluate it.
A provider may respond with a mature process. Another may offer excellent tooling but expect the customer’s team to execute that process. Both can be viable choices. The buyer needs to compare the full arrangement, including the competence and time required internally.
The best answer may differ by role. A strategically distinctive process may justify an internal team, while a bounded responsibility may be better served through a provider with repeatable operating experience.
Internal ownership can be the right choice
Building internally is a serious option when the organisation has the relevant people, access and appetite for continuing responsibility. It can preserve control over unusual workflows and shorten the distance between a business decision and its implementation.
The comparison should include the internal team’s ongoing work: evaluation, integration changes, incident response and the knowledge that must survive staff turnover. It should also recognise what the organisation gains by building that capability. Treating internal effort only as a cost misses the strategic value of learning.
Buying can reduce that burden, but only for duties the supplier actually accepts. A licence with configurable controls and a managed responsibility are different commercial offers. Neither label guarantees the quality of the result.
The same discipline applies to service breadth. No provider can remove the customer’s obligation to define its commercial policy or authorise consequential decisions. A credible operating model makes those retained duties manageable and explicit.
Buy the responsibility you can sustain
The Frontier has argued that a Digital Employee must learn without drift. That principle needs an owner, a routine and a budget after the first release.
For Outcome1.AI, the standard is demanding: describe the role, explain the continuing service and demonstrate how the arrangement handles change. Claims about business capacity should survive the departure of the person who ran the initial demonstration.
Before signing, a buyer should be able to answer an ordinary operational question: when this role stops producing acceptable work on a busy Tuesday, who takes responsibility for restoring it, and what will the business have to contribute?
The answer is part of the product being bought.