BLOG · MANAGED SERVICES
Buyers pay for a prototype and then discover that reliability, monitoring and audit have no line item anywhere. Published managed-agent rates run $7,000 to $15,000 a month. Here is what that money buys.
There is a structural gap in how agent work gets sold, and it is not a pricing mistake. It is a category error: buyers are quoted for construction, then handed something that behaves like an employee — which needs supervision, correction, and eventually an owner.
The gap has a market rate. It is visible in published service menus, and it is larger than most people expect.
Published managed-agent operations rates start at $7,000 per month for a single deployed agent workflow, with a three-month minimum. Broader managed AI operations engagements start at $15,000 per month, and senior delivery for the same category also sits at $15,000 per month.
Those are not aspirational numbers from a pitch deck. They are listed service tiers, which means enough buyers have accepted them to make them worth publishing.
The interesting question is not whether $7,000 is fair. It is what is being bought at that price, because the answer explains a failure mode that repeats across the industry.
A build contract is written to a finish line. It specifies scope, deliverables, a timeline, and an acceptance test that happens once. When it is met, the project closes, everyone is satisfied, and the vendor moves on.
An agent workflow does not have a finish line. It has an operating life. In that life:
Every one of those is a maintenance event. None of them appear in a build contract, because at the time of signature they had not happened yet.
The buyer paid for a prototype and received an operation. The operation was never priced, so it gets absorbed silently by the vendor — until the vendor cannot absorb it any more.
Two failure paths, and both are common.
The vendor absorbs it. Goodwill maintenance accumulates. The client believes the retainer-free arrangement is normal. Six months in, the vendor is maintaining a live system for free and resents it, and the eventual renegotiation feels like a betrayal to the client because nobody ever named the cost.
The vendor stops. Not deliberately — just quietly, as attention moves to new billable builds. The agent keeps running, degrading by degrees. Nobody notices until a failure produces a visible customer-facing incident, at which point the client concludes the whole thing never worked.
Both outcomes end the relationship. The second ends it with reputational damage.
A managed operations contract is not the vendor extracting more money from the same work. It is the same work finally being named and bounded — which is better for both sides.
For the buyer, a monthly figure with defined scope is predictable. It converts an unbounded support obligation into a line item they can budget against, and it creates an explicit party responsible for the system continuing to work.
For the vendor, it converts an open-ended goodwill liability into capacity that can be planned, staffed, and priced. The three-month minimum exists for a reason: the first month is diagnosis, the second is correction, and only in the third do you have enough operating history to know whether the workflow is stable.
That last item is the one that protects the relationship. It means "can it also do X?" has a clean answer: yes, quoted separately. Without it, scope creep is inevitable and both sides end up feeling cheated.
A managed retainer is only sellable if you can define what "working" means in writing. Our internal rule is blunt: if we cannot define an acceptance contract for the workflow, we do not sell the retainer.
An acceptance contract is not a service-level agreement about uptime. Uptime is the easy part and usually the least valuable. It is a written statement of:
| Element | What it must be | Common mistake |
|---|---|---|
| Outcome metric | A number the buyer already tracks | Inventing a metric the buyer does not care about |
| Acceptable range | Stated as a band, with the fallback behaviour | Promising a point value that any variance breaches |
| Failure definition | What counts as broken, in observable terms | Leaving "broken" to judgement |
| Response time | Per severity, with the escalation owner named | A blanket "4 hours" that means nothing |
If any row cannot be filled in, that is diagnostic. It means the workflow is not yet understood well enough to be operated by anyone other than its builder — which is a fine state for a prototype and a disqualifying one for a managed service.
Ask what happens in month seven. If the answer involves the original builder being personally reachable, you are buying a person rather than a service, and the arrangement will not survive that person's calendar. If the answer involves defined thresholds, sampling, and drift review, the price is doing real work.
And if the original contract had no maintenance line at all, understand what you actually purchased: a working prototype and an unwritten dependency. That is not a criticism of the build. It is a specification of what still needs to be bought.
We will look at one live workflow, write down what "working" should mean for it, and tell you plainly whether it is currently operable by anyone other than the person who built it.
Run the deployment check →One workflow, modelled end to end. Yours to keep either way.
A free deployment readiness check on one live workflow. We map the failure paths, the monitoring gaps, and the maintenance load nobody quoted you for.
Run the deployment checkOne workflow. Real arithmetic. No commitment.