Aethel + FamilyClaw: proof-carrying execution for AI agents

I started building this because I kept running into the same uncomfortable problem with AI agents.

It is relatively easy to make an agent produce good text.

It is much harder to let it do something real without eventually regretting it.

The moment an agent can send an email, issue a refund, change infrastructure or touch money, the interesting question changes. I care less about whether the model sounded confident and more about two very boring questions:

Did the action happen twice?

And why was the agent allowed to do it in the first place?

I ended up building two separate Rust projects because I think those are actually two different problems.

FamilyClaw handles the first one.

Aethel is my attempt at the second.

FamilyClaw started with a crash

Imagine an agent doing this:

1. call an external service

2. the external service performs the action

3. write down locally that the action happened

There is a nasty little gap between 2 and 3.

The outside world has already changed, but your local durable state still says it has not.

Kill the process right there.

When the agent comes back, it can look at its journal, see no completion record and do the same thing again.

If the effect was writing a test file, nobody cares.

If it was a refund, a payment, an email to a customer or deleting production infrastructure, you care very quickly.

This is the problem I built FamilyClaw around.

FamilyClaw is a Rust runtime for agents that need durable execution and duplicate-prevented external dispatch.

I did not want to prove this with a polite unit test where everything shuts down nicely.

So I made the process die.

The crash harness uses SIGKILL inside the exact window I care about: the external effect has already happened, but the normal completion record has not been written yet.

Then a completely fresh process starts, reloads the durable state and continues.

My run on 2026-08-10 from a clean checkout produced:

exit 0
side_effect_overcount = 0
approval_payload_match = PASS
proof_receipt = f76edbd2588397a0
runtime = 66.7s

The number I care about is:

side_effect_overcount = 0

There is also an intentionally broken/old execution path in the harness. Run against that path, the effect fires twice.

I added that because I wanted to know the benchmark was capable of catching the bug I claimed to have fixed.

FamilyClaw currently has roughly 2,000 passing tests and zero Clippy warnings. I also have two agents running on it continuously as Discord bots.

I want to be careful with the claim here.

I am not claiming magical universal exactly-once execution across arbitrary distributed failures. That would be a much stronger claim than the implementation justifies.

The claim I am comfortable defending is narrower: FamilyClaw provides at-most-once external dispatch across the crash and replay windows covered by its durability protocol.

In some ambiguous situations it fails closed instead of pretending it knows something it cannot know.

I think that is the right trade.

Repository:

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

Then I ran into the second problem

Crash safety does not help if the agent was about to do the wrong thing once.

A model can produce an account number.

It can produce an amount.

It can produce a filename, a destination address, an instruction or an API argument.

But the fact that the model produced a value does not make the value true.

And writing "make sure this is correct" in a system prompt does not magically change that.

That is where Aethel came from.

The basic idea is deliberately boring.

Model output starts as something like:

Claim<Order>

An effect may instead require:

Verified<Order, RefundPolicy>

Those should not be interchangeable.

If a function expects Verified<Order, RefundPolicy>, handing it a raw Claim<Order> should simply fail.

Not "the model should probably avoid it."

Not "we wrote a rule about it."

The program should not type-check.

That part works.

Unfortunately, that sentence used to be where my description got too optimistic.

Repository:

https://github.com/Sisuthros/Aethel

So I attacked it

On 2026-08-10 I wrote 33 adversarial cases against my own type checker.

I did this while preparing the funding material because I wanted to know what somebody hostile would find before I started asking people for money.

The result was not flattering.

Thirteen attacks were rejected correctly.

Twenty got through.

That was useful.

It also forced me to rewrite how I talk about Aethel.

Before that test I was getting too close to calling the Claim<T> / Verified<T, Policy> separation a security boundary.

Today I do not think I have earned that claim.

Aethel is currently a useful and fairly strong structural checker for agent effect code.

It is not yet a sound security boundary.

And I can show exactly why.

One example is almost embarrassingly small:

let v: Verified<Order, P>;

An uninitialised binding can currently create a path to a Verified value.

There is another hole where function bodies inside a mod block are not type-checked at all.

And my current verify implementation establishes that a policy was named and that the types match. It does not yet establish that the evidence required by that policy was actually satisfied.

Those are real failing programs now.

Not theoretical future-work bullet points.

