Who is it for, and who isn't it for?

For teams running coding agents across more than one person, projects that have outlived the decisions they started with, and regulated teams that need the record to show what was true when. Not for a one-off script, a weekend project, anything that fits comfortably in one context window, or teams looking for a faster way to search chat history.

I already keep ADRs and a CLAUDE.md. Why do I need this?

Because the file is only as current as the last person who remembered to edit it. Research on instruction adherence found context files tend to lower task success while adding more than 20% to inference cost. Keep your ADRs, and keep CLAUDE.md — as a short, static guide to the project's tooling. The decisions themselves move to flmnt, where the current one is served and the replaced one is history.

Why pay when free memory tools exist?

Free tools are good at recall: they'll find what someone said. They aren't built to know a decision was replaced, and they're built around one developer and one agent. flmnt 's unit is the team, and its job is currency — serving what's still true, and retiring what isn't, for everybody at once.

My decisions aren't in the repo. Won't my agent miss them?

The principle is right: what an agent can't see, it can't use. flmnt makes decisions visible through MCP, so your agent reads them the way it reads your files — without anyone maintaining a document. On the pull request, a CI worker writes the decision history in beside the code.

What happens to my data?

It stays yours. Your decisions are your team's record, exportable at any time, and never used to train anything. Enterprise deployments meet your data-residency and retention requirements.

flmnt — Your whole team. Every agent. One version of the truth.

Mar 4 Planning Priya

The team picks Redis for session caching.

Priya writes it into the ticket and into CLAUDE.md so every agent starts from it. Good practice. It is the last time anyone touches the file.

Six months of shipping. Every agent, every session, reads the file first.

Sep 11 Priya

Priya overrules it. In-process cache, 30-second TTL. Redis is dropped.

Right call: one instance per tenant now. Written in the ticket, in Slack, in the architecture note.

CLAUDE.md is fourth on a list of six. CLAUDE.MD · UNCHANGED SINCE MAR 4

Thu Sep 13 11:02 Omar Cursor

Omar's agent reads the file and rebuilds the Redis path.

It read what was true in March. The work is clean, tested, and exactly as instructed. It answers a question the team stopped asking on Tuesday.

Thu Sep 13 16:40 Priya

Review catches it.

What review doesn't catch: it happens again on the next task, and nobody can say which of the two decisions any agent is holding right now.

Your AI keeps using the plan you already changed.

Not forgetting. Remembering the wrong version, confidently. Across 466 projects, about half of committed AGENTS.md files had already gone stale — and stale instructions make agents worse, not neutral.

Sep 15 09:10 Priya connected

Priya connects flmnt. Everyone keeps the tools they have.

No SDK required, no rewrite, nothing to learn. A config entry per tool, and the record starts filling from the first session.

Sep 15 09:24 import

The project's conversations come in.

Existing decisions and their reasons, so the record starts full instead of empty.

Sep 15 09:31 Priya Claude Code

One MCP entry. Priya's agent reads and writes the team record.

Sep 15 11:02 Omar Cursor

One MCP entry. Omar's agent, same record, no change to how he works.

Sep 15 14:40 Priya Web

The team workspace: the record as people read it.

What's current, what it replaced, and why.

Sep 15 CLAUDE.md · repurposed

The file stops carrying decisions. It becomes a short, static reference.

CLAUDE.md now tells agents how to use the project's tooling — how to reach flmnt for the current decisions and their reasons, how to work with Feature and the rest — at the project and repo level. Decisions live in flmnt. The file rarely changes again, and nobody babysits it.

Sep 18 Priya Claude Code

Priya changes another decision: the job queue moves from BullMQ to pg-boss.

She says it once, in her own tool. flmnt records the new decision, the reason, and that it replaces the old one.

Sep 19 Omar Cursor

Omar's agent asks how jobs are queued. It gets Sep 18, with the reasoning.

Nothing re-explained, nothing pasted in. A correction made once holds for everybody, in every tool, in every session after it.

Sep 22 Ines joins Codex

Ines's agent starts from where the team actually is.

Not from a README that was true in March. From the current decisions, and why they were made.

Sep 24 Omar Cursor

Omar's agent reaches for a fix that already failed in July. flmnt says so.

What went wrong is part of the record, so agents stop repeating it.

Sep 30

Month end. The cost of remembering stays flat as the project grows.

Agents get the part of the history that matters for the task, not the whole history. When the history outgrows the context window, pasting it in stops being an option at any price.

The economics, in detail →

The test measured, not promised

Back to caching. One question, asked of two systems, many times over.

The Sep 11 note never mentioned Redis. Nothing in the words said "this replaces that."

Similarity searchserved Mar 4 · retired · every timeNot broken. The old note was still the closest match.
flmntserved Sep 11 · current · every timeIt records that one decision replaced another, so the old one is history, not a candidate.

See the benchmark

Oct 1 Priya, Omar, Ines go further

The team talks through the next feature: metered billing.

Three people, three agents, one thread. By the end, four decisions are in flmnt with their reasons, the moment they were said.

Per-tenant metering on API callsdecided · why: matches how customers think about cost
Bill monthly, on the 1stdecided · pro-rata for mid-month upgrades
Overage is blocked, not billeddecided · a surprise invoice costs more than a blocked call
Three days of grace after the capdecided · gives support time to reach the customer

a second timeline

Oct 2 Omar Moment

The conversation becomes a domain design, with time in it.

Moment translates the decisions into billing.moment: what exists, what can happen, and when. flmnt supplies the four decisions the design rests on.

