Plans that stop being true

An agent writes a plan in about ninety seconds. It is a good plan. It names the files, the order, the thing to be careful about. You read it, you agree with it, and the work starts.

Three weeks later the plan is still in the repository and about a third of it is no longer true. The module it names got split. The constraint it was written around was lifted. Nobody edited the plan, because nobody was reading it — and the next agent that picks it up will follow it anyway, confidently, into work that was already done differently.

That is the whole problem. Not that agents write bad plans. They write good ones, faster than anyone can keep track of, and the plans quietly rot.

What flanner does

It takes the plan out of the chat and puts it somewhere with a version history. Every revision is kept, so you can read what a plan said before an agent changed its mind, and diff any two.

Then it watches whether the plan is still true. Not by asking a model what it thinks — by looking at your git history. A plan that names files which no longer exist is suspect. One written before forty commits landed on the code it describes is more suspect. When flanner says a plan has gone stale it shows you the evidence, and you can disagree with it.

Three things around that

Flanner Memory holds the smaller, longer-lived stuff a plan does not: the constraint that ruled out an approach, the reason a library was rejected, the fact that staging rebuilds on Sundays. Written as Markdown files you can read, so a later session finds them without being told they exist.

Flanner Skills answers a question nothing else could. Install a few plugins and your agent quietly picks up dozens of skills from three different places, and when two share a name one wins silently. On the machine this was built on, 110 skill packages were installed and 57 were in effect. The other 53 were shadowed, and editing one of those is the usual cause of “my change did nothing”.

Flanner Mesh moves all of it between your team's machines directly, signed and verified. Our servers handle accounts and access. They never see your plans, your memory or your skills, because they never receive them.

What we are not going to do

We are not going to guess. A plan is stale because of something you can check, not because a model had a feeling. A skill is not “unused”, it was not invoked in a window we will name, and we will tell you whether anything was watching during it. Zero uses and zero coverage are different facts and we will not print them the same way.

We are not going to let the agent approve its own work. Nothing installs a skill, activates a memory or accepts a plan revision without a person looking at the exact text. An agent that could approve its own skills would be writing its own instructions, and that is the one line this design will not cross.

And we are not going to hold your content. The client is MIT and runs with no account and no network. If we disappeared tomorrow you would still have every plan, every memory and every skill, as files, on your own disk.

Where it is

`uv tool install flanner`, then `flanner init` in a repository. It registers itself with Claude Code and Codex, and your agent starts filing plans through it without being reminded.

It is early. The parts described here work and are tested; the team tier is the newest and least worn-in. If you try it and something is wrong, the repository is the place to say so.