The Night Five AI Agents Turned Me Into Customer Support

Forty-seven notifications. One night. Five AI agents I'd deployed to handle what I thought were simple research tasks.

By 2 a.m., I wasn't managing the work anymore. I was triaging an inbox that never stopped refilling. "Should I proceed with this approach?" "Task A complete, what's next?" "Found an edge case—guidance needed." Each agent worked at machine speed but waited at human speed. The bottleneck wasn't their capability. It was my decision throughput.

I realized something around midnight, somewhere between approving the third status update and wondering why I was still awake: agents aren't going to give us our time back. They're going to fragment what's left of it into smaller and smaller pieces.

The Cadence Collapse Nobody's Talking About

I've watched this movie before. Just with different technology.

Email collapsed the 48-hour memo cycle into same-day expectations. Slack collapsed same-day into same-hour. Mobile notifications made "after hours" a quaint idea your parents remember. Each wave promised efficiency. Each wave delivered was interruption at higher frequency.

Agents are the steepest acceleration of this curve I've seen—and we're deploying them without updating the management model.

When you manage humans, you give direction Tuesday morning and get a deliverable Thursday afternoon. Maybe a quick check-in Wednesday if something's blocking. The work happens in the background. Your calendar remains mostly yours.

When you manage agents, that 48-hour cycle collapses to 90 seconds. An agent that completes a task doesn't take a coffee break or think about the next step. It finishes, pings you, and waits. Five agents running in parallel means roughly 200 decision points per hour. That's not a workflow. That's an emergency room where you're the only doctor on call.

Around 11 p.m., I caught myself answering the same question I'd just answered four minutes earlier—except this time for a different agent on a different task. The questions weren't hard. But they were constant. And each one reset my focus to zero.

The Hidden Tax on Attention

Here's what the agent vendors won't tell you: the efficiency gain from agent speed gets offset by the coordination tax on human attention.

Your agents complete tasks in a tenth of the time. Fantastic. But if they interrupt you five times per task to confirm direction, ask edge case questions, or request the next assignment, you've just traded deep work for air traffic control. You're not doing your job anymore. You're answering the phone so your agents can do theirs.

I work with finance teams deploying agents to handle reconciliation work, anomaly detection, preliminary audit reviews—tasks that used to take junior staff two days and now take an agent twenty minutes. The time savings are real. So is the new job description: standing by to feed the machine its next instruction set.

One controller told me: "I used to review their work at end of day. Now I'm reviewing it every hour because the agent finishes and wants to know what's next." She'd automated her team's grunt work. She hadn't automated her own judgment calls—and now the judgment calls arrived ten times faster than before.

Nobody gets fired the day the agents arrive. You just slowly become their notification handler.

Pattern Recognition from the Last Disruption

Mobile notifications trained us for this, just at lower volume.

A decade ago, we learned to manage the Slack avalanche: mute channels, batch responses, set do-not-disturb windows. The survivors weren't the people who got faster at responding. They were the people who built systems to reduce how often they needed to respond in the first place.

Agents require the same evolution—except the stakes are higher and the pattern is worse. A Slack message from your colleague can wait thirty minutes. An agent stuck mid-task is burning cloud compute and blocking downstream work.

That urgency creates a false sense of crisis. The agent doesn't care if it waits. It has no anxiety, no impatience, no career goals. But the notification feels urgent because it's framed as a blocker: "Awaiting guidance to proceed." Your brain treats it like a person waiting on you, not a script paused at line 347.

I watched myself respond to agent notifications faster than I responded to my own team. Not because the agent work was more important. Because the feedback loop was tighter and the interrupt cost was hidden.

Three Survival Strategies That Actually Work

If you're deploying agents—or about to—here's what I learned from one extremely annoying night and the ten days of debugging my workflow that followed.

1. Build agents that decide for themselves where the cost of being wrong is low

My first-pass agents asked permission for everything. "Should I use data source A or B?" "This result looks unusual—is it valid?" I'd built in safeguards. I'd actually built in dependency.

I redesigned them with decision boundaries: if the dollar amount is under $500, pick the faster data source. If the anomaly is within two standard deviations, flag it but keep going. If you need a judgment call on something worth less than fifteen minutes of human time, make your best guess and document it.

The error rate went up slightly. The interruption rate dropped 80%. I'd rather audit ten decisions at the end than approve ten decisions in real time.

2. Batch high-stakes decisions instead of answering one at a time

I created a holding queue: any question an agent can't self-resolve goes into a list I review twice a day. 9 a.m. and 3 p.m. Fixed schedule. No exceptions.

Agents don't care if they wait three hours. They have infinite patience. Batching lets me see patterns across questions (turns out three "edge cases" were actually the same data formatting issue) and answer in context instead of from a push notification while I'm doing something else.

It feels inefficient—shouldn't I unblock them immediately? But agent idle time is nearly free. Human context-switching is expensive. The math favors the batch.

3. Design agents to wait for you, not the other way around

This one's counterintuitive: I added latency on purpose.

I set a minimum interval between agent notifications: no more than one ping per agent per hour unless it's a true exception (system error, cost threshold exceeded). Tasks that finish early go into a completed queue. I review the queue when I'm ready, not when they're done.

It's like the difference between someone knocking on your office door every six minutes versus sending you a summary at lunch. Same information transfer. Completely different cognitive load.

The Anchor Question You Need to Ask Monday Morning

Here's what I'd ask your team if I were advising you: how are you designing your agents' wait states?

Not their capabilities. Not their speed. Their waiting behavior.

Because the agent that pings you for guidance every ninety seconds isn't poorly designed from a technical perspective. It's probably very well designed. It's just designed without considering that you're managing four other agents, three human reports, and a meeting schedule.

The managers who survive the agent wave won't be the ones who get faster at answering. They'll be the ones who redesign the question cadence so they're not answering constantly.

Otherwise your job becomes notification triage. And the AI's job becomes the actual work.

What to do this week: Pick one agent or automated workflow you're running. Track how many times it interrupts you for guidance over three days. If the number is higher than the number of times your best human report would ping you with questions, you've got a cadence problem, not a capability problem.

Then ask: which of those interrupts could the agent have resolved on its own with clearer boundaries?

Start there. Because fifty notifications a night isn't sustainable—and it's only going to get worse as you deploy more agents.

How many are you running right now? And which one's about to ping you?