The Case-Study Round

“I run IT for a mid-size city. Our council wants us to cut 911 response times, and they’ve heard AI can help. Where would you even start?”

Before I propose anything — how is “response time” actually measured today? Call answered to unit dispatched, or call answered to unit on scene?

“On scene. Council sees an average number every quarter and it’s crept up over two years.”

That number is really three numbers added together: call-taking time, dispatch decision time, and drive time. Do we know which of those three is actually driving the increase, or are we assuming it’s dispatch?

“Honestly, nobody’s broken it down like that. We just assumed dispatch, since that’s the part that feels manual.”

Then step one isn’t a model, it’s a diagnosis — pull the CAD (computer-aided dispatch) logs and split the average into those three segments by shift and district. That’s a data question, not an AI question, and it might change everything downstream. What system generates those logs, and can we get raw exports?

“We run a commercial CAD platform. IT can get exports, but there’s no live API — it’s nightly batch files, and CJIS rules restrict who can even see raw call data.”

Good to know up front — that shapes the architecture more than anything else so far. One more question before I sketch anything: if the diagnosis does point at dispatch decisions, are we talking about recommending which unit to send, or is there any appetite for the system deciding that automatically?

“Never automatically. If a wrong call gets someone hurt, a human made that call, not a vendor’s AI. That’s non-negotiable, and honestly it’s the first thing legal will ask about.”

That’s the constraint the whole design has to respect, so let me build around it rather than bolt it on after. Say the diagnosis does confirm dispatch decisions are the biggest lever. I’d propose two things, both advisory, never autonomous: a real-time suggestion at the dispatcher’s console — “Unit 12 is 90 seconds closer than Unit 7 based on current traffic” — and a slower, nightly analysis that looks for patterns across weeks of calls, like a district that’s consistently under-resourced on Friday nights, and hands that to a shift commander as a report, not an action.

“The real-time piece worries me. What happens the first time it suggests the wrong unit and a dispatcher just does what it says instead of thinking?”

That’s exactly why I wouldn’t launch it visibly on day one. First phase is shadow mode — the recommendation runs silently for a few weeks, we log how often it agrees with what the dispatcher actually chose, and we only turn on the visible suggestion once we can show the accuracy number to the department, not just to us. Trust has to be earned before the suggestion goes on screen.

“Fair. Given the six-month budget cycle we’re actually working with, what ships first?”

The diagnosis and the nightly report — no live recommendation yet. It’s lower risk, doesn’t touch a dispatcher’s live workflow, and it’s the thing most likely to show council a number moving before the next budget review. The real-time console suggestion is phase two, after shadow-mode data backs it up.

“I run operations at a global freight company. Every time there’s a port closure or a storm, it takes my team two full days to figure out which shipments are affected and reroute them. Can you fix that?”

Two days is a specific, useful number. Where does most of that time actually go — figuring out which shipments are affected, or deciding what to do about each one?

“Mostly the first part, honestly. Someone has to manually cross-reference the news with our shipment list in SAP.”

What does “our shipment list in SAP” mean concretely — is this SAP TM, and is there an API or RFC layer IT can expose, or is this a system people mostly interact with through the SAP GUI directly?

“SAP TM, yes. There’s an API layer but it’s locked down — getting access takes a security review that usually runs a few weeks on its own.”

Good to flag now rather than discover in week three. Once a shipment is correctly flagged as affected, who decides the new route today, and what data goes into that decision?

“A planner. They’re weighing capacity, cost, and contract terms with the carrier — a lot of that lives in their head, not in a system.”

That tells me the reroute decision itself is genuinely hard to automate well right now — the tacit knowledge problem is real. But detection is a much more tractable first target. If I built an agent that watches port-status feeds, weather alerts, and news, and cross-references them against your in-transit shipments the moment an event happens, that alone could cut most of the two days without touching the actual routing decision at all.

“That would already help a lot. But eventually I do want it to suggest a reroute, not just tell me something’s wrong.”

