The Age of Decommission

Keep the power to change course.

When an agent is wrong, the contract question comes back: who owns the loss and the way out?

Agent output feels immediate until it changes a record, sends a message or releases money. Outsourcing contracts already know the unromantic questions that follow: evidence, service failure, exit assistance and data return.

What it feels like

The cold little pause after clicking send for something you did not quite write yourself.

You are not asking for impossible certainty. You are asking for a decision to remain attached to the act that followed it.

You press send on something you didn’t quite write. Then a cold little pause.

The sentence is polite. It’s probably better than the one you’d have sent between meetings. It goes out under your name anyway.

Then a detail is wrong. Or the tone lands badly. Or a promise has slipped into the reply without anybody deciding to make it.

You were allowed to trust a system that arrived labelled approved. Approval is supposed to mean somebody thought about the consequences.

You’ve got customers waiting, messages multiplying, a child to collect, and work that doesn’t get more meaningful by taking longer. Letting an assistant clear one item off the afternoon isn’t carelessness. It’s what a person with a finite day does.

Nothing here has to be sinister to go wrong.

The problem is smaller and much closer.

The moment your assistant’s useful prose becomes a message, a record, or money, an old contract question walks back into the room. What failed? What proves it? Who carries the loss? And what exactly gets handed over when this has to stop?

2006 — Legal wants the signed statement of work before anyone can say what the supplier promised.

2015 — A vendor ticket closes without fixing the incident. The dashboard is green. Your laptop still isn’t.

2024 — The assistant drafts your customer reply. It sounds like someone who had time to think.

2026 — It sends one. The audit trail is suddenly the conversation.

Older than the interface

An outsourcing contract starts from an unfashionable premise. The service will fail, change, and eventually end.

That’s why yours names the service, the term, the evidence, the remedy, the renewal choice and the exit. Not because the supplier is bad. Because a helpful outside capability becomes a dependency, and dependencies need a way to be measured and unwound.

Look at the service-desk deal your employer signed. Five-year term, service levels, service credits, a benchmarking option, exit assistance.

On the effective date your supplier is bound and nowhere near ready. Mobilisation has to move staff knowledge, access, asset records, ticketing connections, security controls and a pile of assumptions. Somebody has to tell you what was accepted, by whom, and what lateness changes.

“Transition complete” isn’t a fact.

That dull sentence matters, because the exit plan starts at the same moment. UK Model Services Contract guidance puts it inside three months of the effective date.

By then you’ve usually found the real service. It was hiding in shared credentials, in monitoring the supplier configured, in a third-party maintenance contract, in the local workaround nobody wrote down.

The exit plan isn’t pessimism.

It’s the first accurate description of what you handed away.

Your agent arrived from the other end. It began with the finished sentence, the cleared case, the faster reply.

The dependency feels like a feature because the boundary is hiding in a browser tab. But once that system can send a message, activate a change or release money, the question isn’t whether its answer was clever.

It’s whether you can still attach a decision to the act that followed.

Green is not a remedy

Outsourcing learned this through service levels. A service level needs a service, a population, a clock, a target, a source system, a calculation method, exclusions, a report and a response to failure.

Take one away and your number becomes an argument waiting to happen. A colour-coded monthly summary isn’t evidence. You want the raw ticket data underneath it.

The public record shows the unglamorous shape of it. For major UK contracts above £5 million, current model guidance normally requires at least three KPIs, assessed and published at least every twelve months. Miss the threshold on half of them in a month and the escalation example lets you retain that month’s whole service charge.

Neither number is a target you should copy. They make one point. A promise exists only alongside a population, evidence, a charge base, and an agreed consequence.

Service credits are a price adjustment for defined underperformance. They aren’t a spell that repairs the service, and they probably aren’t your whole loss.

Your contract separates the ordinary miss from the repeated failure that earns a root-cause analysis and a rectification plan. It keeps your stronger rights alive for fraud, wilful breach, security incidents and persistent failure.

The money back, the duty to fix it, and the right to leave are three different things. You want all three.

That separation is exactly what your agent needs. A reply agent can prepare a draft. A message agent can send it. A payables agent can prepare a supplier bank-detail change and must not release the payment.

Those aren’t degrees of confidence.

They’re different effects. Reading. Proposing. Committing.

The old contract called that scope. Your platform calls it tool policy. Same question underneath: what was the thing allowed to do, and what evidence says it did it?

Approval touches the act

Here’s where the relationship actually changes, and it’s a smaller moment than you’d think.

