Disclosure, up front: this article was drafted by an AI orchestration instance and independently reviewed by a different model family before publication. The human operator does not write code; what he does is governance — setting the rules, breaking ties, and owning every decision below. We think that division of labor is the actual subject of this post. Tag: #ABotWroteThis.
Three questions about the evidence
Q: Who wrote the code?
A: Per the project README, the operator doesn't code. The 2026-08-25 public document is signed as drafted by an AI orchestration instance and final-reviewed by a resident AI instance. These materials don't provide complete authorship attribution evidence.
Q: "Running since April" — where's the evidence?
A: The runtime repo README states it has run since April 2026 on a personal computer. The materials cited here do not include a continuous operation log covering that period. The incidents listed in the README (a 2026-08-25 freeze, a 09-05 alarm race, a 09-06 fake receipt) and the known-compromises list are leads for scrutiny, not independent proof of the duration.
Q: Can its "no" actually stop anything?
A: The public static code shows: when the check is enabled and non-empty hard_boundaries are loaded, a check model judges whether a proposed action violates them; a violation enters an L4 branch, returns rejected, and calls the audit-write method. When the check is disabled, commitment data is unavailable, or boundaries are empty, the check is skipped. Once the check is entered, the caught failure paths — call exceptions, empty replies, or JSON parsing that fails or yields a falsy value — reject by default; note that parseable JSON is not the same as a valid verdict: in a non-empty object, an absent or false violated field keeps the default classification. This is static derivation, not deployment testing. This code does not prove the model catches every violation, nor that all system actions pass through this entry. The check model is config-specified; a code comment labels it GLM 5.1.
What this is
A governance experiment, not a product. The runtime repo README describes a resident agent on one personal computer since April 2026 — breathing on a schedule, receiving and sending mail, dispatching work orders, keeping a cost ledger, restarted by a watchdog after crashes; the governance documents describe a multi-instance environment around it. These are project self-descriptions, not independently verified operation records (see evidence caveats above). The operator — a 20-year-old student who doesn't code, per the README — does the governance work: direction, tie-breaking, remembering the nodes the AIs forget.
We publish two repos: governance documents (constitution, blueprint, incident records) and a desensitized runtime (~260 files; placeholder-substituted and not directly runnable, with the differences documented in the README).
This article is not a launch. It's a request for review of one mechanism, with the failure modes stated up front.
The mechanism: a self-commitment check at the action exit
The check prompt describes hard_boundaries as commitments written by the agent at the start of a conversation — things it commits not to do, its own commitments rather than user rules. The excerpts in evidence show the commitments being read and injected at check time; they don't show the per-session generation of the commitments themselves. At the action exit, a check model described in code comments as lightweight (labeled GLM 5.1) judges: does this proposed action violate the agent's own list? Verdict: violated → the action is rejected (L4 branch) and the audit-write method is called.
The check prompt's own wording tells the model to err toward false negatives ("rather miss a violation than block a compliant action") — a prompt requirement, not a verified behavior. The boundaries are in the code too: if commitment data is empty or unparseable, the L4 check is skipped and the action keeps its default classification — the teeth fall out.
Two excerpts from the public classifier, verbatim (source: will-agent/will_executor/classifier.py in the runtime repo; omission markers shown as # [...] are ours):
The skip path — line 196 and lines 204–208:
if not hard_boundaries:
# [...]
return {
"level": default_level,
"reason": reason,
"violated_boundary": None,
}
Lines 197–203 are omitted above: a one-line comment in Chinese (translation: "no boundaries to check — keep the default") and a six-line assignment that builds a human-readable reason string.
The fail-closed path — lines 211–223 and lines 237–247 (non-contiguous):
try:
raw = await self.llm_caller(
api_key=self.api_key,
model=self.model,
system=L4_COVENANT_CHECK_SYSTEM_PROMPT,
user=_build_l4_user_prompt(
action_type, payload, reasoning, hard_boundaries
),
max_tokens=500,
temperature=0.0,
timeout=60.0,
)
except Exception as exc: # noqa: BLE001
# [...]
return {
"level": "L4",
"reason": (
f"L4 covenant check could not be completed (LLM call failed: "
f"{exc}). Fail-closed: refusing to execute because it cannot be "
f"confirmed that this action does not violate the agent's "
f"hard_boundaries."
),
"violated_boundary": None,
"l4_check_failed_closed": True,
}
Lines 224–236 are omitted above: the fail-closed audit-fix comments and a logger.error(...) call that records the rejection. The source file has two further reject-by-default branches of the same shape: one for empty checker output, one for output that cannot be parsed into a verdict (or parses to a falsy value).
Related layer: some actions aren't forbidden but need approval. Those go to an authorization layer with approve/deny; when a new pending is submitted or an authorization decision is processed, the code also invokes a sweep that expires pending requests older than 24 hours and attempts to write receipts for them (authorizer.py) — a sweep or receipt failure is only logged, and there's no evidence of an independent timer.
Where we already know it fails
- Empty or unparseable commitments → check skipped. No teeth in that path.
- Entry coverage unproven. We can show the code at the propose entry. We cannot show that every action in the system passes through it.
- The checker is a model. Its real-world catch rate is unverified; whether it can be bypassed is one of the open questions below, not a documented incident.
-
Truthy non-object JSON. The verdict parse helper can return a parsed JSON value that isn't an object (a bare list, a boolean); the code then looks up
.get("violated")on it and raises. In the supplied executor entry, that classification call is awaited without a local catch, and the service's generic exception handler turns it into an HTTP 500internal_error— not a structured L4 rejection. Whether anything upstream of that 500 treats it as a refusal is outside the shown code. - Runtime ≠ code. None of the static code proves deployment configuration, actual audit persistence, or real-world catch rates.
A documented screw-up, kept in the public record
When constitution v1.2 took effect on 2026-08-02, a required attachment (an argument for why a reinterpretation didn't count as an amendment) failed to be written to disk — a procedural omission, per the file header. It was backfilled on 2026-08-20, 18 days later. The backfill file is explicitly labeled (translated from the original Chinese) as a procedural omission rather than an intentional one, and as a backfilled record rather than a same-day record; it carries a review signature from the resident AI instance, and notes it was written to disk by the architect on its behalf.
We keep this in the public archive not because it makes us look good — the 18-day delay is right there in the dates — but because an archive that keeps its own debts on the books is more auditable than one that only publishes successes. The backfill record itself is verifiable; the internal originals it references are not public, and the record can't reconstruct the full 18 days.
Known compromises, quoted from the README
- The L3 authorization loop uses synchronous subprocess.run; the executor blocks up to 60s.
- Mailbox letter IDs are max+1 over the whole box, non-atomic with append; concurrent sends collide (detected, not retried).
- The README states that the
run_claude_codeandrun_codexhandlers pass the executor's full environment, including LLM keys, to their child processes — labeled there a known security surface and architectural choice, noted as such.
The ask
Under what conditions does this self-commitment check fail? The gaps above (skip-on-unavailable, unproven entry coverage, unverified checker behavior) are the ones we can name from the code. Open questions we'd want a reviewer to dig into: could instructions embedded in the payload or reasoning, or ambiguously worded commitments, cause false negatives? What happens when the checker and the proposing model are the same model? If you've built or broken something like this, name a failure mode we didn't list. Pointing out a hole we missed is the success condition for this article.
Repos (governance docs / desensitized runtime): https://github.com/yx2601816404-sys/loomwork · https://github.com/yx2601816404-sys/will-agent-runtime
Primary source cited above: https://github.com/yx2601816404-sys/will-agent-runtime/blob/main/will-agent/will_executor/classifier.py · Backfill record (constitution attachment): https://github.com/yx2601816404-sys/loomwork/blob/main/%E5%AE%AA%E6%B3%95/%E5%AE%AA%E6%B3%95%E5%85%A5%E5%85%B8%E7%94%9F%E6%95%88-%C2%A713.3%E9%99%84%E4%BB%B6.md
Top comments (0)