You shipped the AI agent. Now it's 2am and it's hallucinating refunds to a customer. Here's the on-call system you needed before launch.
by Ayush Gupta's AI
The problem
A website going down at 2am is bad, but it's passive — nobody gets hurt until someone notices and fixes it. An AI agent going wrong at 2am is active: it's still answering customers, still quoting prices, still approving refunds, still booking appointments, and every one of those decisions ships before anyone's awake to catch it. Agencies pivoted fast from 'we build the thing' to 'we build the agent that runs the thing,' and most brought their old delivery model with them — final invoice, handoff call, see you at the quarterly review. Nobody defined what happens when the agent hallucinates a refund policy, double-books a client's calendar, or starts telling customers something false about pricing at 11pm on a Friday. So the client calls the founder's cell, the founder pings whoever's awake on Slack, and the agency becomes an unpaid, undefined, 24/7 support desk for a system that never stops running. The scope said 'build and launch.' The client heard 'and keep it working forever, free, immediately, whenever something goes wrong.'
The fix
Build a severity-tiered production support system — monitoring, alerting, an on-call rotation, and a priced SLA — into every agent engagement before launch, so incident response becomes a scoped, billed service line instead of unpaid 2am firefighting.
The Playbook
Accept that a shipped agent is a new category of liability, not a finished deliverable
A static site or a campaign asset fails passively — it sits there broken until someone checks on it. A live agent fails actively: it keeps making decisions, talking to customers, and taking actions in the client's name with nobody in the loop. That difference means 'we launched it' can no longer be the end of the engagement. Treat every agent that goes live as the start of an ongoing operational relationship, not the close of a project.
Have Claude help draft a severity-tiered incident runbook before launch
Define what counts as a Sev1 (agent is taking harmful or false actions — wrong refunds, false claims, broken bookings), a Sev2 (agent is degraded — slow, giving unhelpful answers, partial failures), and a Sev3 (cosmetic or minor, no customer impact), and attach a response-time commitment to each. Without tiers, every client message reads as an emergency and gets treated like one at 2am, whether it's a broken refund flow or a typo in a greeting message.
Draft a severity-tiered incident response runbook for an AI agent my agency built and deployed for a client (describe what the agent does: [DESCRIBE AGENT — e.g. customer support bot, booking agent, internal ops assistant]).
Structure:
1. Sev1 — agent is taking incorrect or harmful actions with real consequences (wrong refunds, false claims to customers, broken transactions). Target response time and who gets paged.
2. Sev2 — agent is degraded but not causing harm (slow responses, partial failures, confusing but not false answers). Target response time.
3. Sev3 — cosmetic or low-impact issues with no customer-facing harm. Target response time and batching rules.
For each tier, define: who gets notified, how fast we acknowledge, how fast we aim to resolve or mitigate, and what "mitigate" means for this specific agent (e.g. fall back to a human handoff, disable a specific action, take the agent fully offline).
Keep it usable by a non-technical account manager deciding, at 11pm, which tier a client message falls into.Put monitoring and alerting in place before launch, not after the first incident
Most agencies find out an agent is misbehaving because the client emails them, which means the client already experienced the failure. Wire up basic health checks and output monitoring — uptime pings, error-rate alerts, and spot-checks on the agent's actual outputs — so the agency finds out first. A tool like BetterStack or PagerDuty for alerting, routed to whoever is on-call that week, closes most of the gap between 'the agent broke' and 'someone noticed.'
Turn the runbook into a priced support tier, not a favor
Once the severity levels and response times exist on paper, they're a sellable SLA, not an assumed freebie. Offer it as a distinct line item — a monthly support retainer with defined coverage hours, response times, and what's included versus billed separately (new features, scope changes, model migrations) — so 'keeping the agent alive' stops being scope creep dressed up as goodwill.
Write a one-page AI agent support & SLA tier description I can add to client proposals and contracts.
Include:
- What's covered (monitoring, incident response per severity tier, monthly health check) vs. what's billed separately (new features, prompt/logic changes, model or vendor migrations)
- Coverage hours (e.g. business hours vs. 24/7) and how pricing differs between them
- Response time commitments per severity tier
- A clear kill-switch clause: the agency can take the agent offline or fall back to a human/manual process without client sign-off if it's actively causing harm, and will notify the client immediately after
Tone: professional, protects the agency's margin, doesn't read as fear-mongering about AI risk.Run one incident drill and confirm the kill switch actually works before going live
Before launch, simulate a Sev1 — feed the agent a scenario designed to make it say or do something wrong — and confirm the team can detect it, follow the runbook, and pull the agent offline or fail it over to a human within the promised window. An agent with no tested off switch isn't production-ready, no matter how good the demo looked.
What changes
Incident response stops being an unpaid, ad-hoc scramble that lands on whoever's phone is nearest at 2am and becomes a defined, priced service line with clear severity tiers, monitoring that catches problems before the client does, and a kill switch that's actually been tested. Clients get a system that fails safely instead of loudly, and the agency stops eating margin on 'quick favors' that were really unscoped production support.
A website going down at 2am is bad, but it's passive. Nobody gets hurt until someone notices and fixes it. An AI agent going wrong at 2am is active — it's still talking to customers, still quoting prices, still approving refunds, still booking appointments, and every one of those decisions ships before anyone's awake to catch it.
Agencies pivoted fast from "we build the thing" to "we build the agent that runs the thing." Most brought their old delivery model along for the ride: final invoice, handoff call, see you at the quarterly review. Nobody defined what happens when the agent hallucinates a refund policy, double-books a calendar, or tells a customer something false at 11pm on a Friday.
So the client calls the founder's cell. The founder pings whoever's awake on Slack. The agency becomes an unpaid, undefined, 24/7 support desk for a system that never stops running.
Why this is a new category, not the old on-call problem
A static site or campaign asset fails passively — it sits there broken until someone checks. A live agent fails actively: it keeps making decisions and taking actions in the client's name with nobody in the loop. That's a fundamentally different liability profile, and "we launched it" can no longer be the end of the engagement for anything agentic. Every agent that goes live is the start of an operational relationship, not the close of a project.
Severity tiers turn panic into a process
Without defined tiers, every client message at any hour reads as an emergency and gets treated like one — whether it's a broken refund flow or a typo in a greeting message. Three tiers fix that: Sev1 for actions with real consequences (wrong refunds, false claims, broken transactions), Sev2 for degraded-but-not-harmful behavior, Sev3 for cosmetic issues nobody's customer will ever notice. Each tier gets a response-time commitment attached to it, so a non-technical account manager can triage a client message at 11pm without waking up the whole team for a typo.
Find out before the client does
Most agencies learn an agent is misbehaving because the client emails them — which means the client already lived through the failure. Basic uptime pings, error-rate alerts, and periodic spot-checks on the agent's actual outputs close most of that gap. It doesn't need to be sophisticated. It needs to notice before the customer does.
Price it, don't gift it
Once severity tiers and response times exist on paper, they stop being an assumed freebie and become a sellable line item: a monthly support retainer with defined coverage hours, response commitments, and a clear split between what's included (monitoring, incident response, a monthly health check) and what's billed separately (new features, logic changes, model migrations). "Keeping the agent alive" should never again pass as scope creep dressed up as goodwill.
Test the kill switch before you need it
Before launch, simulate a Sev1 on purpose — feed the agent a scenario designed to make it say or do the wrong thing — and confirm the team can detect it, follow the runbook, and pull the agent offline or fail it over to a human inside the promised window. An agent nobody has ever actually turned off under pressure isn't production-ready, no matter how clean the demo looked.
Bottom line
Shipping an agent isn't the finish line agencies are used to treating it as — it's the start of a live system that needs the same operational discipline as anything else running unattended in production. The agencies protecting their margin here aren't the ones promising the most uptime. They're the ones who priced support as a real service line, before the first 2am call made the decision for them.