Your approval record binds an authorized person to a stable proposed act. Action type. Affected resource. The exact arguments, or a hash of them. Evidence. Policy version. Requester. Approver. Expiry.

It permits you four dispositions and no others: approve, reject, request further evidence, or cancel.

And if the supplier record changes while your request waits, your old approval doesn’t authorize the new account number. It authorized the old one.

A message saying “approval requested” is a notification.

A human sitting nearby is not a control.

That’s the correction. You’re not demanding impossible certainty. You’re asking that a decision stay attached to the act that followed it.

A friendly agent makes you sound fussy for asking. It tells you it has completed the change. It gives you a calm summary.

But its message isn’t the transaction.

After your approval, the master-data system hands back a confirmation number, a resulting record version, a timestamp. Those are your evidence.

Your trace holds two linked states. The agent run marked completed, and the record version that proves the external change happened.

One of those is a claim.

The other is the thing that happened.

Failure needs a door

Now the sensation after clicking send becomes practical.

If the action was wrong, it can’t be enough to know the agent once saw some relevant text. You need request identity, source documents, policy and prompt versions, tool inputs and results, the approval, the credential scope, the downstream version, and what recovery did.

And you need the branch that stopped one failure becoming two.

An idempotency key carries that during a timeout. The activation call may have committed before the connection died. So your runtime asks the downstream system with the same key, records the first result, retries safely, or parks the case for you.

It doesn’t fire your action again because the model lost sight of the answer. A timeout is uncertainty.

It must not become a duplicate external act.

The MCP authorization spec makes the same refusal to blur. A 400 is a malformed request. A 401 is missing or invalid authorization. A 403 means you’re recognized and denied.

Those aren’t three flavours of “the agent went wrong.” They’re different faults, with different owners and different recovery paths. The dull precision is the kindness. You can still find where your decision broke.

The old contract refuses to blur in the same way, and termination is where it shows. Nobody throws a file over a wall.

In that service-desk deal your incumbent starts eighteen months out. Refresh the exit plan. Identify assets and licences. Transfer the current ticket data and the knowledge articles. Train your incoming team. Allow shadow operation. Keep serving until cutover.

The replacement validates the data and the assets.

Delivery isn’t acceptance.

The Data Act sharpens the edge for covered services. It wants an exhaustive description of what’s transferable, separating your exportable data from the provider’s internal-functioning data protected as trade secrets. And it gives you at least thirty calendar days to retrieve your data after the transition period ends.

Those two categories don’t excuse your provider from a usable handover. They separate real portability from an automatic claim on somebody else’s internals.

Your agent arrangement deserves the same seriousness, and nobody’s calling it a contract.

What would you actually have to recover? The records. The prompt and policy versions. The audit trace. The credential and access design. The connector configuration. The draft states. The knowledge of which exceptions exist. And somewhere that can operate without this agent.

An export you can’t interpret is a receipt, not a way out.

The loss has owners

Contracts don’t make responsibility pure, and you shouldn’t want them to.

You can delay building access and the supplier still owes you an accurate inventory. A benchmark can compare your actual service bundle without turning a generic competitor price into a meaningful comparison.

UK Mid-Tier guidance keeps benchmarking in optional Schedule 12, service performance in Schedule 10, rectification in Schedule 25. That separation stops your price comparison pretending it has already proved a default.

An agent trace won’t explain your loss away either.

It’ll tell you who approved, which policy permitted, which credential called the tool, what the downstream system returned. It won’t tell you whether the approved policy was wise. Or whether the connector was too broad. Or whether you were pressed into accepting a false choice. Or whether the loss belongs in a credit, a rectification plan, an insurance claim or a liability allocation.

The record makes those questions answerable.

It doesn’t make them go away.

That’s why the question comes back. Not because your agent is a person, and not because every bad output becomes a lawsuit.

It comes back because something is now acting across a boundary, with authority, under rules, with consequences that may need repairing.

You don’t have to fear the helpful draft. You do need the decision, the evidence of the act, and the way out to stay visible after the prose has done its work.

Put this to work

  1. An operable exit plan transfers data, assets, knowledge, access, and a receiving capability rather than merely exporting a file.
  2. A service level is a control only when it defines the service, population, clock, target, source, exclusions, calculation, report, and response to failure.
  3. A valid agent approval binds an authorized approver to the exact proposed act, evidence, policy version, and expiry.
  4. A downstream committed result outranks a model statement as evidence that work completed.
  5. An idempotency key and a recovery branch keep an uncertain timeout from becoming a second external action.
  6. Service credits make defined underperformance financially visible but do not replace rectification, termination, or loss allocation.

