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

# 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](https://augex.ai/blog/ai-agent-pricing-in-2026) 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.

1. Keep a human on anything irreversible. Sending, publishing, paying,

deleting. No exceptions, regardless of how good the agent gets.

1. 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.

1. 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.