Allostatik

The value is in the relationship

Allostatik gives you a working relationship with your AI that compounds — each session builds on the last instead of resetting with every conversation. It's a folder of plain files you own, plus the routines that keep them true.

AI can hand one person the leverage that used to take a team — but only when it's integral to how you work. It has to see how you work, what you've decided, where things stand, and carry that across time; every decision it can't see, it will happily contradict. Out of the box it can't carry any of it in a form you control. Every window opens from zero, or from a summary you never wrote: you re-establish your preferences, re-derive your patterns, re-explain what you're building. Every time.

If that cycle is familiar, this is for you, specifically — not for someone evaluating AI, for someone already deep in it.

You've probably built the fix once already: a rules file. A CLAUDE.md, a Cursor rules file, a filled-in Project Instructions field. The instinct is exactly right — context you author, in plain text, where you can read every line. Now look at yours. It still says something you stopped believing three weeks ago. It's been steering every session since, and nothing told you.

That's a config file: written once, wrong quietly. Nothing checks it for freshness, and it has no way to tell you a rule went wrong — a bad rule doesn't announce itself, it gets enforced, agreeably, until you notice the work bending.

Allostatik is that rules file, grown into a control system, with you as the gate on every change. The rest of this is why that shape.

Even the context you keep is being edited

Resets are only half of it. Long conversations get compacted — a polite word for summarized by something that wasn't in the room when the decision was made. That edit you never see at all. Memory features synthesize what to keep about you — those you can read and prune, but you didn't write them, and neither editor asked what mattered. Call it the invisible hand: an editor you didn't hire, working on the one document you can least afford to have edited badly. Sometimes it drops something you'd have kept. Worse, it preserves a decision you already reversed. At its worst it infers one — takes an offhand remark for a standing preference and writes it down as a fact about you.

The problem was never that AI has no context. It's that you don't control the part it has.

Where the compounding comes from

The routines run at the edges of every session, against files that live in your project — plan, decisions, observations, project instructions; one file, one job. Open: load the files, check every deployed copy against the canonical one, reconcile before work starts. Work: the files are the source of truth, and stale content gets flagged rather than followed. Close: update them, re-deploy, hand off with pointers instead of copies. Every session ends where the next one begins — that's the compounding. It's a rhythm, not a service: the files act only when your AI reads them, and nothing runs in the background. No process, no account.

Why not just write three markdown files?

You could. You should be asking that. The files aren't the invention — they're markdown, and you could write your own folder this afternoon.

But you can't write a standard. The value of the convention is that it's the same one in your next project too.

And the version you write will have the files and not the routines. Everyone builds the capture half; almost nobody builds the maintenance half — the close, where updating the record is the same act as ending the session, so it actually happens; and the drift-check, which compares what's canonical against what's actually deployed. That's where the living part comes in: capture writes the files once; maintenance is why they stay true. It's also the half that decays first, and the half with no error message. Write the files without it and you've built the rules file again. It will rot the same way.

Files that live like this look different from files written once. These rows are from the decisions.md of the project this post was written in (abridged, marked):

Decision Choice Rationale
Acceptance test: one actually-published artifact (s1) The layer is not working until it has produced one published piece. […] A layer built for extensibility with zero output is architecture masquerading as progress; this test is cheap, observable, and fails loudly.
Publish before building the port (s2) The plan's sequence was inverted: plan.md item 4 (one published artifact) is being executed before item 1 (the canonical→derived port) […] Designing the port before deriving a piece once is guessing at requirements […]
Canonical publishing surface is this repo (s1) [AMENDED 2026-08-21 — see "Canonical source vs canonical publication (s4)"] A published piece is a markdown file in comms; syndicated copies derive from it. […] POSSE's actual invariant is one canonical source you own with copies deriving from it […]

Session numbers, an amendment where reality pushed back, the reasoning kept next to the choice. That's what a working relationship looks like on disk: not prose about the project — a record the next session opens from.

What you get

If you want to read exactly what your AI loads — it's files you own. Readable, versioned, portable. No account, no server, nothing lost when a subscription ends.

If you want to know your context is still true — freshness is checked, not assumed. A cheap comparison runs at every session edge, canonical against deployed. Catching a one-line divergence at a boundary costs nothing. Building on one costs a lot.