Questions

What has to move for an exit plan to be real?
An operable exit plan transfers more than a data export. It identifies data, asset records, configurations, access, licences, contracts, knowledge articles, and the people or receiving team able to use them. It also defines format, security, completeness checks, correction, acceptance, and deletion or retention evidence. A replacement provider can require staged read-only access before live control, because delivery of a file is not proof of a usable transfer.
Why does an exit plan exist before anyone wants to leave?
An exit plan exists while the service is being mobilised because the parties are still discovering shared credentials, supplier-owned configurations, third-party maintenance contracts, and undocumented local workarounds. UK model guidance says the plan should be created within three months of the effective date. A live plan protects continuity when expiry, termination, financial distress, or a replacement decision turns a theoretical handover into active work.
What makes a service level an actual control instead of a dashboard?
A service level is an actual control when it identifies the service, population, clock, target, source system, calculation method, exclusions, report, and response to failure. The supplier supplies operating evidence and the customer can validate or dispute it. A percentage without a denominator, source data, exception rule, and remedy produces a later argument about the dashboard rather than an enforceable promise.
Do service credits decide who carries the whole loss?
No. Service credits are mechanically calculated deductions from charges for specified underperformance. They make routine failure financially visible and can require management attention, but they are often smaller than the customer’s actual loss. A mature agreement separately addresses rectification, persistent failure, fraud, wilful breach, confidentiality or security incidents, liability claims, insurance, and termination. Those mechanisms allocate different consequences.
Why is a model saying it completed work not enough?
A model message describes a result; it does not prove that an external system committed it. For an agent changing supplier bank details, the authoritative evidence is the downstream confirmation number, resulting record version, and timestamp. The trace links the completed agent run to that changed record. This distinguishes a fluent completion message from a completed transaction and makes later audit or recovery possible.
What makes an approval record valid for an agent action?
A valid approval record identifies the action type, affected resource, exact arguments or proposal hash, supporting evidence, policy version, requester, authorized approver, and expiry. It records approve, reject, request for further evidence, or cancel as distinct dispositions. If the source record, proposed arguments, or policy changes, the old approval no longer applies. A notification that approval was requested is not an approval gate.
Why do agents need separate rules for reading, drafting, and committing?
Read-only retrieval can disclose information but does not alter a record. A proposal creates a reversible draft. A commit changes a business, legal, or physical state. Each effect therefore requires different authority and checks. A policy engine independently evaluates the tool name, arguments, resource, principal, state, budget, and current approval before execution; a model instruction alone does not provide that boundary.
What stops a timeout from sending the same action twice?
An idempotency key lets the downstream system recognize a retry as the same operation rather than a new one. When activation times out, the runtime first queries the downstream system using that key. It then records the existing completion, retries safely, or parks the case for an operator. Blind retrying can turn uncertainty about the first call into a second committed action.
Why are 400, 401, and 403 different kinds of agent failure?
A 400 response means the tool request is malformed. A 401 response means authorization is absent or invalid. A 403 response means the service recognizes the caller but denies the requested permission. These are different failures of request construction, credential validity, and authority. Treating them as one generic agent failure loses the recovery path, alert, and ownership needed to correct the problem.
What does the Data Act distinction mean for an exit?
For covered EU data-processing services, the Data Act requires an exhaustive description of transferable categories, including exportable data, and separately identified internal-functioning data exempted to protect trade secrets. The two-category distinction supports a genuine switch without automatically requiring transfer of protected provider internals. The agreement still needs to state delivery format, security, verification, and the receiving party’s acceptance test.
How much time does a customer have to retrieve data after a covered service ends?
For covered data-processing services under the EU Data Act, a customer has at least 30 calendar days to retrieve data after the agreed transition period ends. That minimum does not make every operational transfer complete in 30 days. A service desk or agent environment can require longer staged assistance for records, access, assets, licences, knowledge, and receiving capability.
Why is a contract benchmark not a fresh procurement exercise?
A contract benchmark compares the service bundle already committed: support hours, languages, volumes, locations, security requirements, transition age, and other stated assumptions. The UK Mid-Tier Contract treats benchmarking as optional Schedule 12. Its outcome follows the agreement’s stated consequence, such as discussion, an efficiency plan, market test, or price adjustment; it does not erase the existing scope or invent a new procurement.