Getting an agent to produce decent prose is trivial these days. The hard part, the part I keep getting stuck on, is letting it act without wishing I hadn’t afterward.

Once an agent can send an email, issue a refund, alter infrastructure, or move money, I stop caring how assured the model sounded. Two more tedious questions immediately matter instead: did the action happen twice, and why was the agent permitted to do it in the first place? Those turned out to be different enough that I split the work into two Rust projects. FamilyClaw is my answer to the first. Aethel is my attempt at the second, and it is still wrong in places I can name.

FamilyClaw began with a crash

Imagine the standard shape of an agent doing something outside itself. It calls a service, the service carries out the action, and then the agent records locally that the action occurred. Between step two and step three there is a gap: the outside world has already changed while your durable state still says it has not. Kill the process in that gap and the agent returns, reads its journal, sees no completion record, and repeats the whole operation.

If the effect was creating a test file, fine, nobody cares. If it was a refund, a customer email, or removing production infrastructure, you find out very quickly how much you care.

So FamilyClaw is a Rust runtime for agents that require durable execution and duplicate-avoided external dispatch. I did not want to prove that with a polite unit test where everything shuts down cleanly, so the harness SIGKILLs the process in exactly that window: external effect finished, completion record not yet written. A completely new process then starts, reloads durable state, and carries on.

Running it on 2026-08-10 from a clean checkout:

exit 0

side_effect_overcount = 0

approval_payload_match = PASS

proof_receipt = f76edbd2588397a0

runtime = 66.7s

The important line is side_effect_overcount = 0.

The harness also preserves an intentionally broken older execution path. Aim it at that path and the effect happens twice. I kept it because a benchmark that cannot detect the bug I claim to have fixed proves nothing.

FamilyClaw has about 2,000 passing tests and zero Clippy warnings, and I have two agents running on it nonstop as Discord bots.

I prefer being narrow over being flashy here. I am not claiming universal exactly-once execution across arbitrary distributed failures; that is far stronger than what the implementation earns. What I will stand behind is this: FamilyClaw gives at-most-once external dispatch across the crash and replay windows covered by its durability protocol, and when a case is truly unclear it fails closed rather than guessing.

Repository: https://github.com/Sisuthros/familyclaw-oss

Then I hit the second problem

None of that helps if the agent was poised to do the wrong thing exactly once.

A model can emit an account number, an amount, a filename, a destination address, an API argument. Generating the value does not make the value true, and adding “make sure this is correct” to a system prompt does not change that either. That is where Aethel came from.

The idea is intentionally plain. Model output begins as Claim<Order>. An effect that spends money might instead demand Verified<Order, RefundPolicy>. Those two should not be interchangeable: give a raw Claim<Order> to a function that expects the verified type and the program ought to fail. Not “the model should probably avoid it,” and not “we wrote a rule about it.” It should not type-check.

That part works. Sadly, that is also the sentence where my description used to get ahead of the code.

Repository: https://github.com/Sisuthros/Aethel

So I attacked it, and then spent eleven days repairing what broke

On 2026-08-10 I wrote 33 adversarial cases against my own type checker, because I wanted to know what a hostile person would find before I began asking people for money rather than after.

Thirteen were rejected properly. Twenty slipped through. That was a bad result, and it forced me to stop describing the Claim<T> / Verified<T, Policy> split as a security boundary, because I had plainly not earned that.

Here is where it stands now, 2026-08-21, measured by running the release binary against every fixture instead of trusting a commit message. Each of the twenty bypasses became a fixture. Eighteen live in examples/breakers/required.tsv, which pairs each one with the exact diagnostic code the checker must emit, and the remaining two live in known-gaps.tsv with a written explanation. CI now reads both files and prints the count on every push: seventeen of the eighteen required cases are rejected with the exact code demanded, not merely rejected in some vague way. Counted against the original twenty, seventeen are closed. Evidence-kind checking was wired in correctly, through the lexer, the parser, the semantic checker and check_verify, so the checker now distinguishes a policy that was merely named from a policy whose evidence requirement was actually stated.

Three issues are still open, and they are in the repository rather than hidden in a note:

breaker-016-unused-claim still passes, and it is four lines:

fn unused_claim(c: Claim<int>) -> int {

let x = 42;

return x;

}

The function receives an untrusted Claim<int>, ignores it entirely, and returns a number. Run the checker on that file today and it replies ✓ breaker-016-unused-claim.aet type checks and exits zero. Linear consumption of a Claim is not enforced yet, so a claim can be dropped on the floor instead of being verified or explicitly discarded, and nothing objects. That is a real live bypass, it is in the repository, and you can reproduce it in about thirty seconds.

breaker-020-scope-escape does not get through, but it also does not fail cleanly. The checker overflows its stack instead of issuing a diagnostic, which means the scope-escape path is unbounded recursion rather than a rejection I can reason about. A crash is not a security property.

breaker-009-evidence-mismatch is rejected, but verify() still cannot take evidence terms in the surface syntax, so the fixture cannot express the thing it is meant to test. That gap is recorded in examples/breakers/known-gaps.tsv with its rationale.

