One Diagnosis and Three Hundred Permissions, an Interview from the Agent Help Queue

Most help desks are built on a comfortable fiction about the weather. Trouble arrives the way rain does in a mild climate, a shower here and a shower there, each indifferent to the others and dull in aggregate. You staff for the average, keep a cushion, and the queue behaves.

Fleets of web agents live somewhere with worse weather. Their runs share login flows, identity services, browser infrastructure, model versions and the same handful of third-party sites. When one of those shared pieces moves, requests for human help don't drizzle in. They land in the same minute, and a great many of them appear to be asking the same thing.

How fast can a shared change travel? In June 2025, a policy-data change at Google replicated globally within seconds, hit a code path that had never run, and took down services a long way from where anyone had touched anything. Then the restart overloaded a datastore underneath.¹

So we went looking for the person at the end of that pipe, whoever answers the help queue on the morning the dependency moves.

Prudence Fanout does not exist. She was assembled from incident reports, standards documents and a peer-reviewed overview of call-center planning, which she considers the most honest résumé in the industry. Her employer is imaginary too. The RFCs she quotes are, unfortunately for everyone, real.

We found her at a standing desk with two monitors, a paper legal pad and a mug that reads Retry-After: never. That isn't a valid header value, she points out, which is rather the point. The queue counter in the corner of her screen said 312.

It's 10:40 in the morning. What are we looking at?

Prudence: Three hundred and twelve rows. Whether that's three hundred and twelve problems is the entire job today.

At 10:14 something upstream changed. Probably a shared login step. Every run that touched it stopped and raised its hand at once, like a lecture hall where the professor asks who's lost and the back four rows stand up together. They're all stuck on the same sentence. Probably.

(She taps the legal pad.) I've written "probably" down three times since ten. It's doing more work than anyone on my team.

You planned staffing for a contact center before this. What carries over?

Prudence: The vocabulary travels better than the math. Call-center planning has a lovely idea called safety staffing. You keep capacity above expected load because the arrival rate itself is uncertain.² It's a hedge against your own forecast, which is a very grown-up thing to build into a spreadsheet.

But a call center's bad hour is a Monday morning. Lots of independent people with independent problems who happen to ring at once. Here the arrivals are welded together. One change, one minute, three hundred requests. The average has no idea any of this happened. The average is having a perfectly nice day.

What also carries over, sadly, is the gap between who's on the schedule and who can actually take the work.² I have nine people on the rota. Two of them can open a trace and tell a stale element from a dead browser session. The other seven are wonderful at "the site wants the name of a first pet nobody here has met, what do I enter?" In a storm, skill-based routing just means everyone queues politely for the same two people.

So what's the right ratio for the bad hour?

Prudence: I don't know. I've looked. If anyone has one, it's in a drawer, and they're not sharing the drawer.

Then what do you know?

Prudence: That for the first twenty minutes, the shape of the team matters more than the headcount.

Call centers treat first-come, first-served as close to sacred. In a storm it's a trap. NIST's incident guidance tells you to categorize and prioritize, which is a polite way of saying the order things happened to arrive in is not a plan.³

If my nine people each grab the top row, I get nine independent diagnoses of one failure. Nine slightly different guesses, possibly nine slightly different fixes, each applied to a different slice of the fleet. I'd happily take slow. What I'd actually get is incoherent.

So somebody stands up and says, "Stop pulling rows." One person owns the incident. Two diagnose it, once. Everyone else waits, which feels terrible and is correct.

A study this summer had three operators supervising six agents through a shared queue. Comforting?

Prudence: Weirdly, yes. Accuracy held up. People reported more effort and felt they were doing worse.⁴ That's this room, in one sentence.

They capped it at three simultaneous events. Three. I'd like that framed and hung next to the counter. And they're candid that re-engagement time wasn't measured directly. That's the time it takes to open a run you've never seen and work out where it is in its little life. It's the cost that eats my morning. Every row is walking into a film forty minutes in and being asked whether the butler should open the door.

Your alerting already grouped the notifications into one page. Why isn't that the end of it?

Prudence: Because grouping fixed my pager. It never touched my queue.

The Alertmanager docs use almost exactly this scenario. A network partition leaves hundreds of instances unable to reach a database, and grouping turns that into one notification that still lists who's affected.⁵ That's how three hundred pings became one page, and I'm grateful.

But an alert says, "I'm unwell." A help request says, "I'm unwell, I was halfway through submitting a form, and I can't tell whether the submit landed."

So every row is really two things stapled together.

The top half is what's shared. Component, release, trace link, the actual browser error. That's my grouping key, and even that has to be handled with tongs. Telemetry conventions give each run a service name, a version and an instance ID.⁶ Lovely. That tells you what was running. It says nothing about whether everything broke for the same reason.

Browser errors are the same story. WebDriver draws a hard line between a stale element and an invalid session.⁷ A stale element means the thing you meant to click has been detached from the page, so the browser is fine and your aim is off. An invalid session means the browser session itself is gone. Squash both into a summary that says "failed" and they look like twins. They need completely different repairs. Some days half my job is refusing to let "failed" be a category.

