I built OAEF after months of working on DietAgent with AI agents. The agent wrote code fast, but every session started from scratch. It didn’t remember what we’d decided the day before. And when it didn’t know something, it made it up.

Humans aren’t that different. Anyone joining a project spends days asking why things are the way they are. The answer is rarely written down. When it is, it’s somewhere nobody thinks to look.

OAEF fixes both in the same place: the repo itself. It’s open source under Apache 2.0, and the code is on GitHub .

Everything the project knows lives in the repo

On DietAgent, I started writing everything down inside the repo. The rules lived in a file every agent reads first, AGENTS.md. The app’s spec and a doc for each area sat right next to the code. And at the end of every session, the agent left a note for the next one: what changed, why, what was still open and how to check it.

It worked so well that I wanted it in my other projects. OAEF is that way of working, packaged up. When it lands in a project, it sets up the agents’ contract, folders for specs and decisions, memory between sessions and an index of the docs.

The index is the part I use the most. It tells the agent which doc to read for each task. Instead of opening the whole folder, the agent reads only what it needs, and the context stays free for what matters.

Memory lives in two plain text files, versioned with the code. One holds the note from the last session. The other is a log that only grows. No vector database, no containers.

The order of trust

In a project built with agents, sources disagree all the time. The docs say one thing, the code does another, and the agent believes whatever it read last. So OAEF has a rule for who wins.

The compiler beats the tests. The tests beat the code. The code beats the docs, and the docs beat memory. At the very bottom sits hallucination, which counts for nothing.

In practice, that settles a lot of arguments. If the docs say one thing and the compiler refuses it, the docs are wrong. If the code compiles and a test fails, the code is wrong. And the agent can’t guess at anything the compiler or the tests can prove.

Put like that, it sounds obvious. But it’s exactly what an agent forgets halfway through a long session, once it’s read a lot and starts trusting what it wrote itself.

One contract for every agent

Every agent tool looks for its instructions somewhere different. Some read AGENTS.md directly, others have a folder of their own. OAEF keeps a single contract and generates the copies each tool expects, always in sync with the original. Today it works with more than 20 agent tools.

It also adapts to the stack. There are 12, from Flutter and Swift to Go, Rust and .NET, each with the test and analysis commands it already uses. On top of that come the skills, ready-made instructions for common tasks like building a screen or reviewing code before a PR.

Then there are the checks that run without anyone having to remember them. Test coverage has a floor, and files and functions have a maximum size. The bar only goes up: once coverage hits a number, it can’t drop below it.

Projects that already exist

Hardly anyone starts from zero, so OAEF goes into an existing repo without rewriting what’s already there. Before touching a single file, there’s a dry run that only shows what it would do:

oaef init --target . --stack auto --legacy --dry-run

During adoption, almost all the new rules start out as warnings, so they don’t break the build. The coverage the project already has becomes the floor, and from then on it can only go up.

What I learned

A good agent with bad context does damage fast. When the repo spells out the project’s rules and what happened in the last session, the agent stops guessing and starts following what’s written.

The person who gets the most out of it is me. When I come back to a project after a few days away, it’s all there, down to the reason behind each decision.