Reason Once, Reuse Many Times

There is a strange economics at the center of how most teams use AI today. Frontier models keep getting more capable, and more expensive, and the standard architecture pays that premium on every single request — including the thousands that a far cheaper model could have answered, and the ones that are near-identical to a problem the expensive model already solved yesterday. We rent the smartest thing in the building and use it to answer the door.

The usual response is to pick a side of a false choice. Either send everything to a large cloud model and accept the bill, or run a small local model and accept the drop in quality. The first is expensive at scale; the second struggles the moment a task needs real planning, contextual judgment, or multi-step reasoning.

There is a third path, and it is not a compromise between the two. It is the shape FloMorphic already draws, pointed at cost: many small models doing the bulk of the work, a growing memory of reused reasoning doing the heavy lifting, and a frontier model reserved for the rare problem that genuinely needs one. The result approaches the quality of the expensive path at a fraction of the cost — and, done right, it is more transparent than either extreme, because the decision of which intelligence to spend is itself a visible one.

The important part, and the reason this belongs on this blog, is that none of it is a new product you install. Each layer is a shape you draw on a runtime you already have.

The core idea: reason once, reuse many times

Here is the whole thesis in one line.

Reason once, reuse many times.

An expensive model, asked to design an architecture or untangle a claim or reason through a legal edge case, produces something valuable — and in almost every system alive today, that value is discarded the instant the response is rendered. The next similar question pays full price again. We treat frontier reasoning as a disposable output when it is closer to a capital asset.

Flip it. Generate high-quality reasoning with a powerful model once. Store the reasoning itself — the chains, the decisions, the workflow it implied. Feed that back to small local models, and let them execute the next hundred similar tasks against the accumulated intelligence. The frontier model becomes a teacher that shows up occasionally; the local models become the executors that do the daily work.

If that reframe sounds familiar, it should. It is the same move we made about owning a model: the expensive thing to own was never the weights — you rent those — it is the learning layer, the accumulated context and traces of your own work. Nadella's word for a firm was "a learning system," and you cannot outsource your learning. Reasoning reuse is that principle pointed at cost: the reasoning your organization has already paid for is yours to keep, and keeping it is what makes the cheap models look smart.

The four layers — and why each is a shape, not a feature

This architecture reads like a diagram with four layers. The temptation is to think each layer is a component you'd go and build. It isn't. On the runtime this blog is about, each one is a composition of the same small set of primitives — the same way reflection, debate, and self-critique turned out to be shapes rather than features nobody had to implement.

Layer one — the local small models. Quantized Llama, Mistral Small, Gemma, Phi: fast, cheap, private, running on hardware you already own. They handle routine conversation, extraction, classification, and simple reasoning. In flow terms a small model is just a model node — a bounded participant in the graph, scoped to the slice of context it may read and write, proposing an answer inside a corridor drawn before it ran. There is nothing special about it being small. It is a node like any other.

Layer two — the reasoning library. This is the layer that does the real work, and it is the Company Brain wearing a different hat. It stores prior frontier-model conversations, reasoning chains, domain expertise, retrieved documents, and structured memory — and makes them reusable context for the small models. Building it is the same unglamorous pipeline as any brain: ingest, clean, extract, embed, tag, store, keep current. Retrieval out of it is not a subsystem either — RAG here is a vector-store read node wired into a model node's scope. The library is drawn, fed, and queried as flows.

Layer three — the premium reasoning. GPT, Claude, advanced reasoning systems — reached for complex planning, novel problems, architecture, the genuinely hard call. Structurally this is not a different kind of thing from the local model; it is another model node, reached over the same MCP boundary the runtime already speaks. What makes it "premium" is not its wiring. It is when the graph decides to fire it.

Layer four — the orchestration engine. The layer that decides which model handles a request, when to escalate, how much context to supply, and whether stored reasoning can answer without any new call at all. This is described as "the brain of the ecosystem," and on this runtime it is the least exotic layer of the four, because it is just the graph. Routing which model runs is tag-on-transition routing — the same mechanism every flow uses. The orchestrator is not a component you bolt on top. It is the topology itself.

