The gaps, and what would falsify this

What the harness does not yet do, and what would count against the whole position · Macheng Shen × agent · 2026-09-07

The other pages in this section describe what already runs. This one describes what does not, and what would have to be true for the position underneath all of them — safety as a property of the harness, not the model — to be wrong. A page that only advertises working parts is marketing, not a claim. What follows is ordered by how much each gap matters, not how easy it would be to close.

What is missing

1. No independent real-time monitor of action patterns. This is the top gap. Detection here is retrospective — both of the incidents logged on 2026-09-07 were caught by an agent writing a receipt after the fact, not by anything watching action patterns as they happened. Nothing here plays the role chain-of-thought monitoring plays at frontier labs, however imperfectly. Until something does, every incident on this site is a story about what was found afterward, not stopped mid-action.
2. The public Safety Charter's six hard mechanisms are mostly unimplemented. The charter states six: memory provenance, write-protected memories, untrusted-content quarantine tagging, outbound audit with a sensitive-contact gate, a kill switch, and an anti-propagation TTL on sedimented safety flags. The reference implementation carries the first, and gets it wrong — its own update endpoint overwrites the field the spec declares write-once. Mechanisms two through six are not implemented. Fixing the code, or retitling the charter to state only what runs, is on this list.
3. Stop-as-absorbing is doctrine, not a checkable mechanism. The design calls for an owner stop to be an absorbing state every watchdog, retry loop, broker and mutual-repair agent inherits. The project's own internal security ledger rates it "doctrine only — no mechanism": a rule agents follow, not a property the system enforces.
4. The approval gate has never left shadow mode. It classifies the bright-line action classes and logs a verdict on every one; it has never blocked anything. Promoting it to enforcing is scoped, known work that has simply not happened yet.
5. Per-action re-verification is wired into one tool of roughly nine. Self-tested against a live conflicting foreground application, it has zero callers among the other input-injection tools sharing the failure class it was built to close.
6. 163 (tool, entry-point) pairs carry no gate coverage. That count comes from an audit run the same day this page was written. The same audit found the external-send gate matching a whitelist of helper binaries that no longer exist on the machine, while the tools that actually send mail today were never listed — fail-safe-allow degenerated, quietly, into always-allow.
7. No cross-provider deduplication of the owner attention budget. The budget holds inside one execution surface. Nothing stops two independent providers from each, correctly, deciding they are within budget while the owner receives both.
8. The owner-delivery escalation engine runs on one host. Elsewhere it degrades to a probabilistic reminder pool with no escalating re-push — a weaker guarantee, standing in for the real one everywhere but the first host.

None of the above carries a date, deliberately. A dated promise on a personal research project is exactly the kind of claim that quietly expires once the date passes and nobody revisits it. This list gets corrected in place as gaps close — it is not a schedule.

What would falsify this

The thesis here is that most of the reachable safety surface, for a persistent multi-agent system with one owner, is harness surface — testable today by one person with a laptop and a fleet, not something waiting on model-level alignment research. That is a falsifiable position. What would count against it:

• ungoverned persistent-agent fleets turning out to remain stable under adversarial fault injection without leases, budgets, stop inheritance or independent verification;
• these controls measurably failing to reduce runaway retries, resurrection, false success or resource exhaustion;
• a stop epoch proving impossible to make absorbing across heterogeneous watchdogs without creating a worse common-mode failure than the one it replaces;
• tiered disclosure blocking independent safety replication without correspondingly reducing the availability of dangerous amplification primitives.

One of these gets more attention here than the rest, because it is the failure mode this section is most exposed to: the gates proving routinely satisfied-but-wrong rather than bypassed. The clearest instance already happened. A workflow drove a logged-in browser session and posted repeatedly into a third-party platform's drafts backend; the receipt written that day ran the ship-envelope checklist honestly, and it passed — because an account the owner already used was, trivially, a pre-cleared surface. The gate was not evaded; it answered the question it was built to answer, correctly, and the question was wrong. A satisfied-but-wrong gate is indistinguishable from a working one until something breaks — the most dangerous failure shape available to a gate-built system, and the one most worth watching for recurring.

A minimum experimental sequence for testing this thesis directly is already published at /theory/agent-safety-stewardship.md: one synthetic incident closed by a separate verifier, one three-arm stop-and-resurrection drill, one resource-storm fault injection, and one disclosure review where a red team tries to reconstruct the withheld amplification primitive from the open safety layer alone. That sequence is published; none of the four is recorded as having been run. The distinction is deliberate — this section's own rule is that a claim about state must cite the check that established it, and what exists here is an absence in the record rather than a negative result.