flmnt → builders
Decide what your product sends to the model, on every call.
If you're shipping your own AI product, the context you assemble is your biggest lever on both spend and accuracy — and it's the part most teams hand-roll. The SDK gives you the same record that sits behind our coding-agent integration, with the assembly under your control.
@mmmnt/flmnt-sdkthe SDK · in your product
@mmmnt/flmntthe toolchain · on your machine and in CI
Anatomy of one call
Three phases, and you own two of them.
A model call is the middle of a sandwich. What happens either side of it determines what the call costs and whether the answer is right. Most context bugs and most surprise invoices live in those two phases.
Phase 01 · beforeyou control this
Assemble the context, under a budget you set
Instead of sending everything you have and hoping it fits, you ask for what matters for this call and cap what it may cost. The record is queried against the task, not concatenated.
- Ask by relevance, not by recency — the record returns what bears on this task, including the reasoning behind it.
- Cap the spend per call — set a token budget and the assembly stays inside it. A record ten times larger doesn't produce a prompt ten times bigger.
- Get current decisions only — anything that was replaced is history and isn't served, so your product can't act on a version your users abandoned.
context assembled for one callwithin budget
Phase 02 · the callyour model, your provider
Your call, unchanged
This phase is yours. The SDK's job is the context that goes into it and the decisions that come out of it — the two phases either side.
Phase 03 · afteryou control this
Write back what the exchange decided
The half that usually gets skipped. When a call produces a decision — a preference, a constraint, a change of direction — it goes into the record with its reasoning, so the next call starts from it instead of rediscovering it.
- Record the decision, not the transcript — storing every message gives you a bigger haystack. Storing what was decided gives you something to serve.
- Supersede explicitly — when a new decision replaces an old one, say so. The old one stays readable as history and stops being served from that moment.
- Keep the reasoning — the why is what stops the same question being re-litigated on the next call, by your product or by your user.
What the record gives your product
Not retrieved text. Decisions, with their reasoning and their status.
Current, not merely similar
supersession
A query returns what is true now. Replaced decisions are history: readable if you ask for them, never served by default. Your product can't quietly act on something your user changed last month.
The reasoning travels
why, not just what
Each decision carries why it was made and why the previous one stopped applying — which is what lets your model explain itself rather than just comply.
Bounded by construction
spend control
Assembly is capped by the budget you pass, so per-call cost stays predictable as a user's history grows. That's the property that makes long-lived accounts affordable. The economics →
It outlives the session
persistence
The record is not conversation state. A decision made in one session is available to the next one, weeks later, without replaying anything that led to it.
Where this came fromThe SDK is the same context layer we run in production behind our own delivery work, not a repackaged demo. It exists because we needed to control what a product sent to the model before and after every call, and hand-rolling it kept producing the same two bugs: stale context served confidently, and prompts that grew until they were expensive.
Two packages
One reads the record from inside your product. One drives it from outside.
They're separate installs for separate jobs, and they read and write the same record. Neither is required to use the other, and neither is required to use the MCP integration your team's coding agents connect through.
the SDK
@mmmnt/flmnt-sdk
For the product you're shipping. Assemble context under a budget before a model call, write back what the exchange decided after it. Runs wherever your application runs.
npm install @mmmnt/flmnt-sdkUse it when your users' decisions need to survive their sessions.
the toolchain
@mmmnt/flmnt
For driving flmnt flows outside an application — locally while you work, and in CI. The same record, reached from the command line rather than from your product's runtime.
npm install -D @mmmnt/flmntUse it when the work happens in your terminal or your pipeline rather than in a request.
One record, three ways inThe MCP integration for the coding agents your team already runs, the SDK for products you build, and the toolchain for your terminal and your pipeline. A team can use one, two or all three; they are reading the same decisions.
For product teams