Putting it in service

Once the software acts on live cases, one question matters as much as accuracy: whose is it. Where it runs, who holds the keys, where the record of each case is kept. A pilot on the builder's platform is convenient. There is nothing to provision, and the builder fixes problems quietly. The convenience becomes a problem later, when the builder changes its prices, is acquired, or loses the engineer who built it, and you find that the prompts, the rules, the case set and the history of what the agent did all sit in an account you cannot open.

Owning it means four concrete things. The code, prompts and rule files sit in a repository your organisation controls, with its full history. The deployment runs in your own cloud account or on your own servers, under your billing. Model access runs on your own contract, so usage per case, the provider's retention terms and the bill are visible to you. And the record of every step, what was read, which rule applied, what was done, is written to storage you control, under your own retention rules. A builder can still operate the agent for you, in your accounts, with access you grant and can withdraw.

Give the agent its own service identity, never a borrowed staff login, and only the permissions its actions need. If it raises credit notes up to a limit, it cannot approve payments, and it cannot read payroll because payroll happens to sit in the same database. Instructions steer what the agent tries to do; permissions decide what it can do when it misreads a case. Keep secrets in your own secret store and rotate them on your schedule. Decide in writing which fields may leave your perimeter, and mask what the task does not need: matching an invoice to an order does not need the supplier's bank details.

Handover is documentation written for the person on call in eighteen months, not for the builder. It needs a runbook: how to stop the agent, how to send its cases back to people, how to restore the previous release, how to reverse each kind of action it takes. It needs a catalogue of the rules, each linked to its written source and its owner. It needs the known-outcome case set, with its results for every release. Architecture notes help the next builder. The runbook is what gets used at two in the morning.

The test of ownership is an exit drill, run before go-live rather than at the end of the contract. Ask your own team, or an independent party, to redeploy the agent into a clean environment from your repository, using only the documentation and your credentials, and to run the known-outcome case set against it. If they reach the same results, you own it. If they need a call with the builder to find a missing setting, you have found the gap while it is still cheap to close.

The riskiest day for an agent is the first day it acts on live cases. Everything measured until then was measured on past cases, and live traffic brings what the case set did not hold: a new supplier format, a month-end spike, a system that answers slowly at nine in the morning. A staged rollout exists to meet those surprises while each one is still small, and to make every step one you can take back. Each stage answers one question, and the next stage starts only when the answer is written down.

Start with environments. You need at least two: a test environment connected to test copies or sandboxes of the systems the agent acts in, and production. They use separate credentials, so a test run can never write to the live ledger. Configuration has the same shape in both and moves from test to production by a recorded release, never by someone editing production by hand. If a system has no test copy, say so early: the actions the agent takes in that system stay attended until they can be tested safely.

Then shadow mode. The agent runs on live cases as they arrive, reads everything, decides, and writes down what it would have done, but acts on nothing. People keep doing the work. Every day, compare its proposed outcome with what people did and read the disagreements one by one. Some are agent errors. Some are the agent being right and a person being rushed. Some expose a rule nobody had written down. Shadow mode costs compute and reading time, and it is the only stage that tests live traffic without live consequence. An unread shadow log has tested nothing.

Then partial volume. Let the agent act on a defined slice: one entity, one supplier group, one case type, or a fixed share of arrivals routed at random. Random routing gives a representative mix; routing by entity or type confines a failure to one team. Either works if it is written down and every case's handler is easy to identify. Everything outside the slice stays with people. Widen in steps, and make sure each step brings in case types the previous slice lacked, because results only speak for the cases the slice contained.

Before each stage begins, write its exit criteria and its stop conditions: the outcome quality on sampled cases, the highest acceptable exception rate, the longest a case may wait, the cost per case, and the minimum time at that level. Write down who may stop the rollout at any hour the agent acts, and the exact step they take. Criteria written after the results arrive tend to fit the results. A rollout that has stepped back once and then moved forward again is working as intended.

Standard monitoring tells you the service is up, how fast it answers and how many errors it throws. All three can look perfect while the agent books every eighth invoice to the wrong cost centre. An agent fails differently from ordinary software. It keeps running, it returns plausible results, and the error surfaces weeks later as a complaint or an audit finding. Uptime says it is running; only a checked sample says it is right. So the monitoring has to cover outcomes, not only the machinery.

Four numbers carry most of the signal. Outcome quality on sampled cases: each week a person checks a random sample of completed cases against the written rules and records correct or incorrect, with a reason. Exception rate: the share of cases routed to people. Queue age: how long the oldest case in each queue has waited, against the time it must be settled by. Cost per case: model calls, steps and review minutes per completed case. Track each one by case type as well as in total, because a steady average can hide one supplier group failing every time.