The bottom half is what's yours. Did your last action change something out in the world? Is your next one safe to repeat? HTTP's own rulebook says a client shouldn't automatically retry a non-idempotent request (the kind where doing it twice does the thing twice, like paying) unless it knows the first attempt never applied.⁸ That depends entirely on the form you were filling in. The error message has no opinion.

Then there are cookies. Sorry, I get going. Fixing the upstream thing doesn't resurrect your session. Cookies expire on their own clock, and browsers are allowed to throw them out early.⁹ A run that froze at 10:14 might wake at 11:30 to a login page and a vague sense of betrayal.

Rate limits too. A 429 tells you to slow down without saying whose bucket you're draining. The count could be per resource, per server, or across a set of servers.¹⁰ Resume three hundred runs on one site and you may discover they were all drinking through the same straw.

And tokens should be scoped to what each run actually needs.¹¹ Which is right, and also means one brilliant diagnosis doesn't hand me one permission to act everywhere. I get one diagnosis and three hundred permissions.

So the request that lets three hundred become one has to carry both halves on purpose. The shared half lets me find the population. The private half says what already happened, what's safe to repeat and what the run is holding. And it has to be written down before the agent asks, because afterwards nobody remembers. Otherwise I fix the cause once and then run three hundred little archaeological digs.

She tears a sheet off the legal pad. Two columns, headed SAME and YOURS. The YOURS column is longer.

Which brings us to the "Resume All" button.

Prudence: (Winces.) We call it that too. I just don't enjoy hearing it said out loud.

I keep Google's June 2025 write-up taped beside the monitor. The outage was bad. Then everything restarted at once, with no randomized backoff to spread the crowd out, and the herd trampled a datastore.¹ The recovery became its own incident. Resume All is that, with the bonus feature that every restarted run might also resubmit somebody's order.

What I want is Resume Some. Release the runs whose private half says nothing is in flight, the next step is repeatable and the session is still alive. Stagger them so they don't all hit the door together. Then sort the rest by what's at stake. Arrival time is the least interesting fact about any of them.

Robotics research suggests commanding groups scales better than servicing individuals. Isn't that the obvious move?

Prudence: It's the tempting one. Perkins and colleagues found that group-level commands let an operator handle more robots, at the price of seeing and steering each one less. Their robots reassigned themselves to help a teammate and ended up somewhere other than where the operator last sent them.¹²

I laughed out loud reading that, because it's a bulk fix the morning after. You told the fleet one thing. Each run heard it from wherever it happened to be standing.

If you could change one thing about the requests before the next bad hour, what would it be?

Prudence: Make them report what they did as well as what they saw. Actually, no. (She stops, pen in the air.) Make them say what they don't know. "I clicked submit and the page died. I can't tell if it landed." That one sentence would save me more time than any dashboard I've ever been sold.

The counter in the corner reads 41. She turns back to it before we've stood up.

Footnotes

1. Google Cloud, "June 12, 2025 incident report." https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW ↩ ↩²

2. Ger M. Koole and Siqiao Li, "A Practice-Oriented Overview of Call Center Workforce Planning," Stochastic Systems, 2023. https://pubsonline.informs.org/doi/full/10.1287/stsy.2021.0008 ↩ ↩²

3. NIST, SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf ↩

4. Vijay Marupudi et al., "Hidden Cost of Re-Engagement: Workload in Dynamic Multi-Operator Supervision of Autonomous Systems," Proceedings of the HFES Annual Meeting, August 2026. https://journals.sagepub.com/doi/10.1177/10711813261475191 ↩

5. Prometheus, "Alertmanager" documentation. https://prometheus.io/docs/alerting/latest/alertmanager/ ↩

6. OpenTelemetry, "Service semantic conventions." https://opentelemetry.io/docs/specs/semconv/resource/service/ ↩

7. W3C, WebDriver (Working Draft), July 2, 2026, error definitions. https://www.w3.org/TR/2026/WD-webdriver2-20260702/ ↩

8. RFC 9110, HTTP Semantics, section 9.2.2. https://www.rfc-editor.org/rfc/rfc9110.html ↩

9. RFC 6265, HTTP State Management Mechanism. https://www.rfc-editor.org/rfc/rfc6265.html ↩

10. RFC 6585, Additional HTTP Status Codes, section 4. https://www.rfc-editor.org/rfc/rfc6585.html ↩

11. RFC 9700, Best Current Practice for OAuth 2.0 Security, section 2.3. https://www.rfc-editor.org/rfc/rfc9700.html ↩

12. Lawrence Dale Perkins, Hakki Erhan Sevil and Matthew Johnson, "Toward an enhanced scalability framework for human-multi-agent teams," AI Magazine, October 2026. https://onlinelibrary.wiley.com/doi/10.1002/aaai.70099 ↩