I Forked My Agent Harness So It Couldn’t Grade Its Own Homework

TL;DR: An agent harness cannot independently approve work when it controls both the artifact and the success path; move “done” outside the loop. This is one record from the Ranex slice log.

Your agent finished the task. The harness says it is done. Who, exactly, was allowed to make that call? That question is the next layer under every green check you got this week: the moment the harness had to stop grading its own homework.

In this note

• The problem hiding inside a successful run
• The lesson: move “done” outside the loop
• A checklist for finding self-grading in your pipeline
• What was actually proven in this slice
• Your next move

The problem hiding inside a successful run

A check bolted around an agent is not independent if the agent’s harness can still author the route to success. You need a different actor, with its own record, to decide what the emitted work means.

You know the shape. A task starts. An agent edits files. A wrapper collects a summary, a commit, a test result, or all three. Then that same wrapper turns around and announces success.

That is not a tiny trust gap — it is the whole gap.

The agent does not need bad intent for this to fail. The harness can be wrong, incomplete, configured too broadly, or simply allowed to load something you did not expect. If its output is both the evidence and the verdict, there is no independent place to ask the rude question: Did this task produce what the dispatch actually asked for?

Ranex is pre-release. It is a kernel with a working verdict path and very little else. But this boundary is built because a useful system needs to make that rude question executable, not ceremonial.

I did not get to skip this by calling the surrounding code a harness. Names do not create separation. Authority does.

The lesson: move “done” outside the loop

The fix is structural: let the harness produce work and references, then let the kernel cross-check them against a record it owns. The harness can emit evidence; it cannot emit a gate, a merge, a stamp, or an approver.

For SLICE-007, Ranex forked opencode at v1.18.11, commit 012c2f57. The fork was trimmed to a defined keep-set. Its plugin surface was locked to compiled-in built-ins. It refuses to start when the required bridge is missing or unbound.

Those details sound operational. They are the point.

A harness that can take configuration or npm plugin paths can change what is running around the work. A harness that starts without its bridge can run unobserved. You do not repair either condition by asking the agent to be more careful.

Here is the deal: the actor that performs the work should not own the meaning of its own evidence.

The kernel gained task dispatch and task judge. At dispatch, it records the task-to-worktree relationship in an append-only, hash-chained journal. The harness works in that worktree, commits, and emits references. Then the kernel reads the committed worktree itself, compares the emitted references with its own dispatch record, materialises the commit, and evaluates the evidence.

The resulting journal entry is CANDIDATE. Never PASS.

A candidate is work ready to be judged. It is not permission granted by the worker that made it.

The approval stamp stays human and out of band. That can feel slower than letting an agent complete the sentence with its own praise. Good. A gate exists to make an important transition harder to fake.

If you want the broader shape of the boundary, the kernel topology explains why workers return a diff while the check port produces the only verdict that counts.

A checklist for finding self-grading in your pipeline

You can find the dangerous shapes without adopting Ranex. Follow a task from dispatch to the word “done,” and mark every place one process supplies both the artifact and its interpretation.

• One wrapper owns task creation and completion. Hunt for a task identifier created by the same process that later marks it complete.
• The worker reports the commit it wants judged. Check whether an independent process reads the worktree or commit itself and compares it with a dispatch record.
• Plugins can arrive through configuration or a package path. List what can load into your harness at runtime. If the list is open, treat that as authority entering through a side door.
• The harness can run without its observer. Remove or unbind the bridge in a disposable environment. Does startup refuse, or does work continue without the boundary?
• A summary becomes a verdict. Separate “the worker says tests ran” from an independently measured result against the committed subject.
• The word PASS appears before a person or separate authority acts. Replace it with a state that says what it is: candidate, pending, refused, or failed.

Do not settle for a diagram where these responsibilities have different labels. Ask which process can write each record and which process reads the artifact from disk. The answers matter more than the labels.

What was actually proven in this slice

SLICE-007 proved the path end to end: dispatch, worker loop, hooks, kernel judgement, evidence, and a journalled CANDIDATE. The gear-mesh end-to-end test ran that loop using a deterministic in-fork model with zero credentials.

That proof is narrow on purpose. It does not claim delegation, clean-room orchestration, confinement, authenticated approval, or a finished product. The slice record says those boundaries remain outside its closure.

It also does not turn an emitted candidate into a universal claim of correctness. Ranex judges work by evidence and executable checks, and it cannot decide whether the target itself was the right target. The owner still owns that judgement.

The close is recorded in docs/adr/ADR-008-fork-opencode-and-bridge-to-the-kernel.md. The slice record is in docs/slices/done/ in the Ranex repository. The fork retained opencode’s MIT attribution. That is one small line with a large habit behind it: say what you used, say what you changed, and do not borrow credit with the code.

Attribution compounds. Especially in a system built to distinguish a claim from its proof.

Questions people actually ask

These answers explain how a harness can be kept from approving its own work.

Why is an agent harness grading itself a problem?

When the same actor can produce work, shape the success path, and declare completion, the check does not independently establish the claim.

How can an AI agent harness be stopped from approving its own work?

The harness can be stopped by letting it produce work and references while a separate kernel cross-checks them against a record it owns.

Does the kernel issue PASS for harness work?

No. The kernel cross-checks the dispatch record, materialises the committed work, and journals CANDIDATE. A human stamp remains out of band.

Your next move

Pick one agent task from this week. Trace its task ID, its worktree or branch, its commit, its evidence, and its final status. Then ask whether the actor that changed the files also had a path to write the final status.

If the answer is yes, do not call the task done yet. Make a separate authority read the committed artifact and compare it with a record it created before the work began.

Try it. Break it. Tell me what broke. If this helps, star the Ranex repository — then leave an honest critique. The critique is more useful than applause.

Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.