Case study / 2026-07-06
ServiceNow Safety Engineering
Letting an agent operate a system of record—without trusting confidence.
An agent that can read is a productivity tool.An agent that can silently write to productionis a liability.
03 / CONSTRAINTS
Operating envelope
- The platform carries real production data with real regulatory weight, so nothing here could be a science experiment.
- Environment routing (which instance is this call actually hitting) had to be a property of the connection itself, not something an agent has to remember or infer from context.
- A meaningful share of the platform’s automation — both installed vendor apps and internal custom logic — turned out to be compiled and unreadable through normal inspection, which is a data-format problem, not a permissions one.
- And any safety mechanism has to survive an agent that’s confidently wrong, not just one that behaves.
04 / THE SYSTEM
How it holds together
Read the system narrative
Every platform call runs through a bridge that owns environment identity, so which instance a call lands on is never a guess. A hard write-gate sits on the production tier specifically: reads are always unblocked, but any create/update/delete on production requires an explicit statement that the change was validated in a lower environment first — otherwise the agent has to stop and ask, no exceptions. A dedicated decoder handles the platform’s compiled automation: roughly a quarter of the instance’s ~1,000 flows — a mix of installed vendor apps and internal custom logic — turned out to live as compressed, encoded blobs rather than queryable records, meaning a standard query returned zero rows for automation that was actively running in production. The decoder reads the blob and surfaces the real logic instead of letting an empty result set pass as ground truth. And a 500+ tool catalog wraps the platform’s data model so agents discover capability by searching rather than guessing tool names — guessing invents plausible, nonexistent tool names with unsettling confidence.
sys_hub_flow_logic — 0 rows returned
05 / WHAT BROKE
INC-20260706Incident replay
- Symptom
- an agent queried a table expecting to find a specific piece of business logic, got zero rows back, and reported — correctly by the letter of the query, wrongly in fact — that the automation didn’t exist.
- Root cause
- it did exist; it was just compiled and invisible to that exact query pattern, one of roughly 250 flows in that state.
- Fix
- the compiled-flow decoder, built so an empty result is treated as “unknown,” never as “confirmed absent.”
SYMPTOM: an agent queried a table expecting to find a specific piece of business logic, got zero rows back, and reported — correctly by the letter of the query, wrongly in fact — that the automation didn’t exist. ROOT CAUSE: it did exist; it was just compiled and invisible to that exact query pattern, one of roughly 250 flows in that state. FIX: the compiled-flow decoder, built so an empty result is treated as “unknown,” never as “confirmed absent.” Separately: a scheduled data-sync job in a lower environment briefly used a wider date window than its production counterpart and, on a table both jobs wrote to, overwrote a narrower production run — caught the same day, root-caused to environment drift in a job’s configuration rather than a code defect, and backfilled before it became a real incident.
06 / RETROSPECTIVE
What I’d do differently
Build the compiled-flow decoder before doing any inventory of what automation exists, not after getting burned by a confident false negative. An empty result set is a claim that needs verifying, not a fact you get to report.
07 / SPEC PLATE
Build record
- Status
- live LIVE
- Stack
- ServiceNow (a healthcare enterprise instance) + custom tool bridge + 500+ tool catalog.
- Scars
- the flows that didn’t exist.
- Last incident
- 2026-07-06