Read movements in both directions. A rising exception rate usually means the input changed: a new form, a new response from a system. A sudden fall deserves the same attention, because an agent that stops abstaining may have stopped noticing what it used to catch. Queue age matters more than queue size: forty cases two hours old are fine, four cases nine days old may already have missed a payment date. A steady rise in cost per case with no release behind it usually means retries, loops or longer inputs.

Each alert needs a threshold chosen on purpose, a named person who receives it, and a first action written in the runbook: pause the agent, send cases to people, check the upstream system. An alert nobody owns is noise, and noise trains people to ignore the next one. Keep alerts few. Send slow trends to a weekly review, and keep out-of-hours calls for what cannot wait: a queue close to its deadline, actions failing in a target system, cost running away. The sampled check is a control like any other, so it needs an owner and a deputy.

On-call for an agent rarely requires an engineer who can diagnose the fault at night. It requires a person who can do two things at any hour the agent acts: stop it, and send its cases back to the people who did the work before. Diagnosis can wait for the morning; a growing pile of wrong actions cannot. If the agent acts at night and nobody can stop it until staff arrive, either it stops acting at night or someone is on call. Decide which in writing, before the first night.

An agent's behaviour is set by more than its code. It depends on the model version, the wording of the prompts, the rule tables, the definitions of the tools it can call and the thresholds that decide when it abstains. Change any one and the behaviour moves, sometimes far from the edit. One word in a prompt can change how the agent reads a date. A rule added for one supplier can change how it matches everyone else's invoices.

So ship them as one thing. Each release carries a number and pins the exact model version, prompts, rules, tool definitions and thresholds, stored together in your repository. Nobody edits a prompt or a threshold in production, including through a settings screen. The record of every case notes which release handled it, so a complaint in March can be traced to the configuration that decided it in January. Model providers update and retire versions on their own timetable: pin the version you tested, and treat their change as a release you test like any other.

Before every release, run the known-outcome case set: the past cases with verified outcomes you built before the agent existed, plus every failure found in live running since, each added with its verified outcome. Compare results with the current release case by case, not by headline score. A release that fixes twelve cases and breaks three has not improved by nine; read the three, because they may be the expensive kind. Keep the results on file with the release number. As the case mix shifts, add verified recent cases and keep the old ones.

Rollback has two halves, and plans often cover only the first. The first is the configuration: returning to the previous release should be one rehearsed step that takes minutes, which means the previous release stays deployable and nothing in the data has changed in a way it cannot read. The second is the actions already taken. Rolling back does not reverse the forty credit notes the faulty release raised this morning, or the letters it sent. For that you need the per-case record of what was done and a written reversal procedure for each kind of action, including a correction to each person affected where an action cannot be recalled.

Rehearse both halves before you need them. At a quiet hour, roll production back to the previous release and forward again, and reverse a handful of test actions using the written procedure. Time each step and put the times in the runbook. Repeat the rehearsal after any release that changes the structure of the records, because that is when the previous release is most likely to stop working. A rollback nobody has practised is an assumption, and assumptions tend to be tested during incidents.

The business case was written with estimates. After a few months in service you have real figures, and they rarely match. The number that settles whether the agent earns its place is the cost per completed case, counted in full: model calls including retries, hosting and storage, the minutes people spend on routed cases and on the weekly sample, and the time spent keeping the rules and the case set current. Divide by cases completed, not cases received, or the cases that fell back to people make the agent look cheaper than it is.

Cost per case drifts upward for mechanical reasons. A longer prompt adds cost to every call. A new tool adds steps. A model change may change the price per call. A case that fails and retries is paid for twice, and inputs grow as senders attach more pages. None of this raises an error. Set a ceiling per case, at which the agent stops and routes the case to a person, and a monthly budget with an alert well below it. Review the trend weekly beside the other numbers, because a slow drift never trips a weekly level.

Compare against the right baseline: the same case mix done by people, including the time they spend correcting their own errors, measured the same way. Two distortions are common. An agent that settles the easy cases and routes the hard ones has an average that flatters it, so compare type by type. And review time is a real cost even when it sits in an existing team's budget. A pinned release does not become cheaper by itself; if the cost is to fall, a specific change must make it fall.

Once a year, and whenever a system or a rule changes substantially, run the five candidacy checks again as if the process had just been proposed. The rules must still be written and current, without exceptions piling up in people's heads. The systems must still expose their state, and the licence must still permit automation after the last renewal or replacement. The outcome must still be cheap to check. The volume must still repay the running cost, not the build, which is spent. The owners must still describe the process the same way.

The review has three honest outcomes: keep it, change its scope, or retire it. Narrowing the agent to the case types where it is accurate and cheap is often the right call. Retiring it is not a failure when the process no longer qualifies; it is the check doing its job. Because the code, the records and the known-outcome case set are yours, retiring costs little, and the case set remains to measure whatever replaces it.