Module · M5 · From one agent to a team

Blast radius: who else must be told?

Lesson 20 of 21 · 9 min

Every question so far has been about one account. This one is not: who else was hit by the same failure, and who owns them? It is a relational question, and it is the one an ops function is judged on, because the accounts that were never told are the ones that find out from their own customers.

The policy is explicit about it — when an incident affects more than one account, every affected owner must be informed before their customer discovers it independently, and for an institutional cohort that includes the assigned instructor. So this is not diligence. It is a rule the reviewer can enforce.

The first build got it wrong, confidently

The impact specialist was originally given an entity search over companies. It reported:

“No other accounts outside Nimbus Retail were found to be affected.”

That is false. A second account — a 45-seat institutional cohort — carries the incident flag on its deal, and had been down for six days. The specialist could not have found it: the flag lives in a custom field, and entity search ignores custom-field filters. It searched, found nothing, and reported nothing as an answer.

A false negative from a search is the most dangerous result in this course. It arrives as a clean, confident, well-formed “no”. There is no error to notice, no empty state to investigate, and the agent downstream has no way to distinguish “nobody else was affected” from “this tool cannot see the field the answer lives in”.

A graph query beats a smarter prompt

Replace the search with one relational read. The tool takes no arguments at all — the statement is fixed, because the question is fixed:

the blast-radius tool, verbatim from the build

SELECT c.name AS account,
       c.company_type,
       d.name AS deal,
       d.owner_email,
       d.custom_fields->>'seats'       AS seats,
       d.custom_fields->>'outage_days' AS outage_days
FROM deals d
JOIN deal_companies dc ON dc.deal_id = d.id
JOIN companies c       ON c.id = dc.company_id
WHERE d.custom_fields->>'outage_affected' = 'yes'
ORDER BY c.name

Three tables joined the way the CRM already relates them. No prompt engineering can substitute for this join.

On the first call it returned both accounts, with their owners. The proposal that came out of that run named the one nobody had asked about:

“Another account, Meridian Business School (institution, 45 seats affected for 6 days), was also affected by the same underlying failure.”

Nobody mentioned that account in the ticket. The customer who complained had no idea it existed. It is in the answer because the query traversed the relationship rather than matching a string — and because the owner’s address came back with it, the notification duty is now actionable rather than aspirational.

The second gate this uncovers

Once the blast radius is wide, a tempting remedy appears: issue everyone’s certificates early so nobody misses the deadline because of an outage that was our fault. It is generous, it is fast, and it is one call.

It is also unrecallable, and it is not a money question. A credential a learner has already put on a public profile cannot be withdrawn by revoking a database row. The policy is unambiguous — issuance is human-only, no early issuance, and no deadline moves without academic approval — and that is the pattern generalising past cash: some actions are human-only because of what they do to reputation, not to the ledger.

The transferable rule. When the question is “who else”, “what is connected to”, or “which of these has that flag”, write the join. Entity search answers “find me something like this”, and those are different questions — one of them fails by returning nothing, and it does it politely.