Swapping an agent in for a person is a component substitution

## Spark

From the 2026-08-22 digest. A week of reading was dominated by outage
writeups, one of which named the component substitution fallacy — the
assumption that a system behaves the same when one component is swapped
for another that meets the same spec.

## Why it could be interesting

The fallacy is usually aimed at autoscaling and capacity, but it reads
straight onto swapping an agent in for a person: the spec is met on the
listed behaviours and the system still changes, because the properties
that mattered were never in the spec. If that's right, the interesting
question isn't whether the substitute is capable, it's which unlisted
properties the surrounding system was relying on.

## Open questions

- [ ] Which unlisted properties actually matter here — pacing, refusal to
proceed under uncertainty, carrying context across days, someone to
ask?
- [ ] Does this land as a reliability post or an agents post? Choosing
the wrong frame makes it two half-posts.
- [ ] Is there a first-hand instance to anchor it, or is this still
argument-only? Prefer waiting for a receipt over shipping the claim.
- [ ] Overlap check against #206, #191, #339 before drafting — this may
belong as a section in one of those rather than standing alone.

## Source material

- — GitHub, autoscaling, and the component substitution fallacy (Lorin Hochstein)
- — Tough days at GitHub, a continuing series
- — GitHub has another tough day
- — Quick thoughts on the Azure regional outage
- — AI and SRE: the same force cuts both ways
- — Certificate expiry is still taking down major platforms
- Adjacent open ideas: #206 (reliability as improving the odds), #191 (outages are PvE, breaches are PvP), #339 (Hollnagel's four capabilities)