If you want the window spent on what matters — the window is a budget, not a bucket. A stale convention still sitting in context outvotes the new one you mentioned once. So files load by manifest, knowledge is pointed at rather than pasted, and each close distills the session to a few durable lines.

If you want to switch tools without starting over — your context is the core; Claude Code, Cursor, Desktop are ways of reaching it. A new surface is one adapter, not a restart.

If you want to stay in the loop — automate the mechanical, gate the meaningful. Nothing rewrites your files without your sign-off.

If you want rules that evolve when they stop fitting — a thermostat is homeostatic: fixed target, corrects you back. Allostasis is when the target itself can move, because the right setpoint depends on the season. Stray from a principle once and the files correct you back; stray the same way repeatedly and it asks whether the principle is still right.

That last one is the hard part. Ask a model cold whether one of your rules still fits and it has no grounds to answer; left alone, an AI is homeostatic by default, because correcting you back is the only move it can justify. What changes that is history it can reason over: three sessions of the same correction is evidence, one is noise — and it can only tell the difference if the record exists outside the conversation that produced it.

None of the engineering is exotic. If you build software, you'll recognize the load-bearing conventions underneath — separation of concerns, don't-repeat-yourself, you-aren't-gonna-need-it, ports and adapters — applied to context instead of code.

The rhythm underneath is MAPE-K — Monitor, Analyze, Plan, Execute, over a shared Knowledge base, a control loop from autonomic computing — run as ritual rather than software, with Execute gated on you. Which means it is not, strictly, autonomic anymore. That's the point. The name reads out of that loop: allostat + I + K, the interpretive human gate and the knowledge base. The name's derivation is in the repo's why.md; the fuller design reasoning in concepts.md.

The trade

Two minutes to install, another fifteen or so to get the files saying true things about your project, then a few minutes at each session edge.

Weigh that against what the alternative already charges: an hour lost hunting an old conversation for where a decision got made, work redone because a stale line was still steering, the same context re-explained at the top of every window. You're paying either way. The difference is whether the payment produces anything — and here the close that updates your files is the same act as recording what the session decided, so there's no second artifact to tend. It compounds rather than accrues — and of the options available, it's the one that leaves you the most control.

The gate is meant to move, too. Early on you approve a great deal; as the files earn it, approval shifts from per-step toward per-plan. That one is a direction, not a finished feature.

The routines aren't theoretical, at least. They survived being run on the project this post was written in, session after session — a lower bar than elegance and a more useful one.

Run your own loop

It's built by the system it describes.

It's young and in active development. The installers, templates, drift-check, close/update, handoffs, the migrate routine for existing projects, in-place upgrades for existing installs (new in 0.3.4), and the shipped skills all work; cross-surface deploy guides and an allostatik upgrade command are still to come, and the repo's Status section stays current on what does and doesn't.

Start at the repo: github.com/allostatik/allostatik. The README walks the setup end to end and why.md makes the full case — follow it from there rather than from this post. The short version, from your project root:

npx allostatik init .

pip works the same way:

pip install allostatik && allostatik init .

And there's plain shell, nothing installed first:

curl -fsSL https://raw.githubusercontent.com/allostatik/allostatik/main/init.sh | sh -s -- .

On a fresh install, every path places the same files and prints the pointer block that ties your project to them. (Already running Allostatik? init refuses to overwrite and routes you to the in-place upgrade instead.) This is it, whole:

This is an Allostatik project. The canonical files in its allostatik/ folder — project-instructions.md, workflow.md, plan.md, decisions.md, … — are the source of truth. At the start of a session, read them, follow workflow.md, treat them as authoritative, and flag anything stale rather than just following it. If they aren't set up yet, help me set them up — github.com/allostatik/allostatik is the reference.

Paste it into your project's instructions — the same field your rules file lives in now; on Claude Code or Cursor the placed CLAUDE.md / AGENTS.md already carries it — and the first session walks you through the rest. It sits beside your code rather than woven into it, and removing it is deleting the folder and the pointer files it placed.

Run it on your own work. Open an issue with what compounded and what broke.

It's open. It's free. The value was always in the relationship — now you get to develop it.


Allostatik is open source (MIT) and lives at github.com/allostatik/allostatik.