Tenant · UsagePeriod · Invoicethe things
UsageRecorded · CapReached · PeriodClosed · InvoiceIssuedthe events
When PeriodClosed → issue the invoicea policy
Period boundary on the 1st · grace timer, 3 daystime, made explicit

harness · design layerDomain modelingTurns what the team decided into a design of how the business works, with time in it. The decisions come from flmnt.moment.

Oct 2 16:10 Priya Moment

The design asks a question nobody had answered.

What happens to usage recorded during the grace window? Priya decides: count it, never bill it. A fifth decision goes into flmnt, with the reason, before a line of code exists.

harness · design layerThe design asks backA design asks the questions a conversation skips. The answer goes into the record before any code exists.moment.

Oct 3 Omar Facet

The design is run before any code exists.

Facet plays three scenarios through billing.moment. Two behave. One doesn't: the invoice policy fires before the grace timer has expired.

A normal monthholds
Cap reached mid-monthholds
Period closes during gracecontradiction · invoice issued too earlyFixed in the design, where fixing is cheap.

harness · verification layerDesign verificationRuns the design before code exists. Contradictions surface here, where fixing them is cheap.

Oct 3 17:30 Omar Facet

Re-run. All three scenarios hold.

The design is verified. Its state and the fix that got it there are in the record.

harness · verification layerVerified, and recordedVerified state lives in the record, so nobody has to remember whether the design was checked.

Oct 4 Priya, Omar, Ines

The team agrees the verified design. Now they're ready to build.

A person decides what is agreed. billing.moment v1 · agreed joins the record beside the five decisions it implements.

Oct 6 Omar Feature

Discipline holds: the specs are written before the build.

Three specs, each saying what the agent will build and exactly what it may change. The tests come from the specs. Feature checks them against the design and finds two names that don't match Moment's events.

metering.featdraftRecord usage per tenant per call; may touch /billing/metering only.
period-close.featdraft · 1 mismatch → fixedClose the period on the 1st; issue the invoice after grace.
invoice.featdraft · 1 mismatch → fixedIssue and deliver the invoice; pro-rata rules.

harness · specification layerSpecificationWrites down what will be built and exactly what it may change, then checks the specs against the design.feature

Oct 6 18:05 Priya Feature

Priya flips the three specs from draft to agreed.

Only a person can. From here, the agents know exactly what "done" means.

harness · specification layerAgreement, by a personSpecs flip from draft to agreed only when a person says so.feature

Oct 7 – 8 Omar · Cursor Ines · Codex

Two agents build in parallel, against the same record.

Omar's takes metering and period-close. Ines's takes the invoice. Neither is told the rules twice.

Oct 8 10:22 Ines Codex

Ines's agent asks: what happens to usage over the cap?

It gets Oct 1 — blocked, not billed — and the Oct 2 grace decision that refines it, with both reasons. Nobody re-explained anything.

Oct 9 Priya CI worker Feature

The pull request arrives. Priya doesn't open the diff first.

The same pull request, without the harness

A large diff1,400 lines · 23 filesNo statement of what it was meant to do.
A tickettwo sentencesWritten before the decisions changed.
The reviewerreconstructs intent, line by lineReads everything, then guesses whether it was the right thing to build. Trust gets decided here, at the most expensive point.

With it

metering.feat · period-close.feat · invoice.featagreed Oct 6What the work promised, and exactly what it was allowed to change.
reportpassing · nothing touched outside the specsFeature's report: the delivered work honors the promise.
decision historyposted by CI · 5 decisions, all currentThe decisions this work rests on, beside the code, where reviewers already are.

She confirms the promise, then confirms it was kept. Style goes to linters and other agents. Trust was decided before the build, where it's cheap — not after, where it's the bottleneck.

harness · specification layerProofProves the delivered work against the agreed spec, and reports it on the pull request.feature

Don't review the code. Review the agreement.

What this timeline shows is harness engineering: the structure around an agent that decides what it reads, what it may touch, and how the result is proved. flmnt is the context and memory layer of that harness — every artifact and every agent reads the same current decisions, and why. Domain modeling, design verification, and specification are its other layers, and flmnt has a sibling for each. Each one is optional. Together, they are the whole harness.

Explore the workflow

Nov 3 Priya Claude Code

Support asks for more time. Grace moves from three days to seven.

Priya says it once. flmnt records the new decision, the reason, and that it replaces Oct 1's. Then the change travels.

flmntgrace · 7 days · current · 3 days → history
Momentbilling.moment · grace timer updated · v2
Facet3 scenarios re-run · verified
Featureperiod-close.feat · re-agreed by Priya

harness · all layersCurrency across the harnessDesign, scenarios and specs stay current with the record. One change, every artifact.moment.

Nov 4 Omar, Ines every agent

Every agent on the team gets seven days. None of them was told.

The file, the design, the scenarios, the spec, and the record agree. One version of the truth, held current, everywhere.

Where every leg ends

The harness runs on what you decided.

Every layer above it — the design, its verification, the specs, the proof, and every agent doing the work — reads the same current decisions and the reasons behind them. That layer is flmnt: the context and memory of the harness.

It doesn't stop when the feature ships. The team's entire project context now lives outside any one agent's context window: written, stored, immutable, and available to the whole team. The lifecycle continues, and flmnt holds the state of the project through all of it — what was decided, what changed, what's true now. That is the view leads and managers have been missing.

The industry answers agent output it can't trust with more review. flmnt 's answer is to decide trust before the build, where it's cheap, and make the check afterwards mechanical.

Request access Explore the workflow