One note about the gate itself, since this project is entirely about not claiming what you have not checked. Until yesterday CI was matching fixtures against a hardcoded list that only knew the first eight, so the manifests beside them were being ignored and the suite was reporting a pass it had not earned. I discovered that while writing this page, which is basically how these things are always discovered. The step now reads the manifests, and any fixture appearing in neither one fails the build, so a new hole cannot quietly join the set. The build is currently red, intentionally, at breaker-020. I could have moved that fixture into known-gaps.tsv and shown you a green badge instead. That option is always there, and it is exactly why a green badge means very little by itself.

The hardest remaining problem is not on that list, though. Rust’s type system stops helping the instant a value leaves the process. The compiler can tell me something was Verified<T, Policy> inside Aethel; then it gets serialized, and FamilyClaw receives bytes. At that boundary I need more than “trust me, this used to have a nice type.” I need proof that travels with the action.

What I am actually trying to build

The end-to-end path: model output, then Claim<T>, then policy verification with evidence, then a verification witness bound to that specific value, then a FamilyClaw effect request, then the witness rechecked at the execution boundary, then the approval and policy gate, then durable external dispatch, and finally a crash-safe receipt.

The split of responsibilities is straightforward. Aethel answers what must be proven before an action is permitted. FamilyClaw answers how to execute an allowed action without accidentally repeating it when the process dies. I built them separately. I now think the interesting project is the seam between them.

What I am asking funding for

Six months of full-time work. The target is $30,000 and the minimum is $8,000. I want the work judged by a scoreboard rather than by adjectives, so here is the scoreboard.

Finish the remaining ones, and make the gate genuine. When I first wrote this page I set the goal at fifteen of the twenty bypasses. Seventeen are closed, so that target is gone and the honest version is harder: all twenty rejected with their exact diagnostic, the CI harness reading required.tsv and known-gaps.tsv instead of a hardcoded list, and any fixture that appears in neither manifest treated as a build failure so a new hole cannot slip past the gate unnoticed. Concretely, that means linear Claim consumption for breaker-016, bounded scope resolution for breaker-020 so it emits a diagnostic instead of overflowing the stack, and surface syntax for evidence terms so breaker-009 can express what it is testing. A fix counts when the attack stops working, not when I have changed some code and felt pleased about it.

Make verification survive the compiler. A successful Aethel verification should output a witness tied to the actual value, the policy, and the evidence used. That witness travels with the effect request, and FamilyClaw refuses to execute when it is absent, invalid, or does not match the payload being executed. This is the biggest technical part of the project, and the one that turns two interesting repositories sitting side by side into a single safety boundary.

Publish the attacks. The 33-case suite is a good seed for a public adversarial benchmark. I want to extend it and run equivalent failure cases against FamilyClaw+Aethel and at least two widely used agent frameworks, wherever a fair comparison exists. I am not interested in a rigged leaderboard. Frameworks promise different things, and a framework failing a test for a property it never claimed is not some grand defeat. What I want is a benchmark where you can see that this system prevents this failure, that one does not, and here is the executable case that demonstrates it.

Get it out of my room. At least two outside teams running the stack on real agent workflows. This one matters to me more than it probably sounds. I know my own assumptions too well, and a safety system that survives only the imagination of the person who wrote it is not much of a safety system. I expect outsiders to find things I missed, and I will publish those too.

Why six months is a defensible estimate

I am not starting from a paper and an empty repository, and I would rather show a rate than make a promise. FamilyClaw exists, the crash harness exists, I can run it and hand you a receipt, and I can deliberately switch it to the broken implementation and watch the duplicate appear. On the Aethel side, the eleven days between the audit and this sentence closed seventeen of twenty discovered bypasses. The three that remain are the ones I would expect to be slow, because each needs real analysis rather than a patch: linearity, bounded resolution, and surface syntax for evidence.

The remaining difficulty is not “improve AI safety somehow.” It is narrower: how do I make a verification result impossible to forge, bind it to the exact value being authorized, carry it across a process boundary, and make the runtime refuse the effect when the proof does not survive the trip? I do not have every answer to that yet. That is the research risk, and I would be skeptical of this proposal myself if I claimed otherwise.

About me, and about how the work gets done

I work on this alone in the sense that matters for a grant: no company, no team, no prior funding, and nobody else’s money at risk. Both projects are Rust.

I should be straightforward about something a funder would discover anyway, and which I think is the most interesting part here rather than the most awkward. I do not write all of this code by hand. I run a small team of AI coding agents. A large portion of the work that closed those seventeen bypasses was done by an agent working through the fixtures while I reviewed the results. This is also the point of the project: I am asking for money to build infrastructure that makes agent-executed work verifiable, and the way I build it is agent-executed work that I verify. The reason known-gaps.tsv exists at all is that I do not accept an agent’s report as evidence any more than Aethel accepts a model’s output as a verified value. Every number on this page comes from me running the binary and reading the output myself, not from an agent telling me it succeeded.

The most useful thing I can tell you about how I work is probably not the crate count or the test count. It is what happened on August 10. I was writing this page, and I had a prettier version of the Aethel story ready. Then I attacked my own type checker and twenty of thirty-three attacks sailed straight through it. For a few minutes that was a pretty awful result. Then it became the most valuable thing I had, because I finally knew where the claim stopped being true, and I could revise the claim.

I would rather give someone funding this project twenty ugly failing test cases than bury them under the phrase “trustworthy AI.” Eleven days later, seventeen of those cases are closed and three are documented in the repository with their reasons. FamilyClaw’s crash result is something you can reproduce. Aethel’s remaining failures are something you can reproduce. The funding is for shrinking the distance between those two facts.