Makes sense as phase two — once detection is trusted, I’d add a recommendation step that pulls alternate routing and capacity options straight from SAP TM and ranks them by cost and time delta, and hands that to the planner as a suggestion, with their tacit knowledge as the final filter. I would not have it write anything back into SAP automatically at that stage.

“Why not? If the planner approves it, why not just let the system make the change?”

It can — but only after an explicit human click, and only once we’ve built confidence in the recommendation quality. A write into SAP TM moves real freight and touches real contracts; if a bug in the approval flow fires twice, that’s an expensive mistake, not a UI glitch. I’d rather add the auto-write-back as its own phase, with its own testing, once phases one and two have already proven out.

“That’s reasonable. What do I tell my boss ships in the first month?”

Detection only — an agent watching external events against your live shipment list, surfacing affected shipments in minutes instead of a manual two-day scan. No SAP writes, minimal integration surface, and it’s the piece most likely to be unblocked while the API access review is still working through security.

“I head up fraud operations at a regional bank. Our card system, our wire system, and our new-accounts system don’t talk to each other, and we think we’re missing fraud because of it. Can AI fix that?”

When you say “missing fraud” — is that based on confirmed cases you later found should have been caught, or is it more of a suspicion based on how siloed the systems are?

“Both, but we do have a handful of confirmed cases — someone opened a new account, then wired money out days later, and each system’s own rules engine saw its own piece and flagged nothing.”

That’s a concrete pattern — cross-system correlation, not a smarter single-system model. Before I propose anything: do these three systems share a common customer or account identifier today, or would linking a customer across them be its own project?

“Not cleanly. The core banking system is decades old, the card processor is a separate vendor, and matching is mostly name and SSN, which isn’t always clean data.”

Then identity resolution across those three systems is the real first problem — before any fraud model, we need a reliable way to say “this card activity and this wire and this new account are the same customer.” Get that wrong and we don’t just miss fraud, we could wrongly link two different customers, which is worse. What’s the regulatory posture here — can any part of this take automated action, like freezing an account?

“No. Anything that looks like fraud goes to a human analyst, always. And if we do file a Suspicious Activity Report, we need to be able to explain why — a black-box score won’t fly with compliance.”

That shapes the whole design — this needs to produce explainable, cited cases for a human, never an autonomous action. Here’s how I’d sequence it: first, a nightly batch job that does identity resolution across the three systems using whatever matching signal is reliable enough — shared tax ID plus fuzzy name matching, reviewed by your team before we trust it fully. Only once that linking is validated would I add a second layer.

“And that second layer is the actual fraud detection?”

Right — a cross-system pattern check, initially just rules-based, not ML, looking for sequences like new-account-then-wire-then-unusual-card-geo across the linked identity. That alone, without any AI at all, might catch cases your siloed systems structurally can’t see. Once that’s proven, I’d add a retrieval layer that pulls similar historical confirmed-fraud narratives and regulatory typologies alongside each flagged case, so the analyst sees not just a score but cited precedent — that’s what makes it explainable enough for a SAR filing.

“What if identity resolution makes a mistake and merges two real customers?”

That’s the single scariest failure mode here, which is why I wouldn’t automate any downstream action off of it. Every linked identity and every flagged case lands in an analyst’s queue as a proposal with its evidence attached — the analyst confirms both the link and the fraud call. I’d also track a false-link rate explicitly from day one, the same way we’d track false-positive rate on the fraud side, and treat a rising number there as a stop-and-fix signal, not something to tune around quietly.

“Given all that, what would you actually commit to shipping in the first quarter?”

Identity resolution plus the simple rules-based cross-system flag — no ML, no retrieval yet. It’s the smallest thing that tests the actual hypothesis: that linking these three systems surfaces fraud the siloed rules engines miss. If that doesn’t hold up, the more sophisticated agent on top of it wouldn’t be worth building anyway.