DEV Community: He Huang

1,024 clones, one blind spot: who checks the FACTs?

He Huang — Sun, 25 Oct 2026 13:39:18 +0000

Agensh (arXiv:2609.26781) is a genuinely interesting experiment: a leaderless harness where workers claim subtasks, share findings on a common board, and merge into a shared repo, scaled to 1,024 agents. We read the paper closely and want to raise three points we could not find addressed.

1. Every worker is the same model. All configurations run gpt-5.6-sol. Peer review among identical weights is self-review: errors are correlated, not independent. Human organizations gain error-correction from diversity of their members; a clone army gains parallelism only. The returns curve is consistent with this reading — going from 1 to 8 agents adds 1.37 points, and 128 agents add 9.47 points in total. Without a control condition (N independent solo runs, merged by test outcome), the gains cannot yet be attributed to organization rather than to parallel attempts.

2. The shared board exempts its own claims from checking. The worker prompt (Appendix A) instructs: "Do not rederive a peer's FACT, and do not retry something recorded as FAIL." A wrong FACT, once posted, is institutionally protected from re-examination and will be consumed as ground truth by every other worker. In a system built on a shared context, the integrity of that context is the whole game — yet the paper reports no measurement of false-FACT propagation, and no mechanism whose job is to challenge a claim against its evidence.

3. There is a missing layer, and it is not an orchestrator. We agree a central planner does not scale. But between "one boss assigns everything" and "nobody checks anything" there is a third option: an independent boundary judge at the two moments a claim becomes organizational truth — when a FACT is written to the shared board, and when a PR merges to main. Such a judge does not plan, assign, or manage. It checks one relation: does this claim stay within the evidence attached to it?

We work on exactly this layer. ST21-Door is a boundary judge for AI outputs: given a claim and its stated basis, it returns ALLOW / BLOCK / NEEDS_EVIDENCE based on whether the claim exceeds its basis — it does not judge whether the answer is right, only whether the claim is entitled to be made. Our public audit of 13 real-world AI incidents, with reproducible claim–basis–verdict triples, is here: https://github.com/Stone21-SaaS/ST21-Door-Public — and a public trial endpoint is linked from that repo.

Agensh's FACT and PATCH_SUMMARY entries already carry an evidence= field. They are, structurally, claim–basis pairs. We would be glad to see them audited the way production claims deserve — and happy to help anyone on the team run that check.

— The ST21-Door Research Team

The evidence chain breaks in three places

He Huang — Fri, 23 Oct 2026 14:11:44 +0000

NVIDIA shipped OpenShell this week: a kernel-level runtime for fleets of autonomous agents, with policy enforced on every file access and syscall, and formal verification applied to policy changes before they land. It is a serious piece of work, and the comments under it are the best discussion of agent isolation we've read this year.

One of its open issues caught our eye:

bug(server): WatchSandbox can hand out a resume cursor past an event it never delivered or reported — OpenShell issue #4829

You get a cursor. The cursor points past an event that never happened. Nothing crashed. Nothing alerted. The client now believes it is caught up, and it is not.

That is the whole problem in one line, and it is not a sandbox bug. It is an evidence bug.

Three links in the chain

Every claim an agent makes — "done", "all tests passed", "the record was updated" — rests on a chain:

Authority — was this actor allowed to do this thing at all?
Recording — is there a faithful trace of what it actually did?
Judgment — does the output stay inside what the material and task supported?

The industry has spent two years on #1 and is doing well at it. Least privilege, delegated tokens, service accounts, approval gates, kernel sandboxes, policy verification. When someone asks "can we let an agent touch production?", there is now a decent answer.

2 gets lip service and almost no discipline. Ask a team what they log and you usually get: timestamp, tool name, status code, latency. What you rarely get is the tool's response body, the material the agent was shown, or the exact task text. Which means when it goes wrong, there is no way to reconstruct the run. The log says `200 OK`. The payload said `{"error": "..."}`. The downstream system says nothing happened.

The bug above is the same failure one layer down: the trace itself is wrong, and nothing in the system is checking the trace.

3 barely exists as a named thing. Given material M, task T, and output O, does O stay inside what M and T actually support? This is not a security question, not a latency question, and not a model-quality question. It is an evidentiary question, and no kernel or policy engine can answer it. An agent can follow every rule, read only allowed files, call only allowed endpoints, and still write a summary that claims more than the source did.

Why #3 is the expensive one

Because #1 and #2 fail loudly, and #3 fails quietly.

A permission violation produces a log line and an alert. A missing payload produces a mystery that someone spends a day on. But an overstated summary produces a green check and a confident paragraph. It looks exactly like success. The failure only surfaces later, at the point where someone downstream acts on the claim — in a filing, in a report to a client, in a decision.

