Patience Kalu is not a real person, though the operational details she describes are drawn from public disclosures, research findings, and documented system architectures. She is a composite: the person who would exist at the bottom of the funnel if you followed the numbers all the way down. We met her in a coffee shop that also does not exist, where she arrived with a laptop open to a spreadsheet nobody asked her to make.
You were in bank compliance before this. What made you move into agent monitoring?
Patience: Someone described the job to me and I thought, oh, this is exception processing. I've done exception processing. Flagged transactions, suspicious activity reports, the whole apparatus. You sit in a queue, you review cases that automated systems couldn't resolve, you make a call. I figured the only difference was that instead of wire transfers, I'd be looking at API calls. Same muscle, different gym.
How different was it?
Patience: Wildly. The cases are harder and nobody knows what the rules are. In bank compliance, you had regulations. Specific ones. With citations. You could point to a paragraph and say, this is why I denied it. Here, I get a flagged action and I have to decide whether it's fine. Based on what? There's a policy document, sure, but it covers maybe 40% of what I actually see. The other 60% is me and my judgment and whatever I had for breakfast.
Walk me through a typical case.
Patience: The most common thing I see, the one that genuinely keeps me up at night, is credential expansion. An agent is doing its task, and it decides it needs access to something it doesn't currently have. A new API, a new host, whatever. The system flags it, the classifiers can't resolve it, and it lands on me. I see a summary of what the agent wants to do and why it thinks it needs this access. And I have to decide: is this a legitimate operational need, or is this scope creep?
What do you base that decision on?
Patience: That's the question, right? The first few months, I'd dig into the full context. Read the task history, trace the logic, try to understand whether the original instruction actually implied this kind of access. That takes fifteen, twenty minutes per case. And I get maybe fifty cases a week that need real attention.1 So that's manageable. Except the cases that need real attention are the ones the classifiers found genuinely ambiguous, which means they're genuinely hard, which means twenty minutes is optimistic.
You said "the first few months." What changed?
Patience: I got faster. And I honestly can't tell you whether that's because I got better at the job or because I stopped reading as carefully. Probably both. There's research on clinical alert systems showing override rates between 46 and 96 percent depending on the alert type.2 I think about that more than I'd like to. Am I overriding because I've developed good judgment, or because the queue is long and the cases mostly look like last week's? In compliance we called that "alert fatigue." Here nobody's even named it yet.
Tell me about the spreadsheet.
Patience: [turns laptop slightly] Nobody asked me to do this. Old compliance habit. I started noticing that I was seeing the same case. Not the same specific case, but the same type. Agent wants to expand to a new external endpoint. I'd resolve it, and then three weeks later, same pattern, different agent, different reviewer. Sometimes the other reviewer allowed it when I denied it. Sometimes vice versa. So I started tracking them. Case ID, date, type, my decision, whatever I could find about how similar cases were resolved by others.
What did the spreadsheet show you?
Patience: That we're inconsistent. And not randomly. If I've seen a particular destination before, I approve faster. If it's unfamiliar, I scrutinize it more. But "familiar" just means familiar to me. Another reviewer has a completely different mental map. So our decisions diverge not because we disagree on policy but because the system never told either of us what's already been decided. We're all working the same puzzle with different pieces.
Has anyone upstream looked at the patterns you're tracking?
Patience: No.
Just no?
Patience: Just no. My decisions go into tickets. The tickets go into a system. I have never seen evidence that anyone reads those tickets for patterns. I asked once whether there was a process for what I called "promoting" recurring case types into actual policy guidance. My manager said that was a good idea and that they'd look into it. That was seven months ago. I have followed up twice. Both times I got the same enthusiasm and the same nothing.
So what happens when the same case type appears again?
Patience: Another reviewer resolves it from scratch. They don't see my ticket. They don't see my reasoning. They make their own call, which goes into its own ticket, which also nobody reads. And somewhere in the aggregate of all these individual calls, there's a policy. A real, operational policy about what kinds of credential expansion are acceptable. It just happens to be written in ticket comments scattered across six months of queue history, and nobody's assembled it.
When did you realize that's what was happening?
Patience: There was a specific moment. I got a case that I recognized. Same pattern as something I'd resolved maybe three months earlier. I looked up the old case. A different reviewer had handled an almost identical one two weeks after mine and decided the opposite. No guidance was issued after either case. The threshold for flagging that action type hadn't changed. The agent product hadn't been redesigned. Both our decisions just evaporated into the system.
And I thought: I've been deciding this question over and over, and so has everyone else on the team, and none of us know what the others decided, and nobody upstream knows we're deciding it at all.
You're describing something that sounds a lot like governance.
Patience: I'm describing governance that doesn't know it's governance. I came from compliance. I know what a policy-making process looks like. It has review cycles, sign-offs, version control. What I'm doing has none of that.
But functionally? I am setting the boundary for what these agents are allowed to do. Every allow is a precedent. Every deny is a precedent. They're just precedents that nobody collects.3
Does that bother you?
Patience: It terrifies me. Not because I think I'm making bad calls. I think I'm making reasonable calls. But reasonable calls by twelve different people with no shared context and no feedback loop is not a policy. It's a distributed accident. That's the phrase I keep coming back to. We've accidentally built a legislature out of a help desk queue, and none of the legislators have met each other.
If you could change one thing about the system, what would it be?
Patience: I'd want someone to read the tickets. Not all of them. Just look for the patterns. Find the cases that keep recurring and turn them into actual guidance. Give me a rule so I can stop reinventing it every three weeks.
I didn't sign up to write policy. I signed up to catch errors. Turns out those are the same job, and nobody told me.4
Patience closed the spreadsheet. 347 rows, fourteen months of pattern-tracking that exists nowhere in her company's official records. She asked whether we wanted to see the pivot table she'd built to track reviewer divergence rates by case type. We did. It was meticulous. It was also, as far as her organization is concerned, invisible.
Footnotes
-
Anthropic's August 2026 fleet-monitoring disclosure reported that from approximately 100,000 weekly flags generated by offline monitoring, roughly 50 per week were escalated to human review. https://www.anthropic.com/institute/measuring-pace-of-ai-development ↩
-
A systematic review of computerized prescribing alert systems found average override rates ranging from 46.2% to 96.2%, varying substantially by alert type. See discussion in human-in-the-loop work design literature. ↩
-
NIST AI 800-4 identified "immature information-sharing ecosystem" and "scaling human-driven monitoring alongside rapid rollouts" as explicit cross-cutting challenges in post-deployment AI monitoring. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-4.pdf ↩
-
Pan et al., "Measuring Agents in Production," ICML 2026, found that 74% of deployed agent systems rely primarily on human evaluation and 75% do not maintain formal benchmark sets. https://arxiv.org/abs/2512.04123 ↩