Operating expenditure
AI Agent Maintenance Cost
Price the work needed after launch: failure review, source upkeep, dependency changes, release checks and incident support. Includes a monthly effort ledger and retainer questions.
An agent can keep answering while its business service quietly deteriorates. A carrier changes a status code, an access token expires, a dispatch policy is revised or a source stops updating. The interface may remain available even though the information is wrong or the intended action no longer completes. Maintenance pays for detecting, diagnosing and correcting those changes.
For an operations manager, the useful question is not “What percentage of the build price should support cost?” It is “Which recurring responsibilities must be staffed, at what service level, and who pays for exceptional changes?” A percentage can be a temporary planning shorthand. It cannot tell you whether a retainer covers an urgent integration failure or merely includes a few hours of prompt editing.
Follow a freight-status agent through an ordinary month
Consider an illustrative agent that prepares shipment-status explanations for a freight service desk. It reads approved carrier events and internal exception notes, identifies what is known and drafts an answer. A service employee handles missing events, disputed delivery and compensation. The agent does not invent an arrival time or make a compensation decision.
During a month, one carrier adds an unfamiliar event, another delays its feed, the operations team changes an escalation contact and a reviewer reports that an Arabic abbreviation is being misread. These are four different maintenance jobs. They require different owners and different evidence of completion. Counting them all as “four prompt updates” would hide most of the work.
A useful service record says what changed, which tasks were affected, how the issue was contained, what was corrected and which regression cases now protect the behaviour. It also identifies the business owner who confirmed the correct interpretation. Maintenance cannot determine a disputed commercial policy on behalf of the organisation.
Separate five types of work in the contract
| Type | Example | Commercial question |
|---|---|---|
| Corrective | An agreed carrier event is mapped incorrectly | Is this a covered defect, and for how long after acceptance? |
| Preventive | Check feed freshness, permissions and recovery procedures | Which recurring activities and evidence are included? |
| Adaptive | A carrier changes its API or the model version must move | Is compatibility work included, capped or separately estimated? |
| Content upkeep | An approved escalation rule or service policy changes | Who approves the source and who updates and retests it? |
| Enhancement | Add a new carrier or a customer-facing channel | Does this require a new scope, price and acceptance gate? |
The contract should resolve borderline cases before they become incidents. If the delivered agent never supported scanned proof-of-delivery documents, adding them is an enhancement. If it mishandles an agreed supported document in the acceptance set, the defect clause may apply. The actual contract determines the obligation; the category names alone do not settle it.
An effort-based monthly estimate
The following example uses invented hours and rates in SAR. It demonstrates a budgeting method, not a market rate or an Open for AI support offer. Assume a limited business-hours service, a stable release and a small number of documented integrations. Human review of daily shipment enquiries remains with the service desk and is outside this technical maintenance ledger.
| Activity | Hours | What should be evidenced |
|---|---|---|
| Service health and failure investigation | 10 | Investigated alerts and recurring-failure actions |
| Sampled outcome and language review | 8 | Labelled cases, disagreements and corrected tests |
| Access and security upkeep | 6 | Permission changes, credential rotation or patch records |
| Dependency review | 4 | Provider notices and compatibility decisions |
| Approved source updates | 8 | Versioned changes and source-owner sign-off |
| Recovery exercise | 4 | Restore or rollback evidence and unresolved actions |
| Release checks and reporting | 6 | Regression results and service-owner review |
| Total planned effort | 46 | At an assumed SAR 300/hour: SAR 13,800 |
Now suppose an incident adds four hours at an assumed SAR 350/hour, and a separately approved mandatory migration adds 20 hours at SAR 300/hour. The illustrative month totals SAR 13,800 + SAR 1,400 + SAR 6,000 = SAR 21,200. Infrastructure, model consumption, daily business review and tax remain excluded. A retainer might absorb some of that work or charge it differently; compare its terms with the same activity ledger.
Do not turn this single month into a universal annual ratio. A new service may need more stabilisation, while a mature restricted workflow may require less routine change. Track several actual periods, identify the recurring baseline and retain a separately justified provision for material dependency changes. Connect this evidence to the broader ownership-cost model.
Budget for dependencies that have their own lifecycle
Amazon Bedrock documents model lifecycle states and directs customers to model-specific retirement terms. Microsoft Graph distinguishes production and preview API support, including different change expectations. These examples show why a dependency register should record the actual model, endpoint, SDK version, provider notice channel and owner. They do not imply identical policies across providers.
For a planned migration, allow time to run the existing acceptance set, inspect changed tool behaviour, measure latency and cost, and confirm the fallback. A newer model is not automatically an approved replacement. A cheaper one might alter how often shipment identifiers are confused or how much review an Arabic answer needs. The acceptance criteria should travel with the workflow, not disappear when a component changes.
If a dependency is already unsupported or its production suitability is unknown, record that explicitly. A small monthly retainer cannot compensate for an architecture built around an unstable capability with no replacement path. Use the architecture guide to identify boundaries that make components replaceable.
Service coverage can cost more than the repair itself
A four-hour repair and a promise to respond at any hour are different services. Around-the-clock coverage requires availability arrangements even when few incidents occur. Define the covered hours, time zone, severity levels, acknowledgement target, containment target and escalation contact. Specify whether weekends, public holidays and named business peaks are included.
Do not confuse response with resolution. A provider can acknowledge a ticket promptly while waiting for a carrier to restore its feed. Agree what the agent should do during that period: display the last verified event and its timestamp, suspend claims about current location, and route affected enquiries to a controlled fallback. Such containment can preserve service integrity even when the dependency remains unavailable.
Describe how multiple incidents are prioritised and whether unused hours expire. Ask who can authorise emergency expenditure and what happens after the included allowance is exhausted. The pricing-model guide helps distinguish a capacity retainer from an outcome guarantee or an unlimited change service.
Use monitoring to find work, then close it properly
A dashboard is not maintenance completion. An alert should produce an owner, investigation and decision. For the freight workflow, track feed age, unresolved identifier matches, unavailable tools, repeated retries, unsupported event codes and accepted handoffs. A low average response time can conceal a rising queue of unanswered difficult shipments.
Review samples from both routine and exceptional requests. Include Arabic and English separately where their distributions differ. If the team only reviews complaints, quiet failures may remain invisible; if it only reviews easy successes, it cannot learn from the paths that consume support time. The monitoring and observability guide describes the evidence needed to investigate a task across its components.
Close an issue only when the corrected behaviour is demonstrated and the recurrence mechanism is addressed. A temporary carrier-specific rule may need an expiry date. A source correction may require rebuilding an index or invalidating cached answers. Record those operational steps in the ticket, not just the final wording of the response.
Test whether a maintenance ticket is really finished
Take the unfamiliar carrier event from the example. First quarantine the event from customer-facing conclusions, while retaining its original code and timestamp for investigation. Ask the carrier or approved business source what the event means. Confirm whether it changes the shipment state or merely adds a note. The integration owner can then update the mapping, and the service owner can approve the wording customers may see.
The completion evidence should include the new event, the previous event and an out-of-order arrival. Otherwise, the correction may work on a clean example while incorrectly moving a shipment backwards when delayed messages arrive. Add an Arabic request containing the shipment identifier and a mixed-language carrier description if those inputs are supported. Check that an old cached answer is invalidated where necessary and that affected open cases are identified for review.
Record the effort by diagnosis, business clarification, implementation and verification. If similar event changes recur, a better mapping mechanism may be cheaper than repeated urgent patches. That decision depends on the recurring workload and the cost of the proposed improvement. It should not be justified simply by a large count of closed tickets. This is how a maintenance ledger becomes a source of engineering priorities, rather than a monthly list of activity.
What a good monthly service review should decide
- Which recurring failures justify engineering work rather than repeated manual correction?
- Which source owners missed update obligations, and how will the workflow behave until they respond?
- Which dependencies create a dated migration decision?
- Which costs rose because volume increased, and which rose because the agent required more attempts or reviews?
- Should any authority or use case be reduced until its quality is restored?
The review should leave a short funded action list, an updated forecast and clear accepted risks. It should also recognise when the workflow is stable enough to reduce unnecessary checks. Maintaining everything at launch intensity indefinitely can waste resources just as surely as providing no operational ownership.
Open for AI’s AgentOps service and agent development work can be discussed in terms of the service responsibilities your project needs. Bring your dependency list and one month of redacted incident and usage data to scope maintenance around actual work, expected coverage and a clear change boundary.