Nine of the twenty bypasses reduce to four implementation defects I have already identified and specified fixes for.

The remaining problems are harder and, frankly, more interesting.

The biggest one is that Rust types stop helping you when a value leaves the process.

A compiler can tell me that something was Verified<T, Policy> inside Aethel.

Then it gets serialized.

Now FamilyClaw receives bytes.

At that point I need something stronger than "trust me, this used to have a nice type."

I need proof that travels with the action.

That is the next piece.

What I am actually trying to build

The combined path I want looks roughly like this:

model output
    ↓
Claim<T>
    ↓
policy verification + evidence
    ↓
verification witness bound to that value
    ↓
FamilyClaw effect request
    ↓
witness checked again at the execution boundary
    ↓
approval / policy gate
    ↓
durable external dispatch
    ↓
crash-safe receipt

The division of labour is simple.

Aethel answers:

What has to be proven before this action is allowed?

FamilyClaw answers:

Once the action is allowed, how do we execute it without accidentally doing it twice 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

I am asking for six months of full-time work.

The funding goal is $30,000.

The minimum is $8,000.

I want the work to have a scoreboard, not a collection of adjectives.

First: make the current attacks permanent

The twenty Aethel bypasses become required adversarial CI fixtures.

My target is to close at least fifteen of the current twenty.

Anything still open remains visible as a failing or explicitly tracked case.

I do not want a security fix to count because I changed some code and felt good about it.

The attack has to stop working.

Second: make verification survive the compiler

A successful Aethel verification should produce a witness tied to the actual value, the policy and the evidence used.

That witness then travels with the effect request.

FamilyClaw should refuse to execute the request when the witness is missing, invalid or does not match the payload being executed.

This is the biggest technical piece of the project.

It is also the piece that turns the two repositories into one safety boundary instead of two interesting experiments sitting next to each other.

Third: publish the attacks

The current 33-case suite is a decent seed for a public adversarial benchmark.

I want to expand it and run equivalent failure cases against FamilyClaw+Aethel and at least two widely used agent frameworks where a fair comparison is possible.

I am not interested in manufacturing a leaderboard where my project magically wins.

Different frameworks promise different things.

If another framework never claimed to provide a property, failing that test is not some grand defeat.

What I want is a benchmark where you can see clearly:

this system prevents this failure,

this system does not,

and here is the executable case that proves it.

Fourth: get it out of my room

I want at least two outside teams to run the stack on real agent workflows.

This matters a lot to me.

I know my own assumptions too well.

A safety system that survives only the imagination of the person who wrote it is not much of a safety system.

I expect outside users to find things I missed.

I will publish those too.

Why I think six months is a defensible estimate

I am not starting with a research paper and an empty repository.

FamilyClaw already exists.

The crash harness exists.

I can run it and get a receipt.

I can deliberately switch it to a broken implementation and watch the duplicate appear.

That half of the project has something concrete under it.

Aethel is earlier.

But after the adversarial audit, it also has something concrete under it now: twenty failures.

I know which attacks pass.

I know the root cause of several of them.

I know which fixes are small.

And I know where the problem becomes genuinely harder.

The hardest remaining part is not "improve AI safety somehow."

It is much more specific:

How do I make a verification result impossible to fabricate, bind it to the exact value being authorized, carry it across a process boundary and make the runtime refuse the effect when that proof does not survive?

I do not know every answer to that yet.

That is research risk.

I would be suspicious of this proposal myself if I claimed otherwise.

About me

I am building this alone.

No company.

No team.

No previous funding.

Both projects are written in Rust.

I think the most useful thing I can tell you about how I work is probably not how many crates or tests I have.

It is what happened on August 10.

I was writing this funding page.

I had a nicer version of the Aethel story.

Then I attacked the type checker.

Twenty of thirty-three attacks got through.

For a few minutes that was a fairly terrible result.

Then it became the most useful result I had.

Because now I knew where the claim stopped being true.

So I changed the claim.

I would rather show somebody funding this project twenty ugly failing test cases than hide them underneath the words "trustworthy AI."

FamilyClaw's crash result is already something I can put in front of you and ask you to reproduce.

Aethel's failures are also something I can put in front of you and ask you to reproduce.

I am asking for funding to close the distance between those two facts.