Managing AI Agents After Deployment: A 30-Day Operating Plan for Small Teams

Buying the right agent is the easy half. The work that decides whether it's still running in three months starts the day after you deploy it.

Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 — and the three reasons it names are escalating costs, unclear business value, and inadequate risk controls. Read that list again. None of those are selection mistakes. They're all operating mistakes. They happen after the purchase, to teams who picked a perfectly good agent and then had no plan for running it.

This is that plan. Thirty days, no engineers, no observability stack.

Why the usual advice doesn't apply to you

Search for how to manage AI agents in production and you'll get guidance written for a different company than yours. Kill switches. Evaluator models that second-guess high-stakes decisions. Full decision tracing so every tool call can be reconstructed. Dedicated AgentOps tooling.

That advice isn't wrong. It's written for engineering organizations operating agents they built themselves, and it assumes a platform team to implement it.

If you hired an agent off a marketplace, your situation is inverted. You didn't build the thing, so you can't instrument its internals. You have no ML engineer. What you do have is the one thing the enterprise playbook takes for granted and rarely uses well: a human who knows what good output looks like.

That person is your entire quality system. The plan below is about pointing them at the right thing at the right time.

First, a statistic to stop repeating

You'll see it everywhere: 88% of AI agents never reach production.

It's a real number attached to the wrong subject. The 88% comes from IDC research conducted with Lenovo, and it measures AI proofs of concept generally — for every 33 POCs launched, roughly four reached production. It is not a measurement of AI agents, and it describes organizations building their own systems, not teams deploying a finished one.

Worth knowing for two reasons. It tells you the failure mode is organizational readiness rather than model capability. And it's a useful filter: a vendor who cites that stat as an agent failure rate hasn't checked their own sources.

Days 1–7: Establish the baseline

You cannot prove value later without a number from before. This is the step teams skip, and it's why "unclear business value" ends up on Gartner's cancellation list.

Pick one workflow. Measure four things for a week, by hand if necessary:

Write these down somewhere permanent. A shared doc is fine. In three weeks someone will ask whether this was worth it, and an honest baseline is the difference between a renewal and a cancellation.

Then set your ceiling. Decide now what you're willing to spend monthly, and check the agent's pricing model against your real volume — work-fee and token-based pricing behave very differently at 50 tasks a month versus 5,000. Escalating cost is the first item on Gartner's list for a reason: it's the failure that arrives quietly.

Days 8–21: Run the review loop

Two weeks of structured review. The goal isn't perfection — it's finding the shape of the agent's mistakes.

Review every output in week two. All of it. This feels excessive and it's the highest-leverage fortnight you'll spend. You're not grading; you're building a mental model of where this agent is strong and where it drifts.

Sort every miss into one of three buckets:

• Input problems. The agent got bad context, an ambiguous request, or a malformed file. Fixable by you, usually today.
• Scope problems. The agent is being asked to do something adjacent to what it was built for. Fixable by narrowing the job.
• Capability problems. The agent genuinely can't do this well. Not fixable by you — and the only bucket that should ever make you reconsider the agent.

Most teams assume every miss is bucket three and start shopping again. In practice the first two dominate early, and they're both free to fix.

Drop to sampling in week three. Review a fixed fraction — 20% is a reasonable starting point — and keep sorting. If the mix hasn't shifted toward "no misses" by the end of the week, you have a real problem to escalate rather than a settling-in period.

Calibrate oversight to consequence. Reviewing everything forever is how teams quietly spend more time on the agent than the agent saves. Anything cheap and reversible can run unattended once it's stable. Anything expensive, public, or hard to undo keeps a human in front of it permanently. That's not a temporary training-wheels stage; it's the steady state.

Days 22–30: Decide

Three outcomes. Pick one on purpose — the failure mode here is drift, where nobody decides and the agent runs half-trusted forever.

Scale it. The numbers beat your baseline and the misses are rare and predictable. Widen the scope one increment. Don't hand it three new responsibilities at once; you'll lose the ability to attribute any change.

