How to Implement a Stem Cell

Once you accept that memory is not enough, a harder question appears almost immediately:

What, exactly, should govern the movement between memory, context, and action?

That is where implementation begins.

It is one thing to say that a system needs continuity functions. It is another to build them in a form that can actually run. Many good ideas fail at this stage. They remain compelling in explanation but vague in machinery. Builders can feel the truth of the idea without yet knowing how to translate it into a working system.

This is why I find it useful to think in terms of a small architectural unit: a continuity function that can be described clearly, triggered reliably, tested independently, and adapted across systems.

You can call that unit many things. The name matters less than the pattern.

For me, the useful pattern looks like this:

a stem cell is a small, executable continuity unit that governs one class of judgment inside a larger system.

It is not a memory record.
It is not a persona.
It is not just a prompt paragraph.
It is not a philosophical note floating above the code.

It is a runtime unit that decides something important about how the system behaves under continuity pressure.

That pressure may involve retrieval, classification, authority, writeback, drift, scope, promotion, escalation, restraint, or re-entry. The exact domain can vary. What matters is that the function exists to make a specific continuity judgment repeatable rather than improvised.

This is the core implementation insight:

if a system repeatedly needs the same kind of judgment, that judgment should become a first-class unit in the architecture.

Not a note to remember later. Not a sentence buried in a system prompt. A unit.

So what does such a unit need?

At minimum, a stem cell should have six parts.

1. Purpose
What problem does this cell solve?

2. Trigger
What condition causes it to activate?

3. Inputs
What information does it need in order to decide?

4. Rules
What logic does it follow?

5. Negative rules
What must it explicitly avoid?

6. Output
What does it return, change, block, or permit?

That is the minimal shape.

From there, a builder can add more sophistication: priority levels, confidence thresholds, retry conditions, audit logging, fallback behavior, human review requirements, or model-specific variants. But those six parts are enough to make the cell real.

Let’s make that concrete.

Imagine a retrieval-routing cell.

Its purpose is to decide what information should be loaded for the current task. Its trigger might be the beginning of a new task, a major task-turn shift, or a request that clearly crosses domains. Its inputs might include the user request, active project, prior context already loaded, source-of-truth hierarchy, recent retrieval history, and current system state.

Its rules might say something like:

identify the task domain,
choose one primary source,
add support sources only if they materially improve the answer,
prefer already-active relevant context when appropriate,
stop once the packet is sufficient.

Its negative rules might prevent exactly the behaviors that weaker systems fall into:

do not over-read out of caution,
do not under-read out of haste,
do not let a support source outrank the primary source,
do not reopen the entire archive when one scoped object would do,
do not confuse available material with necessary material.

Its output might simply be a context packet: a selected set of memory objects or source references that can now be passed into the next step of the runtime.

That is already enough to implement something meaningful.

Notice what changed.

The system no longer “just retrieves.” It retrieves under judgment. And because that judgment has been given a defined form, the behavior becomes testable and stable.

This is what makes the stem-cell pattern useful.

It turns blurry continuity expectations into explicit behavior.

The same approach works well beyond retrieval.

A classification cell can decide what kind of object a new output is.
A promotion cell can decide whether that object is allowed to move from provisional to more durable status.
A drift cell can detect when current output no longer matches the governing line of the system.
A re-entry cell can determine what minimum continuity packet must be restored before work meaningfully resumes.
A task-turn cell can decide whether the system is still doing the same kind of work it was doing three turns ago, or whether the context should be rebuilt.

Each one solves a different continuity problem. But structurally, they can all be implemented using the same pattern.

This portability is one of the best reasons to work this way.

Because the builder is no longer relying on vague “intelligence” to carry the burden. The burden is distributed into smaller executable judgments.

That distribution matters more than it first appears.

A lot of current AI systems rely on a kind of hopeful centralism. A model is given memory, instructions, and maybe a few helper tools, and then it is expected to figure out most continuity decisions on the fly. Sometimes that works surprisingly well. But it tends to fail at the same fault lines over time:

too much context,
too little context,
wrong scope retrieval,
priority confusion,
canon drift,
writeback bloat,
mixing stable truths with temporary chatter,
and the gradual flattening of distinctions that should have remained protected.

Stem cells help because they reduce the amount of improvisation required in exactly those areas.

