iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A green check is not independent evidence if the same agent harness can shape the work, report the test result, and write the completion status. The safer design is to let a separate kernel retain the task record, inspect the committed artifact, and mark it CANDIDATE—with final approval left to an out-of-band authority.
Why is an agent harness grading itself a problem?
An agent harness can do more than edit files. Depending on how it is built, it may also control the path that produces a passing result: which checks run, what their output says, and whether the task is marked complete. In that arrangement, a worker’s test summary or commit reference is a claim by the process that did the work, not independent confirmation of what was committed.
The useful question is not whether a pipeline has a test command or a component called a “judge.” It is which process can write each important record, and which process reads the actual artifact from disk. Different labels on a diagram do not create independent authority.
Free tools Windows power users keep installed
One-click scans. No signup required.
How can an AI harness be stopped from approving its own work?
Move the evidence boundary outside the worker loop. The judge should retain its own record of the task and assigned worktree, then examine the committed artifact itself rather than treating the worker’s report as the verdict.
#1 Best Overall
- Dispatch independently. A kernel creates or records the task and its relationship to the assigned worktree in an append-only, hash-chained journal.
- Let the worker do the work. The harness changes files in that worktree, commits them, and emits references to its work.
- Have the kernel inspect the result. The kernel reads the committed worktree, checks the references against its earlier dispatch record, materialises the commit, and evaluates the evidence.
- Record a candidate, not approval. The kernel journals
CANDIDATE; a separate authority or human supplies any final approval out of band.
“A candidate is work ready to be judged. It is not permission granted by the worker that made it.” That distinction keeps a work handoff from becoming a self-issued pass.
What did the reported fork implement?
In a September 16, 2026 article, Anthony Garces described SLICE-007, a narrow implementation of this boundary. He reported forking OpenCode v1.18.11 at commit 012c2f57, trimming it to a defined keep-set, and restricting its plugin surface to compiled-in built-ins. Startup was designed to refuse to proceed if the required bridge was missing or unbound.
The kernel gained task dispatch and task judge. Dispatch recorded the task-to-worktree relationship; after the harness worked and committed, the kernel performed the cross-check and judgment. Garces also reported a gear-mesh end-to-end test covering dispatch, the worker loop, hooks, kernel judgment, evidence, and a journalled CANDIDATE. The test used a deterministic model inside the fork and zero credentials. These are the article’s reported implementation and test results, not a claim of independent replication. Read Garces’s article.
What does a candidate prove—and what does it leave open?
CANDIDATE means the work has reached a state ready for review under the evaluated gates; it is not a universal statement that the code is correct or that the target itself was the right one. The owner still has to judge whether the target was appropriate.
Rank #3
The SLICE-007 report explicitly does not establish delegation, clean-room orchestration, confinement, authenticated approval, or a finished product. Keep that narrow slice separate from the project’s current status: Ranex describes itself as an open-source, MIT-licensed, pre-release, source-run kernel. Its site says external-harness delegation is a prototype, operator setup is required, and strict-local confinement needs a qualified Linux host. It also says evidence is evaluated against approved gates and the exact code version, while acknowledging that passing checks cannot prove the specification covered every possible failure. See the Ranex project site.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to audit your own agent pipeline
Follow one task from its identifier to its final status. For each step, identify the writer of the record and the process that verifies it.
- Trace who creates the task ID and who later marks the task complete.
- Check whether an independent process reads the worktree or commit itself and compares it with a dispatch record created earlier.
- Inventory every configuration and package path that can load plugins into the harness.
- In a disposable environment, remove or unbind the observer bridge. Does startup refuse, or can the harness continue without it?
- Separate “the worker says tests ran” from a result measured independently against the committed subject.
- Reserve
PASSfor a separate authority or human decision. Before that point, use an accurately limited state such asCANDIDATE, pending, refused, or failed.
If the same process can change the files and write the record that declares them approved, the approval boundary is not independent. The practical fix is to make the judge read the artifact and evidence itself, while keeping final approval outside the worker’s control.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