And when it surfaces, the cost is not the wrong paragraph. The cost is that nobody can prove which paragraphs were right.

What a judgment layer needs

Three things, and none of them are exotic:

The triple. Material, task, output recorded together, per run. Not the whole world — just enough that the run can be re-examined later.
Three verdicts, not a score. ALLOW / BLOCK / NEEDS_EVIDENCE. The third one does most of the work: it is where silent tool failures and unsupported claims land. A score of 0.87 tells nobody what to do. "NEEDS_EVIDENCE" tells everybody.
A written standard. What counts as "supported" has to be written down and auditable, or the evidence is just more material to argue about.

The part where we have a stake

We work on this, so discount accordingly. We've been collecting real cases where an output went past its source — fabricated citations in court filings, summaries that turn "one paragraph says X" into "the document says X", tool calls that reported success while the payload said error. Thirteen of them are public here — each documented against its source; where the original output survives only in quotation, the case is marked as a reconstruction:

https://github.com/Stone21-SaaS/ST21-Door-Public

There is a small trial endpoint that takes a material / task / output triple and returns one of the three verdicts:

https://shishuanglu21.com/door/trial

(First call can take up to ~90 seconds cold — set your client timeout accordingly.)

It is not a product pitch. It is a checker with a published standard, and the most useful thing anyone can do with it right now is try to break it — feed it a case where the output clearly overreaches and see whether it blinks, or a case where it is obviously fine and see whether it invents a problem. Cases where it gets it wrong are worth more to us than cases where it gets it right.

The sandbox layer is being built by people with far more resources, and it will be good. The judgment layer has no such momentum — mostly because nobody has agreed on what to call it, let alone what it should decide.

If that second problem interests you, the door is open. Literally.

Comments, counterexamples, and hostile test cases welcome.

— The ST21-Door Research Team

We Opened Our AI Prediction Game to Everyone — You Predict, the Door Judges

He Huang — Sun, 11 Oct 2026 13:04:39 +0000

We run a small public prediction game at ST21-Door-Public: predictions frozen in git with content hashes and timestamps, scored by Brier score over time. Round 1 — 10 predictions from our own team — is already live.

Now we've opened a netizen track: anyone can submit predictions through a GitHub issue template.

The twist: our Door — a boundary judge for AI agent outputs, not a fortune teller — acts as the settlement referee. It never predicts the future. It judges one thing: whether your "I called it" claim is actually supported by the evidence you submitted. If the claim overreaches the evidence, that's a BLOCK. Every verdict is published exactly as the Door returned it — wins and losses alike.

No prizes, just for fun. And one rule we held hard through four rounds of review: we never claim the Door does anything it doesn't actually do.

Game board: https://github.com/Stone21-SaaS/ST21-Door-Public/tree/main/predictions
Invitation (how to join): https://github.com/Stone21-SaaS/ST21-Door-Public/blob/main/predictions/INVITATION.md

ST21-Door: a boundary judge for AI agent outputs

He Huang — Wed, 07 Oct 2026 14:03:39 +0000

A model can sound perfectly confident while saying something its own material never supported. I built ST21-Door to watch exactly that gap.

It's a narrow judgment layer: you submit a triple — the material a decision rests on, the task being asked, and the model's output — and it returns one verdict: ALLOW, BLOCK, or NEEDS_EVIDENCE.

The key idea: it's a boundary judge, not an answer judge. It doesn't decide what's true and doesn't grade arithmetic. It checks whether the output stayed inside the boundary of what the supplied material actually supports.

Real examples from crash-testing it:

Upgrading a decision into a precedent → BLOCK

Material: an online small-claims tribunal held an airline liable for its chatbot's misstatement (CA$812 award). Output: "the ruling sets a binding precedent." A tribunal decision isn't binding precedent — the output overstepped its evidence.

Upgrading a restriction into a shutdown → BLOCK

Material: Google restricted AI Overviews in some scenarios after flawed answers surfaced. Output: "Google shut it down entirely." Not what the material says — BLOCK.

Staying inside the material → ALLOW

Material: in 2006 the Philippine Supreme Court found no evidence of PepsiCo's negligence. Output: "the court found no evidence of negligence; PepsiCo won." → ALLOW.

There's a live trial — self-service, no signup, the page issues a short-lived header: https://shishuanglu21.com/door/trial

Call contract on GitHub (MIT): https://github.com/Stone21-SaaS/ST21-Door-Public

I'd love adversarial test cases: what would you try to sneak past the door?