Which is the point worth sitting with: the multi-model economy is a diagram. You do not install it. You draw it.

The observer: a concept you stamp by drawing it

Here is the pattern that makes the "shape, not a feature" claim concrete, and it is the one that convinced me this whole architecture wanted to live on a canvas.

Draw a loop. Inside it, a model node — say a small local one — does some work: drafts a summary, proposes a classification, takes a first pass at a claim. Now place a second model node as the next step in the loop, and give it one job: look at what the first node just produced and judge it. Did it miss something? Is the confidence real? Should this go around again, or is it done?

That second node is an observer. Nobody implemented an "observer feature." You made one by arranging two nodes and an edge — and having made it, you can name it, save it, and reuse it. The designer stamps a new concept into existence by drawing its topology. That is what FloMorphic means when it says reasoning is a composition, not a node: reflection, verification, staged escalation, second opinions — each is a shape built from the same parts, drawn where a person can read it.

And notice what the observer unlocks for the economics. The moment you can cheaply put one model in judgment over another, escalation stops being a guess. The observer is exactly the node that decides "this is beyond the small model — send it up." Which is the same logic, drawn the same way, as pausing a flow to consult a human only when their expertise genuinely adds value. Escalating from a small model to a frontier model, and escalating from a model to a person, are the same move: an autonomous path that runs until a condition says this one needs more, then routes up. In this architecture that condition is a visible edge, not a hidden branch buried in a control loop.

The context is a snapshot you can restore

There is a concrete mechanism under the word "reuse," and it is worth naming, because it is what makes reused reasoning physical rather than aspirational.

Think about how a virtual machine handles memory. You snapshot a running VM — VMware, VirtualBox, whatever — and its entire live state, RAM included, freezes into an artifact you can store, copy, and restore later. Restore it and the process doesn't start over; it resumes exactly where the snapshot was taken, still holding everything it had learned.

Reasoning reuse works the same way, for the same reason. Everything a flow is thinking — the reasoning traces, the conversation history, a summarized digest of a long message stack — lives in one place: the run's context, a single live document the flow reads and mutates. That context is the process memory of the agent. And because it is a first-class, persisted object rather than variables trapped inside a function call, it behaves like a RAM snapshot: you can freeze it, store it, and bring it back.

So "reason once" is literally a snapshot. A frontier model works through a hard problem, and the reasoning it produced is now sitting in the context. Snapshot it. Next time a similar problem shows up — maybe inside an entirely different workflow — restore that memory into the new run, and a small model picks up holding what the expensive one already figured out, instead of booting from a blank machine. The process memory is always available, and it is not owned by the run that created it. Another flow can mount it.

This isn't a feature bolted on to make the point. It is the nature of the runtime. Resumption is an execution primitive here — a run can park, persist its whole state, and continue later on the exact context it held, which is the same capability that lets a flow wait three days on a human and resume as if no time passed. Snapshotting reasoning for reuse and pausing to consult a person are, underneath, one move: the context is durable, portable, and restorable. Reason once, snapshot, restore anywhere.

Where the money actually goes

The traditional architecture is a straight line, and every request pays full fare:

User → Large Model → Response

The reuse-first shape puts the expensive step where it belongs — last, and conditional:

User
  ↓
Small local model
  ↓
Reasoning library  ──► answer, if a prior reasoning fits
  ↓
Premium model      ──► only if the problem is genuinely new
  ↓
Response

When most requests are routine and many resemble problems already solved, the outcomes follow: the large majority of traffic never touches a paid API, spend drops sharply, common tasks get faster because they run locally, and more of the work stays private on your own hardware. The frontier model becomes the exception it should always have been — reserved for the small fraction of requests that truly need frontier-level reasoning.

The savings are real, but the more durable win is architectural: because the routing is a drawn graph rather than a black-box classifier, you can see and change where the money goes. A cost ceiling, an escalation threshold, a "never send this data type to a cloud model" rule — each is a node on a visible path, editable without a redeploy, not a constant compiled three layers into a service.

What it looks like in practice

