Automation maintenance without a maintenance contract, and who keeps the agent running

Most automation offers come with a maintenance contract attached: a fixed monthly fee, and in return someone will look after things when they break. We think that arrangement is built the wrong way round. The fee buys availability, and it quietly assumes that somebody on your side notices the breakage and reports it. Automation maintenance is mostly watching, and watching is a job an agent can do. That is why every automation we deliver comes with a maintenance agent, and it is part of the fixed price.

Automation maintenance means noticing changes before they do damage

An agent that reads customer emails and creates orders in the ERP depends on things other people change. The ERP gets an update and renames a field. A customer switches to a new inventory system and sends orders in a different layout. The language model provider retires the model version the agent was built on. A login expires. None of this is a bug in the agent, and all of it needs a response.

The awkward half of these changes is silent. A renamed mandatory field makes the order fail with an error message, which somebody notices the same morning. A new PDF layout, on the other hand, still gets read, just wrongly: the customer number ends up in the purchase order field, and the draft goes into approval with that value. If you first hear about it from the customer, the maintenance has been outsourced to the customer.

What the maintenance agent does

The maintenance agent runs alongside the actual automation and has four jobs:

• Monitoring the operation: whether the agent is running, how many cases it handles, and how many of them land on the review list with a flag.
• Checking the input and output of every interface for changes. If one sender suddenly delivers different fields than before, or the ERP rejects a call that worked yesterday, it reports that before the problem runs through a hundred cases.
• Testing every change against old cases. An adjustment to the code, a house rule or the model is first run against the collection of known cases with known correct results, and only then goes live.
• Supporting the move to a new AI model. Model providers retire older versions, and a new model does not read everything the way the old one did. The switch runs like any other change: against the old cases first, then live.

Whatever the maintenance agent cannot resolve itself goes to the customer's IT as a ticket, with the affected spot and the cases where it showed up. Who then makes the change, your IT or we, is agreed with you up front.

Played through on three changes in one year

The following example is constructed and does not describe a customer. Suppose a wholesaler of fastening technology has its order entry from customer emails automated. The agent reads purchase orders, matches items and customers against the ERP and creates the order as a draft, which the sales office approves. Over the course of a year, three things happen.

The ERP update

The ERP moves to a new version. The delivery date field becomes two fields, the customer's requested date and a confirmed date. The agent's call, which still writes the old field name, is rejected by the ERP. The maintenance agent sees at the output that every draft has failed with the same message since the update. It keeps the affected emails on the review list so no order is lost, and raises a ticket: which call, which field, since when, how many cases are waiting. After the fix, the old cases run through once more. Only then does the agent pick up the waiting emails.

A customer's new order layout

A regular customer replaces its inventory system. Its orders still arrive as PDF, but the customer number now sits where the purchase order number used to be. The agent reads it without stumbling. The maintenance agent sees at the input that this sender's orders have had a different layout for three days and that the purchase order numbers no longer match the usual pattern. The affected drafts get a flag, and the sales office sees why during approval. The reading rule for this customer gets a correction, and the maintenance agent checks it against that customer's old orders before it runs again.

The model is retired

The model provider announces that the version the agent was built on will be switched off on a fixed date. The maintenance agent runs the collection of old cases through the successor model and compares the results field by field. Where the new model reads differently, for instance quantities written out in prose, the house rule gets an addition until the old cases come out right again. Only then does the agent run on the new model, and the sales office does not notice.

What maintenance costs

The maintenance agent is part of the fixed price. There is no operating fee and no subscription. What you pay in operation is the usage cost of the AI models, and the model provider bills that to you directly. The maintenance agent uses compute as well, and that counts too. Each month you see what the automation and the maintenance agent consumed, and nothing else.

Sophera Consulting builds agents for wholesale, logistics and hospitals at a fixed price, with a maintenance agent and a handover to your IT. Which process is the right one to start with, and which interfaces need watching, is what we work out in the free automation check.

The recommendation

Before you sign a maintenance contract, ask the provider three things. Who notices a change to an interface, and when? What is a repair tested against before it goes live? And what does operation cost in a month where nothing happens? If the answer to the first question is "your staff" and the answer to the third is a flat fee, you are paying for maintenance twice: once in money and once in your people's time.