From pilot to daily operations

What changes after the pilot

During a proof, the build team watches the agent every day. Volume is limited, a person reviews most outputs, and problems are fixed within hours. Once the agent runs at full volume, all of that has to happen without the build team in the room.

This is where many programmes lose value. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing rising costs, unclear value and weak risk controls. Each of those shows up in operations: costs that creep up with volume, quality that drifts without anyone noticing, and controls that were fine for a pilot and weak at scale.

Running an agent well needs five things in place: an owner, monitoring, evaluation, incident handling and a plan for change.

An owner for every agent

Each live agent has a named owner in the business, as described in Chapter 2. For daily operations, that owner needs two more people behind them, even if one person covers both roles in a smaller company:

• An operator who watches the agent’s numbers, reviews samples, handles user feedback and decides when something needs fixing.
• An engineer who changes prompts, rules, integrations and models, tests the change and releases it.

The owner decides what the agent should do. The operator checks that it does. The engineer changes how it does it.

Monitoring that covers quality

Traditional monitoring asks whether a system is up and fast. An agent can be up, fast and wrong. Monitoring for agents covers four things:

• Volume and speed. Items processed, time per item, queues building up.
• Quality. Share of items approved without change, override rate, and scores from automatic checks.
• Cost. Model usage and infrastructure per item, against the business case.
• Safety. Guardrail triggers, blocked actions, and anything the agent tried and was not allowed to do.

Every call to a model should be traced: the input, the output, the model and prompt version used, the time taken and the cost. Aralab’s invoice agent, from Chapter 3, traces every call this way, so any decision can be checked afterwards.

Evaluation that never stops

Models are updated by their providers, data changes, and new kinds of cases appear. Quality can drift without a single error message. Three practices catch it:

• A standing test set. The real cases with known answers collected during the proof, extended every month with new examples. Every change to a prompt, rule or model is tested against it before release.
• Live sampling. A small share of live outputs is reviewed by a person each week, even in supervise mode.
• Automatic checks. Rules and scoring at each step of the agent’s work, with low scores sent to a person or retried.

A global consumer electronics brand ran a 24/7 AI radio station built by Twistag, where people wrote a dedication and received a song with custom lyrics, audio and album art. Quality scoring ran at every stage. Lyrics were checked for completeness and emotional fit, audio for completeness and genre. Anything below the threshold was retried automatically, so users never received a failed song. Over six months the station generated 700,000 original songs, shared 1.5 million times.

The same pattern applies to back-office agents. Checks at every step, a threshold, and a defined path for what falls below it.

Incidents and the off switch

Something will go wrong. A source system changes its format, a model provider has an outage, or an agent starts producing answers that look right and are not. The plan for this should exist before launch:

• A way to pause. Every agent can be paused, falling back to the manual process or to assist mode, by a named person, in minutes.
• Alerts with owners. Thresholds on quality, cost and volume, each with someone who receives the alert.
• A short run book. What the agent does, what it must never do, how to pause it, who to call, and how to restore it.
• A review after each incident. What happened, why, what was changed, and what was added to the test set.

Change without breaking things

Agents change more often than most software. Prompts are tuned, rules are added, models are upgraded. Each change should follow the same path:

1. Make the change in a test environment.
2. Run it against the standing test set and compare with the current version.
3. Release it to a small share of live volume, or in assist mode first.
4. Watch the numbers for a set period, then roll it out or roll it back.

Model independence makes this easier. The radio station’s pipeline kept each AI service behind its own layer, and Twistag replaced one provider mid-campaign without users noticing. The same design lets a company move to a cheaper or better model when one appears.

Twistag applies the same discipline to its own engineering. In its delivery system, Pulse, every pull request that touches a client environment runs through eight checks in sequence, from spec conformance to security and data safety. A failure stops the pipeline, every override is recorded, and leadership tracks the override rate by check and by team over time.

Scaling the volume

When the agent moves from pilot volume to full volume, three things usually need attention:

• Review capacity. If 20% of items still need review, the review team must handle 20% of full volume. Plan the people, or plan the move to fewer reviews.
• Cost per item. Measure it again at full volume. Caching, smaller models for simple steps and batching often bring it down.
• Edge cases. Full volume brings rare cases the pilot never saw. Route them to a person and add them to the test set.

Common mistakes

• No owner after launch. The build team moves on and nobody watches the agent.
• Monitoring uptime only. The agent is always available and slowly getting worse.
• Changes straight to live. A prompt tweak released without testing breaks a case that used to work.
• No way to pause. When something goes wrong, nobody knows how to stop the agent safely.
• Locked to one model. A provider outage or price rise leaves the company with no options.

What to do this month

1. Name the owner, operator and engineer for each live or near-live agent.
2. Make sure every model call is traced, with cost and version.
3. Turn the proof’s test cases into a standing test set, and run it before every change.
4. Write a one-page run book for each agent, including how to pause it.

Questions for the leadership team

1. Who owns each live agent day to day, and who do they call when something goes wrong?
2. How would the company know if an agent's answers got worse this week?
3. What does each agent cost per item this month, compared with the business case?
4. How long would it take to switch an agent to a different model?
5. How can each agent be paused, and who is allowed to do it?