They do not remove model flexibility. They constrain the continuity decisions that are too important to leave entirely to improvisation.

This is also why I do not think of them as “just prompting.”

A builder can certainly prototype a continuity function in prompt form. In fact, that is often how the idea first gets tested. You can ask a model to classify, summarize, detect drift, or route a task according to a written policy. That is a good early stage.

But if the function matters enough, it should not remain prompt-only forever.

Why?

Because prompt-only logic is soft in the wrong places.

It can be ignored partially.
It can be followed inconsistently.
It can be crowded out by other context.
It can grow bloated over time.
It can become dependent on model temperament instead of system behavior.

That is fine for experimentation. It is not enough for core architecture.

Core continuity behavior belongs in code, middleware, orchestration logic, or some other explicit enforcement layer.

That does not mean everything needs a giant framework. Builders can implement stem cells at several levels of maturity.

Level 1: Prompt-prototyped
The cell exists as a clear written policy and is invoked deliberately in prompts or workflows. This is useful for design testing and conceptual validation.

Level 2: Middleware-enforced
The cell becomes part of the application layer or orchestration layer. It runs before or after the model call, selecting context, applying rules, or deciding writeback behavior.

Level 3: System-native
The cell is part of the core architecture. It participates in routing, storage, retrieval, state transitions, and audit behavior across the system.

Not every builder needs to start at Level 3.

But many systems stall because they never move past Level 1. They discover something real, document it beautifully, and then leave it in advisory form for too long.

The implementation question is what helps break that stall.

To implement a stem cell well, a builder should ask:

What exact continuity failure is this cell meant to prevent?
What event should cause it to activate?
What does it need to know in order to make a good decision?
What would “correct behavior” look like from the outside?
What are the specific failure modes we want to block?
What should happen next if the cell succeeds?
What should happen next if the cell abstains, fails, or defers?

Those questions make the cell practical.

They also make it easier to explain to other builders.

This is another reason implementation patterns matter: they create portability without requiring total sameness of purpose.

A writer-facing AI system may implement a classification cell to distinguish between notes, canon, scene drafts, and unresolved questions.

A companion-oriented system may implement a drift cell to detect when the model’s tone or relational posture has moved too far from its governing line.

A research tool may implement a promotion cell to decide which findings should be added to durable project memory and which should remain ephemeral.

A provenance system may implement a writeback cell that records process lineage only when certain thresholds are met.

Different systems. Same pattern.

The specific values, domains, and outputs will change. But the architectural move remains recognizable: identify a recurring continuity judgment and turn it into an executable unit with defined behavior.

That is the pattern I would encourage more builders to notice.

Not because every system should use the same names. Not because every architecture needs the same moral center. But because many builders are already reinventing fragments of this pattern without giving it a stable form.

They build a retrieval filter here, a memory rule there, a handoff policy in one corner, a ranking exception in another. Over time they realize they are not merely building tools around a model. They are building behavioral governance around continuity.

At that point, it helps to stop pretending these are only helper scripts.

They are part of the system’s judgment architecture.

And once you recognize that, you can design more deliberately.

You can write cells to be composable.
You can let one cell hand off to another.
You can separate retrieval logic from classification logic, authority logic, and writeback logic.
You can log their decisions.
You can test them in isolation.
You can make them portable enough that another builder can adapt the pattern without inheriting your exact system.

That, to me, is what makes this approach strong.

It treats continuity as something that deserves its own machinery.

Not just more memory.
Not just better prompts.
Not just clever context assembly.

Machinery.

Small, disciplined, inspectable machinery that sits between memory and behavior and helps a system remain itself under pressure.

So if I had to give one practical recommendation to builders who are beginning to think this way, it would be this:

Start by identifying one continuity judgment your system keeps making badly. Then turn that judgment into a small executable unit.

Do not try to build an entire philosophy stack on day one.

Pick one recurring failure.

Maybe your system over-fetches context.
Maybe it confuses brainstorming with canon.
Maybe it writes too much back into memory.
Maybe it loses the thread after task shifts.
Maybe it does not know when to stop promoting vivid but low-authority information.

Take that one failure and ask: what cell would prevent this if it existed?

Then define its purpose, trigger, inputs, rules, negative rules, and outputs.

That is enough to begin.

Architecture does not always emerge from grand design.

Sometimes it emerges from one recurring judgment being finally given a proper body.