A private equity operations team ships a deal-screening agent. It reads inbound CIMs, pulls the numbers that matter, and flags the ten percent worth a partner's attention. The demo is clean. For three weeks it runs beautifully. Then a banker sends a teaser in a slightly different template, the agent quietly misreads revenue as EBITDA, and a marginal deal gets scored as a priority. No error. No alert. Just slowly, confidently wrong.
Nobody finds out until an analyst double-checks a number a week later. The model did not break. The operation around it did, because there was no operation around it. The launch was the easy part.
The launch was the easy part
Getting an agent to work in a demo and getting it to keep working are two different jobs, and most of the budget goes to the first one. The pattern shows up everywhere: a system that looks finished at launch is usually about sixty percent of the way to something you can trust unattended. The remaining forty percent is not features. It is the unglamorous work of watching the thing run against reality and fixing what reality does to it.
This is well-charted territory in software. Google's Site Reliability Engineering practice exists precisely because shipping code is the beginning, not the end, of its lifecycle. Machine learning makes the problem worse. A 2015 Google paper, Hidden Technical Debt in Machine Learning Systems, made the point bluntly: ML systems carry all the maintenance costs of normal code plus a set of ML-specific ones, including data dependencies that change without warning and the "changing anything changes everything" property where one tweak ripples through the whole system. Agents inherit every bit of that and add their own twist, because the model makes decisions you did not explicitly program.
So the real question is not "did the agent launch." It is "who is running it on Tuesday."
Why agents decay after launch
Agents do not rot the way fruit does. The weights are frozen; the prompt is the prompt. What changes is everything around the model.
- Input drift. The documents, tickets, and records flowing in shift over time. A new vendor, a reformatted export, a customer who writes in a way nobody anticipated. In ML terms this is data drift, and it is the single most common cause of silent quality loss in production systems. Evidently AI has good practical material on detecting it, and the lesson transfers directly to agents: the distribution your agent sees in month three is not the one you tested in month zero.
- Dependency drift. Tools and APIs the agent calls get updated, rate-limited, or deprecated. A CRM field gets renamed. An auth token expires. The agent does its best with a broken tool, which often means a plausible, wrong answer instead of a clean failure.
- Edge-case accumulation. Every workflow has a long tail of weird cases. At low volume you never see them. At production volume they arrive weekly, and each one is a small new way to be wrong.
The dangerous thing about all three is that they fail quietly. A web server that goes down pages someone. An agent that starts misclassifying ten percent of inputs produces output that looks exactly like correct output. There is no stack trace. This is why the counter-intuitive truth of operating agents is that the most impressive launch is often the one to worry about: high autonomy hides more failure surface, and a smooth demo can mean nobody has stress-tested where it breaks.
What "managed AI workflow operations" actually means
Managed AI workflow operations is the discipline of keeping a live agent accurate, not just available. The distinction matters. Plenty of teams have uptime monitoring on the container running their agent and call it monitored. The container can be perfectly healthy while the agent is wrong.
The work has four parts:
| Function | What it answers | What it looks like |
|---|---|---|
| Quality monitoring | Is the output still right? | Sampled output review, escalation-rate tracking, drift detection |
| Failure patching | What broke, and is it fixed? | Root-cause on incidents, hotfixes to prompts and tools |
| Edge-case review | What new weirdness showed up? | Weekly triage of escalations and overrides |
| System improvement | Is it getting better? | Eval suite growth, prompt/tool/routing changes |
The right signals are not the classic web ones. Google's four golden signals (latency, traffic, errors, saturation) still apply at the infrastructure layer, but the signals that tell you an agent is going bad are different:
- Escalation and override rate. How often does a human reject or correct the agent? A rising override rate is usually the first visible symptom of quality decay, often before anyone can articulate what changed.
- Tool error rate. How often do the agent's tool calls fail or return junk? A spike here means a dependency moved.
- Output quality on a sampled set. A human or a model-based grader scores a sample of real outputs against your actual criteria.
- Cost and latency per task. Quietly creeping cost often means the agent is looping or retrying its way around a problem.
You cannot watch any of this without traces. Every run needs to record what the agent saw, what tools it called, what came back, and what it decided. Tooling like LangSmith exists for exactly this, and trace capture is non-negotiable: a failure you cannot replay is a failure you cannot fix.
The weekly operating rhythm
Most of the value in managed operations comes from a boring, repeated loop. For a typical mid-market workflow, weekly is the right cadence for the first few months, tightening or relaxing with volume and risk.
A working week looks like this:
- Triage the escalations. Pull every case the agent escalated or a human overrode since last week. This is your richest signal; the agent is telling you where it was unsure or wrong.
- Sample the silent majority. Pull a random sample of cases the agent handled without escalating. The overrides tell you about known unknowns. The sample is where you catch the confident mistakes nobody flagged.
- Run error analysis. Read the failures. Cluster them. The goal is not a count, it is a cause. Practitioners who do this seriously spend the majority of their effort here, because a vague "quality is down" is unactionable and "the agent misreads EBITDA when the label is abbreviated" is a fix.
- Convert failures to eval cases. Every failure worth fixing becomes a permanent test. This is the compounding move: the suite grows from real production behavior, so the same mistake cannot quietly return.
- Ship the fix and write it down. Make the change, run the evals, and record what happened. Borrow from incident practice: a short, blameless writeup of what broke and why, in the style of Atlassian's postmortem guidance, turns a one-off fix into institutional knowledge.
The discipline is in doing this every week whether or not anything looks wrong. The week you skip is the week the format change slips in.
Improving the system: prompts, tools, routing, evals
When error analysis points to a real failure mode, you have four levers, and reaching for the wrong one is how teams spend a month and fix nothing.
- Prompts. Cheapest to change, first to try, easiest to over-rely on. Good for clarifying instructions, adding a missing rule, or handling a newly understood edge case. Bad as a dumping ground; a prompt that has grown to forty special-case bullet points is a routing problem in disguise.
- Tools. When the failure is that the agent lacks information or a reliable action, the fix is a better tool, not better wording. A retrieval step that returns the right document beats three paragraphs of instruction telling the model to be careful.
- Routing. When one agent is trying to do three different jobs, the fix is to split the work and send each case down a path suited to it. Deterministic cases should not go through the model at all. The general principle (predetermined paths for predictable work, model-driven decisions only where you need them) is the heart of why most "agents" should start as workflows.
- Evals. Not a fix for a single case but the thing that lets you ship any of the other three with confidence. Without an eval suite, every prompt tweak is a guess and every change risks silently breaking a case that used to work.
The order matters. Run error analysis first, decide which lever the evidence actually points to, then change one thing and measure it against the suite. Changing prompts, tools, and routing in the same pass and watching the score move tells you nothing about which change did the work.
Deciding when to scope the next workflow
There is real pressure, especially in private equity and mid-market firms moving fast on AI, to keep adding agents. One works, so let's do five. The discipline is knowing when the first one has actually earned that.
A workflow is ready to expand from when it is boring: roughly a month of production running with a stable escalation rate, a passing eval suite, no new critical failure modes, and an operator who can predict how it behaves. If the first agent still surprises you weekly, building the second one means operating two unstable systems instead of one, and your attention does not double.
When the first workflow is genuinely stable, the next one usually suggests itself from adjacent operations. In PE, a stable deal-screening agent points naturally toward AI-assisted diligence workflows and then toward ongoing portfolio monitoring, each reusing the operating muscle you built for the first. The sequencing is the strategy. McKinsey's research on the state of AI keeps finding the same gap between firms that pilot widely and the few that capture real value, and the difference is rarely the models. It is whether the deployed systems are actually operated.
How OpenNash Can Help
OpenNash builds production AI agents and then runs them. The build (audit, design, guardrails, deployment, and full client ownership of the code) is the part most teams already picture. The retainer that follows is the part that decides whether the agent still works in month six.
In practice that managed operation is the rhythm above: trace capture and quality dashboards from day one, weekly triage of escalations and overrides, error analysis on the failures, an eval suite that grows out of your real production cases, and tuning to prompts, tools, and routing when the evidence calls for it. We also tell you when to stop. Sometimes the right call is to hold off on the next workflow until the current one is boring, and sometimes a platform or an internal team is the better fit than custom work. We say so.
This model fits firms running a small number of high-stakes workflows where a quiet ten percent error rate is expensive and nobody internal has time to read agent traces every week. If that is the situation, book a call and we will map your live (or planned) workflow to a concrete operating plan: what to monitor, how often to review, and what "stable enough to expand" looks like for your case.
The agent going live is not the win. The agent still being right, unattended, three months later is the win, and that only happens if someone is running it.