Fix it. The output is close but the misses cluster somewhere specific. This is where marketplace agents have an advantage worth actually using: on Augex, the operator who built the agent is reachable. A capability gap that would take you weeks to diagnose is often a five-minute answer from the person who encoded the workflow. Ask before you re-shop.

Cut it. The gap is capability, the creator confirms it, and the workflow is outside what the agent does well. Kill it in week four rather than month six. You have a documented baseline and a documented reason, which makes the next selection decision sharper rather than a re-run of the same mistake.

The risk controls a small team can actually maintain

Gartner's third cancellation driver is inadequate risk controls. The enterprise version of this is a governance program. Yours is four rules, written down:

1. Define the blast radius. What is this agent permitted to touch? Name the systems, the data, and the spend limit explicitly. "Drafts replies, never sends" is a complete and useful policy.
2. Keep a human on anything irreversible. Sending, publishing, paying, deleting. No exceptions, regardless of how good the agent gets.
3. Know what data leaves. If the workflow involves customer records, know where they go and what the retention terms are before week one, not after an incident.
4. Name an owner. One person, by name, responsible for this agent's output. Shared ownership means nobody is reviewing.

Four lines in a shared doc. That's the whole program at this scale, and it addresses the same risk Gartner is describing.

Watch for agent washing

One selection issue worth carrying into your operating review, because it shows up as an ops problem: Gartner estimates that only around 130 of the thousands of vendors claiming agentic AI are real, describing the rest as "agent washing" — rebranding existing assistants, RPA, and chatbots without substantial agentic capability.

The operational tell is behavioral. A genuine agent handles variation in its inputs. A rebranded automation breaks the moment a request falls outside its script. If your week-two review shows failures that correlate perfectly with novelty — fine on the cases you demoed, brittle on everything else — you may be operating a workflow tool that was sold as an agent. That's a capability problem, and no amount of review loop fixes it.

The honest summary

Deploying is a five-minute decision. Operating is a thirty-day habit. The teams that get durable value from agents aren't running more sophisticated tooling than you — they set a baseline, reviewed hard for two weeks, sorted their failures honestly, and made an actual decision at the end of the month.

That's available to a team of four. It just has to be deliberate.

FAQ

How much should I review once the agent is stable?

Enough to catch drift, scaled to consequence. For low-stakes internal work, a weekly spot-check of a handful of outputs is usually sufficient. For anything customer-facing or financial, keep a human approving before the action happens — permanently, not as a probation period.

What if I don't have a clean pre-agent baseline?

Build one retroactively from whatever you have — ticket counts, email volume, invoice timestamps, calendar time. An approximate baseline you can defend beats no baseline. The point isn't precision; it's having a number to compare against when someone asks whether to keep paying.

Is a bad first two weeks a reason to switch agents?

Usually not. Early failures concentrate in inputs and scope, which are yours to fix. Switch when the failures are capability-based and the person who built the agent confirms it's outside the intended job.

Who owns the agent — ops, IT, or the team using it?

The team whose work it does. They're the only ones who can tell good output from plausible output. IT should own access and data boundaries; the operating owner should be the person who'd otherwise be doing the task.

Does this change for multiple agents?

The loop is the same per agent, but stagger your starts. Deploying three agents in one week destroys attribution — when your numbers move you won't know which one moved them. One agent, one baseline, one decision at a time.

Sources

• Gartner: Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (June 25, 2025) — the 40% cancellation prediction, the three named causes, the ~130 genuine vendors estimate, and the definition of agent washing. Figures reflect a Gartner poll of 3,412 webinar attendees.
• CIO: 88% of AI pilots fail to reach production — reporting IDC research conducted with Lenovo; the source of the 88% figure and the 33-POCs-to-4-production ratio, and confirmation that it measures AI proofs of concept generally rather than agents.
• Augex: AI Agent Marketplace Buyer Checklist — the selection-stage companion to this operating plan.
• Augex: AI Agent Pricing in 2026 — how work-fee and token-based pricing models scale with volume.