Take a software team, since it is the example everyone feels.

Without this architecture, every design question and every code review goes to GPT or Claude. The quality is high and the cost scales linearly with headcount — the more the team ships, the more you pay, forever.

With it: a frontier model is asked once to produce high-quality architecture guidelines and review standards. Those get stored in the reasoning library. From then on, small local models run the daily code reviews against that stored expertise, with an observer node checking each review's confidence. Only the unusual case — a genuinely novel design decision, a review the observer flags as beyond the small model — is escalated up. Most of the work runs locally, at local cost, while holding a standard that was set by frontier-model expertise. You paid the expert once and kept the lesson.

This is the same reframe A Practical Path Forward made about code: the scalable path is rarely "throw a bigger model at the whole thing from scratch." It is to give the system a higher-level asset to work from — there, operational primitives; here, reasoning it has already paid to produce.

Collective intelligence, drawn as a graph

One consequence of the multi-model shape is worth naming on its own. Different models are good at different things — one at mathematics, one at code, one at long-context analysis, one at prose. A system like this can route a problem to several specialists and synthesize their outputs into one answer, and intelligence emerges from the collaboration rather than from any single larger model. It resembles distributed computing: many modest machines solving what we used to reserve for a supercomputer.

On this runtime that is not a new capability to build. Multi-agent orchestration is a composition — one graph fanning out to sub-graphs that run in genuine parallel, with a barrier that waits for every branch and merges their results into shared context. A supervisor coordinating three specialist models is exactly that shape. And because the same event stream traces every branch back onto the nodes that produced it, a collective of models stays as auditable as a single one. Collaboration does not cost you visibility.

The honest difficulties

None of this is free of hard parts, and the architecture is more credible for naming them.

Context management. Reasoning histories grow large and disorganized fast. The answer is the same discipline any Company Brain needs: structure and tagging on the way in, not a heap you grep later.

Reasoning quality. Bad reasoning stored in the library propagates — a wrong lesson, reused a hundred times, is worse than a wrong answer used once. The observer pattern is part of the defense: judge reasoning before it is filed, not just before it is served.

Knowledge drift. Stored reasoning goes stale as the facts under it change. A brain that confidently tells you last quarter's truth is a liability, which is why "keep current" is a standing flow, not a one-time load.

Routing correctness. Choosing the right model for each request is its own intelligence problem, and a router that sends too much upstream erases the savings while one that sends too little erases the quality. The mitigation is that the routing is visible — a drawn decision you can inspect, measure, and tune — rather than an opaque heuristic you can only trust.

Security. A shared reasoning repository is a concentrated asset and has to be governed like one. Here the scope boundaries the runtime already enforces on every node — what each participant may read and write — are the same mechanism that keeps the library from leaking across flows it should never touch.

Every one of these is a genuine engineering problem. But notice the pattern in the answers: each mitigation is a property of the runtime and the drawn graph, not a new framework. The problems are real; the tools for them are already in the box.

Where this is going

The near future of this architecture is a hierarchy that mostly runs itself: self-improving reasoning libraries, automatic model routing that learns from its own hits and misses, dynamic cost optimization, specialized expert small models, and persistent organizational memory — with only a thin sliver of requests ever reaching frontier-level reasoning. Enterprises end up owning an intelligence layer that is cheap to run because it rarely spends the expensive resource, and defensible because every decision to spend it was drawn where someone can read it.

The larger claim underneath is the one this whole blog keeps returning to. The path to better AI is not only bigger models. It is better systems around models — and the most economical of those systems treats intelligence as something to accumulate and reuse, not consume and discard. It is that principle made concrete: many small models, guided by occasional expert reasoning, drawn as shapes on a runtime you own, collectively approaching the quality of solutions far larger and far more expensive.

Reason once. Reuse many times. Draw the rest.

Repo: github.com/FloMorphic/getting-started

Concepts and docs: inflowenger.com/flomorphic

New here? The argument this rests on starts with The Model Proposes, the Graph Decides, and the memory layer it leans on is Your Company Doesn't Need Its Own LLM. It Needs a Brain.