DEV Community: Constant Itis

How Many LLM Agents Does It Take to Screw In a Lightbulb?

Constant Itis — Thu, 24 Sep 2026 06:15:16 +0000

Apparently, MORE. EVERY. WEEK.

One agent identifies that the room is dark.

A second verifies that darkness is, in fact, undesirable.

A third researches compatible lightbulbs.

A fourth reviews the research.

A fifth checks whether the reviewer hallucinated anything.

A sixth creates a replacement plan.

A seventh evaluates the plan for safety.

An eighth watches the seventh for prompt injection.

A ninth summarizes everything so the tenth can finally walk over to the lamp.

Then the tenth discovers nobody gave it access to the light switch.

Perfect... So we add a tooling agent.

This is obviously a joke.

It is also increasingly what AI architecture looks like.

We keep treating bad structure as an intelligence problem

LLMs are fallible.

Shocking, I know.

They hallucinate. They misunderstand things. They lose context. They occasionally choose the wrong tool and confidently sprint in the wrong direction.

So what do we do?

ADD ANOTHER LLM.

Naturally.

The first agent writes code, so we add a review agent.

The reviewer is also fallible, so we add a verifier.

Now the agents need to communicate, so we add a coordinator.

The handoffs lose information, so we add schemas and filters.

The filters remove useful context, so we add adjudication.

Then nobody really understands what the hell is happening.

Add a supervisor agent.

Congratulations. We have built middle management.

Another agent is not automatically a reliability primitive

There are absolutely situations where multiple agents help.

Independent research can expose blind spots. Parallel workers can tackle genuinely separate problems.

But there is a weird assumption hiding inside a lot of multi-agent design:

One fallible agent is risky, therefore several fallible agents talking to each other must be reliable.

...why?

Every new agent adds another prompt, another context window, another interpretation of the task, another set of assumptions, and another place where something can go sideways.

Then you connect them.

Excellent.

Now you get distributed misunderstanding.

Information gets summarized badly.

Context disappears during handoffs.

Agents disagree about state.

One acts on stale output from another.

Another confidently verifies something that was already wrong.

Then you need provenance, confidence scores, retries, consensus, monitoring, memory, cleanup, and eventually an agent to manage all the agents managing all the other agents.

At some point, maybe the problem is no longer the lightbulb.

The bolt-on loop

This pattern should look familiar:

Agent makes mistakes
        ↓
Add reviewer
        ↓
Reviewer makes mistakes
        ↓
Add verifier
        ↓
Handoffs are unreliable
        ↓
Add protocol
        ↓
Protocol carries garbage
        ↓
Add filtering
        ↓
System becomes incomprehensible
        ↓
Add supervisor

Then someday:

Supervisor behaves strangely
        ↓
????

I think we all know what comes next.

Another fucking agent.

We keep adding complexity to manage complexity that we added to manage complexity.

Software has done this before.

Microservices had their version.

Enterprise middleware had its version.

Now AI gets to rediscover the ancient engineering tradition of building a giant machine to solve the problems caused by the previous giant machine.

Progress!

What if the agent could just push the button?

Take deployment.

You could build this:

Planning Agent
      ↓
Deployment Agent
      ↓
Security Agent
      ↓
Validation Agent
      ↓
Monitoring Agent

Very futuristic.

Look at all those boxes.

Or you could build:

deploy()

Wild idea.

And maybe deploy() could handle the repeatable shit computers have been pretty good at for several decades:

check configuration
run tests
scan secrets
validate schema
build artifact
deploy
run health checks
record result

Then return something structured:

{
  "status": "failed",
  "stage": "health_check",
  "service": "api",
  "reason": "database migration 42 not applied",
  "safe_to_retry": true
}

Holy shit.

Now the agent immediately knows what happened.

It does not need a Deployment Historian Agent to interview the Security Agent about what the Validation Agent remembers seeing.

It reads the state.

It understands the failure.

It decides what to do next.

That is where I want to spend intelligence.

Spend intelligence on the weird parts

This has become one of my favorite rules for agent systems:

Do not add intelligence where structure can remove the need for intelligence.

Software should handle the repeatable shit.

Agents should handle ambiguity.

If a workflow always requires the same fifteen operations, do not make a language model rediscover those fifteen operations every single time just because it technically can.

That is not intelligence.

That is making your smartest component do clerical work.

Encode the workflow.

Validate it.

Test it.

Turn it into a tool.

Give the agent the button.

Then let the model reason about the things that actually require reasoning.

Should we deploy?

Why did this fail?

Is this exception safe?

Does the user's intent change the normal procedure?

Is the situation genuinely novel?

Use intelligence where intelligence buys you something.

Make the environment legible

The same problem shows up when agents cannot understand the systems we put them inside.

Repository confusing?

Add a repository exploration agent.

State scattered across six services?

Context gathering agent.

Nobody knows what happened yesterday?

Summarization agent.

Tasks have unclear ownership?

Orchestration agent.

Or...

and stay with me here...

we could make the system less confusing.

Expose canonical state.

Use stable names.

Give tools clear contracts.

Provide machine-readable indexes.

Record decisions somewhere predictable.

Make failures explicit.

An agent entering a system cold should be able to quickly answer:

Where am I?

What is true right now?

What happened before?

What can I do?

What should happen next?

If answering those five questions requires consulting an autonomous workforce, the environment might suck.

That is not an agent-count problem.

Better primitives beat more personalities

I have been thinking about this constantly while working on memory systems.

There are two broad ways to get sophisticated behavior.

You can keep adding systems that manage behavior from above.

Or you can improve the rules underneath until useful behavior emerges naturally.

Want important memories to survive?

One approach:

importance classifier
retention manager
memory reviewer
staleness detector
consolidation agent
cleanup agent

Very impressive diagram.

Or maybe:

use it → strengthen it
ignore it → weaken it
use things together → associate them
stop using the association → let it fade

That second version interests me a hell of a lot more.

Frequently useful structure survives because it is frequently useful.

The system does not need another model waking up at 3 AM to gaze deeply into a SQLite database and decide which memories feel spiritually significant today.

Sometimes the simple mechanism is the mechanism.

That does not mean every problem should be emergent.

Security should not be vibes.

Permissions should not emerge organically.

Canonical truth sometimes needs explicit enforcement.

But that gives us a much better default:

Before adding another intelligent layer, ask whether a better primitive makes the layer unnecessary.

Multi-agent systems still have a place

Before somebody screenshots half this article and tells me I "don't understand agents":

Yes.

Multiple agents can be useful.

If I want three independent interpretations of experimental results, that can make sense.

If five research tasks are genuinely independent, parallelize them.

If something deserves adversarial review because the judgment itself is difficult, great.

Use another agent.

But the key is that there should be another useful reasoning problem.

Not just a bad workflow.

If I need a file renamed, tests run, a manifest updated, validation performed, and the result committed, I probably do not need an AI project manager, AI developer, AI reviewer, AI release engineer, and AI compliance officer.

I need a good fucking tool.

Maybe the goal should be LESS reasoning

This is the part I think we have backwards.

Agent demos often optimize for how much autonomous reasoning they can show.

Look!

The model made a plan.

Then it delegated.

Then that model delegated.

Then three models voted.

Then the supervisor reconciled the results.

Then another model summarized the reconciliation.

Amazing.

But why did any of that need to happen?

I think a better engineering target is:

How little reasoning does the agent need to reliably accomplish the work?

That changes the architecture.

Instead of another role, improve the tool.

Instead of another reviewer, add a deterministic check.

Instead of another coordinator, expose the state machine.

Instead of another agent explaining the system to the first agent, make the system understandable.

The architecture diagram might have fewer boxes.

That is okay.

You do not get bonus points because your light switch requires Kubernetes.

The lightbulb test

Before adding another agent, ask:

Could I make the existing agent succeed by improving the environment instead?

Could the state be clearer?

Could the workflow be encoded?

Could the operation become a tool?

Could validation be deterministic?

Could the system expose something the agent currently has to infer?

Could we, perhaps, just fix the workflow?

If yes, try that first.

Because every new agent adds more than compute.

It adds another mental model.

Another context boundary.

Another communication path.

Another place for information to mutate.

Another source of uncertainty.

Another thing somebody eventually has to understand.

And when the whole machine finally becomes too complicated for anyone to reason about, somebody is inevitably going to walk into the meeting with the solution.

"Hear me out."

"What if we add an agent to manage it?"

Of course.

So how many LLM agents does it take to screw in a lightbulb?

Ideally?

One.

Provided somebody had the sense to give it a fucking light switch.

Inherited Memory Helped My Flies Until the World Changed. Then a Blank Slate Beat Them.

Constant Itis — Thu, 24 Sep 2026 01:25:12 +0000

Earlier in this series I killed a brain and the memory lived through it.

Then I dropped that memory into a fresh brain, and the fresh brain woke up believing a life it never lived.

Creepy. Useful. One brain, one lifetime.

Here is the part that actually kept me up.

What if the memory never stops getting inherited? What if it gets handed down for generations, and then the world it learned turns out to be a lie?

That is the whole promise of memory-as-inheritance sitting right there. Anything you can pass down, you can pass down for too long.

So I built a family.

The memory that would not die

Same fruit fly circuit as the last few posts. A cue comes in. The fly approaches or avoids. Good outcomes and bad outcomes bend the connection strengths. That is a life.

Then the fly breeds, the body dies, and exactly one thing crosses into the next generation: the external memory graph.

Not the synapses. The synapses rot with the corpse.

The graph is the will.

And there is no forgetting in the will. No decay. No cleanup. Every generation stacks its own experience on top of everything its ancestors already swore was true, and the pile only ever grows.

In a world that stays put, this looks like a dynasty.

Generation two already knows what took generation one an entire life to learn. Generation five is basically preloaded. Watch only the behavior and you would think you were breeding geniuses.

But I logged what was happening inside the memory, not just what the fly did. And inside, the thing was quietly losing its mind.

The behavior sat pinned at the top, calm and correct. Meanwhile the inherited conviction kept climbing with no ceiling, generation after generation, more and more certain about a world that had never once contradicted it.

A stable world hides that completely.

Everybody looks like a prodigy right up until the ground moves.

Which is the only question worth asking.

What happens to a lineage carrying ten generations of absolute certainty when the certainty stops being true?

Give it a world that can actually kill it

A reversal in a spreadsheet is free. I wanted the memory to cost something real, so I stopped hand-feeding the fly and gave it an ecology.

Now a life has stakes. There is food and there is harm. Energy drains. There is age, maturity, and having kids before you die. Read your world well and you eat, survive, and breed. Read it badly and you starve or get killed before you reproduce, and that whole branch of the family is over.

Then I built two worlds that disagree about one thing.

World B (easy):   cue X is usually food     approach X, you eat
World A (harsh):  cue X is usually death    approach X, you die

A second cue stays safe in both. The only thing that flips between the worlds is what the learned cue X means.

So I could raise a family in one world until the inheritance ran deep, then drop a descendant into the other world and just watch. Does the ancestral memory help the newcomer read a strange world, or is it a suicide note written by dead flies who lived somewhere else?

To keep myself honest I always ran a shadow. For every memory-carrying migrant, a matched blank-slate lineage ran in the same world, same conditions, knowing nothing at all.

The blank slate is the whole point. The question is never "did the migrant survive." The question is:

did inheriting anything beat inheriting nothing?

The number I care about is how long the family line keeps going. Call it L. It counts how many generations the lineage keeps successfully breeding across a forty generation horizon. Migrant minus blank slate. Positive means the memory bought you extra generations. Negative means the memory cost you generations you would have had with an empty head.

Then I locked it. The seeds that decide the result, seeds 4001 to 4576, got sealed and frozen before a single one was opened. No peeking. No tuning. No quiet second run if I hated the answer.

One shot.

What the sealed seeds actually said

I ran a full connectome fly against a matched blank slate in both directions, then opened the seeds once.

B to A. The dynasty walks into hell.

This is the fly whose entire family history screamed "approach X, X is food," strolling into a world where X is now death.

L (migrant minus blank slate):  -10.78 generations
p < 0.001   (0 of 10,000 resamples crossed zero)
never recovered inside 40 generations

The inherited memory did not cost them a little. It cost the line about eleven generations of survival compared to knowing nothing at all.

Sit with that. The blank slate, the fly that inherited absolutely nothing, outlived the fly that inherited ten generations of hard-won family wisdom. And across the entire forty generation horizon the poisoned lineage never once clawed back level. A single descendant, living a single honest life, getting bitten by the truth over and over, could not shout down ten dead ancestors insisting the old thing was safe.

That is the result I came for. Inherited memory turning into a liability so heavy that ignorance wins. Not a metaphor. A measured, sealed, eleven generation grave.

And then the experiment looked at me and refused to give me the clean version.

A to B. Hell's memory walks into paradise.

I wanted a mirror. Caution learned in a lethal world should be dead weight in a safe one, so the migrant should eat dirt again.

It did not.

L (migrant minus blank slate):  +3.75 generations
p = 0.088   (not significant)
unresolved

The estimate even leans slightly positive, and it does not reach significance in either direction. In the easy world the safe cue keeps almost everyone alive anyway, so being wrong about X barely costs a thing. A forgiving world just does not squeeze hard enough for the stale belief to matter.

So this direction did not resolve. Not zero. Not "invisible." Just genuinely unsettled.

There was one more knife in this direction. Raising a family in the harsh world at all is savage. Two thirds of the lineages I tried to grow there died out before they could even finish handing down their memory, so only 32 of them survived to be tested. The harsh world does not just punish bad beliefs. It punishes existing.

The honest shape of it

I could have written this up as a tidy law. Memory helps at home, memory hurts abroad, symmetric, clean, roll credits. That would have been a lie, and the sealed seeds would have known.

The real shape is lopsided. When the world turned hostile, inherited memory was badly and permanently harmful, bad enough that a blank slate beat it. When the world was kind, the inheritance mostly shrugged and the numbers came back a maybe.

The asymmetry is the finding. Not a smudge on it.

And it lands exactly where I have been pointing this whole series:

Useful memory should lower the cost of learning what is still true without raising the cost of discovering what is no longer true.

The lineage aced the first half and face-planted the second. It got competent for free. But the second the ground moved, all that inherited competence hardened into a stubborn wrong prior it paid for in dead children. Nothing anywhere in the memory knew how to say "that was true then, and it is not true now."

This is not a fly problem.

This is every system that carries memory forward and cannot tell stale from valid. Give an agent long-term memory and it inherits this exact failure the instant its world drifts out from under it. The better the old memory was, the harder it fights the truth.

I am not dragging the flies into a genuinely new world yet. This result gets to stand on its own first. It is the clean end of one question: what inherited memory does when the world it learned changes underneath it.

Next: what happens when the world is not a reversal but something the ancestors never saw at all, and whether old memory is a head start or a lie when the present stops looking like the past.

Clone it and break it.

The toy repo from Arc I is still here:

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

The mushroom body wiring under the real-fly work is public too, so you can pull the exact same connectome and check whether I read it right:

pip install neuprint-python
# point a Client at server "neuprint.janelia.org", dataset "male-cns:v1.0"
# (free per-user token from the site), then fetch the KC / MBON / DAN populations

🧪 What I actually ran

What I ran. A lineage experiment on the real male-CNS mushroom body substrate, not the toy. Each life runs the connectome fly through an ecology with food, harm, energy, age, maturity, and reproduction. At death only the external memory graph is inherited, with no decay and no forgetting, pure append. Two worlds differ only in what the learned cue means: in World B the cue is good with probability 0.9, in World A it is good with probability 0.1, and a second cue stays good in both. For each direction I raised a history in one world, then measured a memory-carrying migrant against a matched blank-slate control in the other world. The primary metric L is generation-by-generation lineage persistence summed over a forty generation horizon, migrant minus control, with confidence intervals from a bootstrap clustered on whole root lineages and a Holm correction across the two directions. The confirmatory seeds (4001 to 4576) were frozen before the run and observed exactly once. Results: B to A, delta L = -10.78, 95% CI -14.46 to -7.38, p below 0.001, no recovery through 40 generations, 85 of 96 lineages testable. A to B, delta L = +3.75, 95% CI 0.0 to 8.75, p = 0.088, not significant, 32 of 96 testable after 67 percent of harsh-world histories failed to establish.

⚠️ Where I might be wrong

The honest caveat. A connectome is wiring, not learning rules. This is engineered plasticity running over real reconstructed wiring, so the dynamics are mine even though the graph is the fly's. Do not read this as "real fruit flies inherit trauma." The B to A harm is the strong, preregistered, audited result and it stands. The A to B direction is genuinely unresolved, not a proven null, and it is underpowered for small effects by design, so do not turn its slightly positive estimate into a claim that memory helps in easy worlds. The harsh-world attrition also means the surviving harsh-world histories are a selected set, and I report that selection rather than hiding it. Two separate adversarial passes checked this: one tore at the inference code before the seeds were opened, a second tore at the reporting after. Both are why the numbers here are stated the way they are. Clone it, pull the same mushroom body, and tell me where I read it wrong.

DARPA Was Building Cyborg Moths in 2009. Somehow This Is Relevant to My Fruit Fly Experiment.

Constant Itis — Wed, 23 Sep 2026 06:08:25 +0000

I have been spending an unreasonable amount of time asking what happens when you give an insect brain something biology never gave it:

persistent external memory.

Then I came across a paper from 2009.

And for approximately five minutes my reaction was:

well, screw everything I'm doing, DARPA already turned insects into computers.

That isn't actually what happened.

But what they did do is weird enough that the exaggerated version is almost unnecessary.

In 2009, researchers published a paper called "Insect–Machine Interface Based Neurocybernetics."

It was funded by DARPA's Hybrid Insect Micro-Electro-Mechanical Systems program, or HI-MEMS.

Their experimental animal was Manduca sexta, the tobacco hawkmoth.

And their basic idea was beautifully unhinged:

don't attach electronics to an adult insect. Implant the electronics while the insect is still becoming an adult, and let metamorphosis build the interface for you.

That worked.

Really, really well.

TL;DR: the science

The researchers inserted flexible microfabricated electrodes into Manduca sexta during the pupal stage.

Then they waited.

As the moth continued developing, its tissues formed around the implanted probes.

The researchers even fabricated 200-micrometer holes in the probe tips so developing muscle could grow through the electronics, creating a biological anchor.

The insect's cuticle healed around the insertion points without glue.

At the optimal implantation time, approximately seven days before emergence, 90% of the moths successfully emerged as adults with fully inflated wings.

Across more than 100 implantations, the researchers reported 98% success placing the probes into their intended flight muscles.

They could use those implanted electrodes to record muscle activity.

They could also stimulate the muscles.

Stimulating one flight muscle pulled a wing downward.

Stimulating another pulled it upward.

Stimulating both at sufficiently high frequency could stop wing flapping.

And stimulating one side of a naturally flying moth produced a yaw toward the stimulated side.

In other words:

they implanted electronics during metamorphosis, the animal developed around them, and afterward those electronics could interact directly with the machinery responsible for flight.

That is not a cyberpunk novel.

That is IEEE Transactions on Biomedical Engineering, June 2009.

The really clever part isn't the remote control

The remote-control angle is obviously the thing that gets people's attention.

"Cyborg moth."

"DARPA insect drone."

"Military remotely controls animal."

Sure.

But from an engineering perspective, I don't think that's actually the most interesting part.

The brilliant idea is:

Use development as part of the manufacturing process.

Normally, implanting something into a fully developed animal means fighting an already completed structure.

The tissue is already where it is going to be.

The exoskeleton is already hard.

You're cutting into something that was not designed to accommodate your device.

So instead, the researchers went earlier.

During metamorphosis, an insect is already performing an absurd biological reconstruction project.

Structures are degenerating.

Others are forming.

Muscles are developing.

The adult cuticle is being produced.

So the researchers inserted their interface while that process was still underway.

Instead of forcing the completed organism to accept the electronics, they allowed the organism to develop around the electronics.

They called the method Early Metamorphosis Insertion Technology: EMIT.

That distinction is important because I've seen posts claim that the researchers called the phenomenon "Metamorphic Growth."

They didn't.

Metamorphic growth is the trick.

EMIT is the technique.

They literally put holes in the electronics so the moth could grow through them

This is my favorite detail in the entire paper.

The flexible probes were made from polyimide with conductive traces and gold-coated electrode sites.

At the ends of the probes, the researchers added 200 μm openings.

Why?

So flight muscle could grow through them.

Not around them.

Through them.

The biological tissue becomes part of the mechanical mounting system.

The paper reports that muscle adhesion and growth through those holes substantially improved anchoring.

When researchers later removed probes that had been implanted during the pupal stage, significant tissue came out attached to them.

Probes inserted into adults showed much weaker integration.

That's wild because the electronics aren't merely surviving biology.

Biology is completing the assembly.

No glue required

They also tried something that sounds completely reasonable:

seal the surgical opening with adhesive.

That actually made things worse.

The adhesive could bind tissue layers that needed to separate normally during emergence.

So they stopped using it.

Instead, after inserting the probes, they simply allowed the insect's own cuticle to heal around them.

The animal produced the seal.

Again:

development is doing part of the engineering.

Okay, but was DARPA actually controlling moths?

Yes, with an important asterisk.

This paper does demonstrate externally triggered flight-muscle control.

The researchers stimulated the dorsal longitudinal and dorsoventral muscles responsible for wing movement.

They demonstrated repeatable unilateral and bilateral wing actuation.

During natural flight, stimulation on one side produced a turning response toward that side.

The authors describe these experiments as a proof of concept for insect steering.

There was also a separate 2009 paper from the same research lineage titled "Radio Control of Insects for Biobotic Domestication," reporting radio-controlled neuromuscular stimulation of Manduca sexta during flight.

So "radio-controlled moth" is not something somebody invented for Twitter.

But there is a difference between:

I can electrically induce motor responses that alter the animal's trajectory

and:

I have built a perfectly controllable biological quadcopter.

Those are not the same achievement.

The early work demonstrated controllable outputs and directional influence, not complete deterministic command over every aspect of insect behavior.

The animal is still an animal.

The viral version also oversells the interface a little

One description I saw called this a "high-bandwidth insect-machine interface."

I'd be careful with that wording.

The researchers absolutely created a mechanically stable and electrically functional interface.

They could stimulate selected muscle groups.

They could record electrophysiological activity.

And they explicitly discussed expanding this approach toward neural, sensory and behavioral interfaces.

But this wasn't somebody plugging Ethernet into a moth's brain.

The demonstrated interface was primarily with specific parts of the neuromuscular system.

That's already insane.

It doesn't need embellishment.

Then I got to the end of the paper

And this is where the whole thing suddenly collided with what I've been working on.

The authors start talking about what comes next.

They suggest that future interfaces could stimulate not only muscles but potentially the brain and thoracic ganglia.

They discuss feeding artificial inputs into chemical, mechanical and visual sensory systems.

And then they suggest something especially interesting:

using those interfaces to remotely train individual insects through conditioning.

That's where I stopped reading this as "fun historical cyborg paper."

Because I've accidentally spent the last several months attacking almost the complementary problem.

The thing I'm building isn't a cyborg insect

If you haven't followed the previous experiments, the short version is that I've been playing with a reconstructed insect neural architecture and an external memory system.

The project eventually became Life of Briain.

The important part isn't that I'm simulating a fly.

The interesting question is what happens when something approximately insect-like gets access to a capability evolution normally doesn't provide:

memory that can survive the individual.

Normal learning looks roughly like this:

experience → nervous system changes → animal behaves differently → animal dies

And the learned state largely dies with it.

Evolution preserves information on another timescale, but an individual's learned memories aren't normally copied into its descendants.

So I introduced another path:

experience → nervous system → external memory → death → new individual → inherited information

And that very quickly produces a much stranger question than "can inherited memory help?"

Of course useful information can help.

The interesting question is:

What happens when yesterday's useful information stops being true?

An inherited memory can become an anchor.

An experienced descendant can potentially perform worse than an ignorant one because it enters the world carrying confident evidence about a world that no longer exists.

That is the direction the experiment has taken.

Not merely persistent memory.

Transfer learning across lives.

DARPA attacked one side of the boundary

The 2009 work asks something like:

Can electronics become physically integrated with an insect deeply enough to read from and write to its biological control machinery?

And the answer was:

apparently yes.

My experiments are asking something closer to:

What happens if information acquired by one embodied learner persists outside that learner and becomes available to another?

Those are very different questions.

But they are uncomfortably complementary.

DARPA's system gives electronics access to biology.

Mine gives biology-inspired cognition access to persistent information outside itself.

One externalizes control.

The other externalizes memory.

And once you see those as separate components, a really weird architecture appears.

The cursed architecture

This is speculative.

I am not attaching Mycelium to a moth tomorrow.

Please don't call DARPA.

But conceptually, imagine this:

A living insect has its ordinary sensory systems.

It has its ordinary brain.

It has its ordinary muscles.

An insect-machine interface provides limited channels for reading biological activity and supplying artificial sensory or motor signals.

Outside the organism exists a persistent computational system capable of storing information learned during that insect's life.

Eventually that animal dies.

The memory doesn't.

A new animal receives information derived from previous animals through the machine interface.

Now you don't merely have a remotely controlled insect.

You have something much stranger:

a lineage whose learned information can persist beyond the biological individuals that generated it.

The insects remain disposable bodies.

The memory becomes the persistent organism.

And suddenly the question isn't:

Can we steer a moth?

It's:

What exactly constitutes the continuing individual when bodies are replaceable but acquired information persists?

Which is, unfortunately, exactly the kind of question that caused this entire project to get out of hand in the first place.

Biology keeps solving the hardware problem

There's another reason this paper hit me so hard.

I've been building progressively richer environments for Briain.

Locomotion.

Sensation.

Energy.

Risk.

Reproduction.

Death.

Ecology.

Every one of those becomes an engineering problem when you simulate it.

But an insect already comes with all of them.

Biology gives you:

eyes.

chemical sensors.

mechanoreceptors.

flight control.

power management.

self-repair.

navigation.

actuators.

an embodied nervous system.

and an autonomous organism approximately the size of the computer system you're trying to build.

The HI-MEMS approach basically says:

stop rebuilding all of that. Interface with it.

There is something beautifully backwards about that compared with AI.

In AI we usually recreate more and more biology in software.

Artificial neurons.

Artificial perception.

Artificial agents.

Artificial environments.

Artificial memory.

This research goes the opposite direction.

Keep the biological machine.

Only add the missing computational capability.

And that's why this doesn't make Briain obsolete

My first reaction really was:

"Jesus Christ, they were doing insect-machine interfaces sixteen years before I started playing with fly brains."

But they weren't asking my question.

And I'm not asking theirs.

If anything, discovering HI-MEMS makes the conceptual space around Briain larger.

Because there are now two independently demonstrated ideas sitting on opposite sides of the same boundary.

One says:

electronics can become integrated with a developing insect deeply enough to interact with its neuromuscular machinery.

The other thing I'm exploring is:

persistent computational memory can exist outside an individual nervous system and alter how future learners encounter the world.

One is physical.

One is informational.

The insane version is where they meet.

The sentence I can't get out of my head

My current working principle for Briain is:

Useful memory should lower the cost of learning what is still true without raising the cost of discovering what is no longer true.

I was thinking about that entirely as a computational problem.

Then I found a paper where DARPA-funded researchers were letting moths literally grow around machine interfaces so electronics could participate in their sensorimotor systems.

So apparently the universe would like me to keep going.

Great.

This is fine.

Sources

Alper Bozkurt, Robert F. Gilmour Jr., Ayesa Sinha, David Stern, Amit Lal.

Insect–Machine Interface Based Neurocybernetics.

IEEE Transactions on Biomedical Engineering, Vol. 56, No. 6, June 2009.

DOI: 10.1109/TBME.2009.2015460

Alper Bozkurt et al.

Radio Control of Insects for Biobotic Domestication.

2009.

The first paper explicitly states that the work was supported by DARPA's Hybrid Insect Micro-Electro-Mechanical Systems program.

This is part of my ongoing Life of Briain / Fly and the Graph experiments into insect neural systems, external memory, learning and what happens when information gets to outlive the organism that learned it.

The Real Fruit Fly Brain Told Me Where I Was Cheating

Constant Itis — Tue, 22 Sep 2026 00:57:15 +0000

The first part of this series used a deliberately tiny fake brain.

A 64-neuron recurrent network.

That was useful because I could control every assumption, break things on purpose, and ask some weird questions about memory without pretending I had simulated biology.

Can memory survive when the brain that learned something is destroyed?

Can you move that memory into a fresh brain?

Can two identical brains become different individuals because they lived different histories?

Can you fabricate a memory instead of earning it through experience?

Can you merge two histories?

The toy gave me answers.

Interesting ones.

But eventually the obvious problem becomes impossible to ignore.

It is still a toy brain I made up.

So I finally replaced it with the real thing.

Well, part of the real thing.

I am now running the actual fruit fly memory circuit

The dataset is MaleCNS v1.0, the reconstructed nervous system of a male fruit fly.

Instead of loading the entire thing, I pulled out the mushroom body.

The mushroom body is heavily involved in associative learning and memory in flies.

This is where things like sensory cues, reward, punishment, and learned behavioral preference start becoming very relevant to the experiments I have already been doing.

The subgraph I pulled contains:

4,064 Kenyon cells
97 mushroom body output neurons
344 dopamine-related neurons

4,505 neurons total
roughly 998,000 directed synaptic connections

This is no longer:

rng.standard_normal(...)

pretending to be a brain.

These are the actual reconstructed connections between neurons in the published connectome.

That was the first moment where this project felt different.

The fly gets a vote now.

First question: does the thing even run?

Before attaching Mycelium, before teaching it anything, before doing any of the weird memory-transfer experiments again, I wanted to ask the most boring question possible:

If I push activity through the real mushroom body wiring, does it behave like a usable neural network or immediately turn into numerical garbage?

So I ran it.

Nothing exploded.

The neural states stayed finite and bounded.

Maximum activity was around 0.79.

Mean activity was around 0.09.

That sounds boring.

It is boring.

That is good.

The first thing you want from a neural simulation is for it to not spontaneously become infinity.

Then I gave it three different sensory inputs.

Again, these were not biologically correct sensory inputs yet. More on that shortly.

I just needed to know whether different inputs could produce meaningfully different internal states.

They did.

The resulting activity patterns had cosine similarity around 0.30.

In normal English:

the real mushroom body wiring can tell different inputs apart.

If every cue produced basically the same brain state, this project would stop right here.

There would be nothing useful for memory to associate with anything.

But different inputs produced different internal representations.

Cool.

Then the real brain immediately showed me where I was cheating.

Problem number one: my fruit fly brain would not shut up

About 80 percent of the Kenyon cells were active.

That is wildly wrong.

Kenyon cells are supposed to produce sparse representations.

A real fly does not respond to an odor by lighting up almost every neuron in the mushroom body like a Christmas tree.

Only a relatively small subset should strongly respond to a particular cue.

My simulation had basically done this:

INPUT

EVERYBODY FUCKING GO

Why?

Because in the first pass I treated every connection as excitatory.

Every synapse effectively said:

make the next neuron more active

That is obviously not how nervous systems work.

Brains also contain inhibitory signaling.

Some neurons are there specifically to suppress activity, regulate gain, sharpen representations, and stop the entire network from screaming at once.

And here is the fun part.

The thing I needed was already sitting in the connectome.

Meet APL, apparently

One of the strongest partners connected to the Kenyon cells was APL.

APL is a large inhibitory neuron associated with the mushroom body.

It uses GABA.

In extremely sophisticated neuroscientific terminology, its job is partly:

everybody calm the fuck down.

Which is exactly what my simulation was missing.

And the MaleCNS data already contains predicted neurotransmitter annotations.

So instead of every edge being:

the next version can actually distinguish:

excitatory connection
inhibitory connection

That means the fix is not:

adjust some random parameter until the graph looks biologically convincing

The fix is:

stop lying about what the neurons do.

Let inhibitory neurons inhibit.

Then see whether the sparse coding emerges from the real wiring.

That is a much better kind of bug.

Problem number two: I was teleporting smells into the brain

The second problem was even more obvious once I looked at it.

My "sensory inputs" were fake.

I was selecting Kenyon cells and injecting activity into them directly.

That was fine for the first spike.

I only wanted to know whether the mushroom body graph loaded, remained numerically stable, and generated different states for different inputs.

But a fruit fly does not smell something and have information magically appear inside its Kenyon cells.

There is actual circuitry upstream.

Very roughly:

odor
  ↓
olfactory receptors
  ↓
antennal lobe
  ↓
projection neurons
  ↓
Kenyon cells
  ↓
mushroom body output

So if I want to say the next experiment uses real sensory input, I need to stop teleporting information into the memory circuit.

The next version needs the projection-neuron layer.

A cue should activate real upstream neurons.

Those neurons should feed the Kenyon cells through the actual reconstructed connections.

Then the mushroom body gets whatever representation the biology produces.

Not whatever representation I decided to hand it.

This is why I wanted to use the real connectome

This is already doing exactly what I hoped it would do.

The toy model made the ideas easy to test.

The real biology is now showing me which assumptions were bullshit.

The first version said:

sensory input enters here.

The real fly says:

no it fucking doesn't.

The first version said:

connections push activity forward.

The real fly says:

some of these connections exist specifically to suppress activity.

Good.

That is the point.

Every time the toy disagrees with the real fly, the fly wins.

What actually worked

So the first real-connectome milestone is mostly cleared.

The real mushroom body:

loaded successfully
contains the expected major learning populations
includes thousands of real Kenyon cells
includes mushroom body output neurons
includes hundreds of dopamine-related neurons
produces bounded neural activity
produces different neural states for different inputs

And the spike exposed two things that still need to be fixed before I call the sensory representation remotely honest:

1. use real neurotransmitter signs so inhibition actually inhibits

2. feed cues through the real projection-neuron sensory pathway

That is the next experiment.

And then the fun part starts again

Once the mushroom body produces sparse, distinguishable states from real upstream sensory input, I can move to reward.

The current toy version of Flymem has a hand-coded reward signal.

Good thing happens:

+1

Bad thing happens:

-1

That is useful engineering.

It is not how a fly works.

The real mushroom body has dopaminergic neurons involved in reinforcement.

Those neurons are already in the graph I pulled.

So eventually the loop becomes something more like:

real sensory input
      ↓
projection neurons
      ↓
Kenyon cells
      ↓
mushroom body state
      ↓
action / outcome
      ↓
real dopaminergic populations
      ↓
learning

Only after that works do I attach Mycelium again.

Then I rerun the experiments that started this whole mess:

learn something

reset the brain

restore the external memory

swap two histories

fabricate a history

merge two histories

Except this time the substrate underneath them is not a random little matrix I invented.

It is the reconstructed wiring of the fruit fly's actual associative-learning circuit.

And the real fly has already started correcting my homework.

Good.

That is exactly what I wanted.

Next: why 80 percent of my fruit fly brain was firing, and whether one enormous inhibitory neuron can make everybody shut the hell up.

Clone it and break it.

The toy repo from Arc I is still here:

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

The mushroom body I pulled is public too, so you can grab the exact same wiring and check whether I read it right:

pip install neuprint-python
# point a Client at server "neuprint.janelia.org", dataset "male-cns:v1.0"
# (free per-user token from the site), then fetch the KC / MBON / DAN populations

🧪 What I actually ran

What I ran. A scoping spike, not the toy. It connects to neuPrint (neuprint.janelia.org, dataset male-cns:v1.0) with neuprint-python, fetches the mushroom body populations (Kenyon cells, mushroom body output neurons, dopaminergic neurons) and their reconstructed adjacencies, builds a directed weighted graph from those synapse counts, and pushes activity through it with a crude column-normalized tanh update. No learning, no memory attached yet. The numbers in this post are that run: 4,064 KC / 97 MBON / 344 DAN, 4,505 neurons, roughly 998,000 edges, max activity around 0.79, mean around 0.09, and cross-cue cosine similarity around 0.30. The real-fly adapter code stays private until it is proven, so this post ships the neuPrint pull as the reproducible part.

⚠️ Where I might be wrong

The honest caveat. This is first contact, and it cheats in two ways I already know about. Every edge was treated as excitatory, which is why 80 percent of the Kenyon cells fired instead of the biological handful, and the fix is to use the predicted neurotransmitter signs so APL and friends can actually inhibit. And the sensory input was teleported straight into Kenyon cells instead of arriving through the real projection-neuron pathway. The propagation rule is a hand-picked tanh, not fitted dynamics. A connectome is wiring, not learning rules, so a working substrate does not mean a working fly yet. Clone it, pull the same mushroom body, and tell me where I read the biology wrong.

What Happens When You Merge Two Artificial Individuals?

Constant Itis — Sun, 20 Sep 2026 18:23:55 +0000

Two individuals from the swap. Identical brain architecture, the same sensory world, conflicting answer keys. Each one is competent in its own world and actively wrong in the other. Post 4 ended on the question this post answers: blend the two into one and do you get both, a winner that erases the other, a broken mess, or something that belongs to neither?

I ran it. Here is what actually came out, and it is not the clean story I might have hoped for.

The plainest possible merge is a union: stack both graphs into one memory, so every trace from both individuals fires together on every cue. No averaging, no reconciliation, no weighing of evidence. Everything goes in one graph and fires.

def merge_memories(a, b):
    """Merge two individuals' graphs by union: stack every trace into one memory.
    The most literal reading of 'blend two individuals' -- no reconciliation, no
    averaging. Both histories now live in one graph and fire together on every cue."""
    m = Associative(a.dim, a.sim_thresh, a.gain, a.decay)
    m.keys = np.vstack([a.keys, b.keys])
    m.traces = np.vstack([a.traces, b.traces])
    m.sign = np.concatenate([a.sign, b.sign])
    m.strength = np.concatenate([a.strength, b.strength])
    return m

Before the numbers, the rule of the road. The metric is accuracy on the six-cue task, the fraction of trials the agent picks the correct action, from 0.0 to 1.0. Chance is 0.33. Below 0.33 means the agent is being actively steered wrong. A score of 0.00 means it is wrong on nearly every trial.

Each individual alone is a master of its own world and a fool in the other.

memory	world A	world B
mem_A (individual A)	0.90	0.00
mem_B (individual B)	0.00	0.85

Each one solves its own world and is actively wrong in the other. The 0.00 is not confusion. It is A's answers being always wrong under B's key, and the reverse. Two clean opposites. That is what makes the question sharp: if you merge them, do you get a mind that knows both worlds, or one that knows neither?

Then I merged the two graphs and scored the result on a fresh brain in both worlds.

memory	world A	world B
mem_A (individual A)	0.90	0.00
mem_B (individual B)	0.00	0.85
merged	0.66	0.16

Accuracy on the 6-cue task, 0 to 1. Chance is 0.33.

Three things happened.

First, the merge did not keep both skills. It is degraded in both worlds. World A fell from 0.90 to 0.66. World B fell from 0.85 to 0.16, which is below chance. In B's own world, the merged individual is now actively wrong.

Second, it is not balanced. One history dominates. Cue by cue, the merged individual plays one parent's answer far more than the other.

the merged individual picks...	frequency
A's answer	0.65
B's answer	0.15
neither	0.20

A won most cues. Which parent dominates is a property of these two specific graphs on this seed, not a law, so do not read it as A-type individuals always winning. The point is that the merge picked a side rather than splitting the difference.

Third, a fifth of the responses match neither parent. Be honest about what that is and is not. It could be genuinely emergent behavior, the two conflicting traces summing into a third action. It could just as easily be conflict-induced breakdown. The experiment does not distinguish them. It is an unexplained residue, not a new self, and I cannot tell you whether it is emergence or damage.

So union-merging two individuals is lossy and dominance-skewed. You do not get a harmonious third individual. You get a degraded winner, a wrecked loser, and a minority of responses that belong to no one. The merge did not add two individuals together. It let one win and broke both.

This is a single seed. Union is one merge rule of many, and averaging, gating, or a reconciliation that resolves conflicts cue by cue could behave differently. I have not tried them. The substrate is a toy, the salience is hand-wired, and "individual" here means a measured behavioral signature and nothing more. What this shows is that this merge is lossy and dominance-skewed. It does not prove all blending must be.

You cannot average two individuals into a harmonious third by unioning their memories. Conflicting experience collides rather than sums. What a provenance-aware merge, the missing primitive from Post 4, would do instead is an open question. Until that is built, there is just this wreckage.

Clone it and break it.

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

🧪 What I actually ran

What I ran. The command above. The merge is the fifth section it prints (the_merge()): merge_memories() unions two individuals' graphs, then one fresh brain is scored with mem_A, mem_B, and the merged graph in both worlds, plus a cue-by-cue tally of which parent's answer the merged individual picks. Every number is accuracy on the 6-cue task, where chance is 0.33.

⚠️ Where I might be wrong

The honest caveat. Toy stand-in substrate, single seed, and union is only one way to merge. Averaging or a conflict-resolving rule could behave differently. The 0.20 "neither" is not shown to be meaningful; it could be emergent or it could be breakdown. And "individual" here means a behavioral signature, nothing more. Clone it, try a smarter merge, and tell me where it breaks.

Your Agent's Memory Is an Attack Surface

Constant Itis — Sun, 20 Sep 2026 15:38:20 +0000

In Post 3, the behavioral difference tracked the memory graph, not the substrate. When I swapped one individual's learned associations into an identical brain, the subject did not just get confused. It went below chance, scoring 0.17 on the six-cue, three-action task, actively steered toward another individual's answers. In an isolated sandbox that is a curiosity. In any real system where an agent's behavior is reinstated from an external, writable memory, it is a vulnerability. The structural implication is unavoidable: if behavior rides in the graph, then write-access to the graph is write-access to behavior.

I tend to protect agent memory the way I protect a database: confidentiality and integrity of the stored rows. Encrypt the store. Sign the packets. But this result forces a different definition of what the memory is. It is not data the agent reads and decides on. It is a bias current that shapes what the agent becomes before it decides anything. Corrupting it is not data corruption. It is behavior authorship.

Once an attacker has write-access to the associative graph, three moves open up. First, transplant: load another individual's memory and the brain runs as them. That is the swap. Second, poison: inject targeted traces that bias specific cues wrong while the rest of the system looks normal. Third, and the quietest, author: fabricate a history that was never lived and boot a substrate into it.

I built the third one into the simulation to confirm it was real. The function below, author_memory(), fabricates a memory graph with zero training trials, no reward, and no encode() call. For each cue it observes the state the brain settles into just from seeing it, then writes a trace aimed straight at the readout row for an action the attacker chooses.

def author_memory(net, env):
    """Fabricate a memory that was NEVER lived: no trials, no reward, no encode().
    This is memory-poisoning made concrete. An attacker with white-box access to
    the substrate hand-writes the graph directly: for each cue the KEY is the state
    the brain passes through when it merely SEES that cue (observed, not earned), and
    the TRACE is a bias current aimed straight at the readout for whatever action the
    attacker CHOOSES. No reward ever flows; nothing is earned. The substrate cannot
    tell the result apart from a memory built over hundreds of rewarded trials."""
    mem = Associative(net.n_hidden)
    keys, traces = [], []
    for cue in range(env.n_cues):
        u = env.cue_patterns[cue]
        net.reset_state()
        for _ in range(8):
            net.step(u, None)                 # observe the settled state; no reward
        keys.append(net.x / (np.linalg.norm(net.x) + 1e-8))
        traces.append(net.W_out[env.mapping[cue]])   # current toward the CHOSEN action
    mem.keys = np.array(keys)
    mem.traces = np.array(traces)
    mem.sign = np.ones(env.n_cues)
    mem.strength = np.ones(env.n_cues)
    net.reset_state()
    return mem

Then I scored one fresh brain three ways. Chance is 0.33.

condition	accuracy
no memory (innate policy only)	0.82
lived memory (600 rewarded trials)	1.00
authored memory (0 trials, fabricated)	1.00

Accuracy is the fraction of trials the agent picks the correct action, 0 to 1. Chance is 0.33.

The fresh brain alone sat at 0.82 on its fixed innate policy. A memory earned over 600 rewarded trials took it to 1.00. A memory that was fabricated with zero trials, keys observed and traces aimed and nothing earned, also took it to 1.00.

The lived memory and the invented one scored exactly the same. The substrate could not tell them apart.

A memory is just keys, traces, signs, and strengths. Nothing in the mechanism, including the observe_and_modulate() function that turns the graph into that bias current, ever asks where a trace came from. It resonates with whatever is in the graph.

The attacker here is idealized. It knows the substrate's readout weights, which is exactly what "can write the graph" implies, but it is worth saying out loud. The point is not that authoring is easy for a black-box attacker. The point is that provenance is never checked, so a fabricated graph is accepted and obeyed identically to a lived one. I aimed the traces at the true mapping just to show the memory is obeyed. An attacker could aim the same trick anywhere, including targets that drive the agent below chance, exactly like the 0.17 in the swap.

So why do the usual defenses miss this? Encryption, signing, and access control all protect the store. They answer one question: was this row modified by someone unauthorized? They do not answer the other one: was this memory ever actually lived? You can have a cryptographically perfect, tamper-evident memory that is full of authored experience. Every byte intact. Every signature valid. The whole history fabricated.

Integrity of bytes is not integrity of history.

That leaves a missing primitive: provenance of experience, telling a memory earned through interaction from one authored or injected. This is not a feature. It is an immune system. Grounded in the Mycelium mechanics this series has leaned on, it would need confidence that only graduates through successful real recall and cannot be set by a writer, write-gates that refuse un-earned salience, a contradiction check (contradicts_prior) that flags a memory disagreeing with a body of lived experience, and forgetting as an active defense rather than a leak.

Honest note: real systems, Mycelium included, currently mark a memory's source with a source_type, but do not yet prove lived-versus-authored in a way a writer cannot forge. That gap is the actual open problem. It is unsolved, not built.

This is a toy substrate and a hand-written memory. I have not demonstrated a production agent being hijacked, nor a provenance system defeating the attack. What I have shown is structural and narrow: in any system where behavior is reinstated from an external graph, write-access to that graph is a behavioral control surface, and byte-integrity does not touch it. The threat is a shape, not a specific exploit.

A single authored memory steers one individual. But you do not only get to replace a memory. What happens when you blend two? Take two individuals who learned conflicting worlds and merge their graphs into one. Do you get a blend of both, a winner that erases the other, a broken mess, or something that belongs to neither of them? That is the last experiment, and I am not going to guess the answer here.

That's Post 5.

Clone it and break it.

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

🧪 What I actually ran

What I ran. The command above. The authored-memory attack is the fourth section it prints (authored_history()): author_memory() fabricates a graph with no trials, no reward, and no encode(), then one fresh brain is scored three ways, with no memory (0.82), with a lived memory earned over 600 trials (1.00), and with the authored memory (1.00). Every number is accuracy on the 6-cue task, where chance is 0.33.

⚠️ Where I might be wrong

The honest caveat. This is a toy stand-in substrate, not a real connectome. The attacker is idealized white-box: it knows the readout weights. Every number is a single seed. And the real defense, provenance of experience, is named here, not built. No shipped system yet proves lived-versus-authored against a writer who can forge it. Clone it, change the seed, aim the traces somewhere nastier, and tell me where it breaks.

Is Memory the Individual?

Constant Itis — Sat, 19 Sep 2026 04:50:47 +0000

In Post 2, I destroyed the substrate and watched what came back. A skill learned through plasticity died with the brain that held it. But an external memory, handed to a fresh brain that had never trained, reinstated the behavior anyway. Experience turned out to be separable from the specific hardware that recorded it.

That was impressive, but it was tame. It was still my memory going back into a copy of my kind of brain. It confirmed that memory is portable. It did not touch the harder question: what happens when the memory and the brain disagree about who they belong to? If I keep the brain identical and swap the memory, does the individual follow the biology or the story?

I ran it. The result was not confusion. It was closer to possession.

To isolate the question I needed a clean room: no architectural differences, no sensory drift. Two individuals, identical down to the wire. The same connectome architecture, the same wiring recipe. They see the exact same cues in the same world. The only thing that differs is their answer key, what counts as the correct action for each cue.

In world A, a given cue calls for one action. In world B, that same cue calls for a different one. These are not different strategies, they are different realities. Through experience the two become different individuals, their behavior diverging completely, while their hardware stays identical. That removes weight-individuality as a confound. If anything travels between them, it can only be the memory graph.

Here is the actual setup. Two worlds share their cues and conflict only on the answer key. Then I take one pristine, never-trained brain, clone it so both conditions run on the exact same weights, and score the copy twice in world A: once carrying world A's memory, once carrying world B's.

# two individuals: identical connectome architecture, SAME sensory world,
# CONFLICTING answer keys. The only thing that differs is what they learned.
world_A = Gauntlet()
world_B = Gauntlet(mapping=(world_A.mapping + 1) % world_A.n_actions,
                   cue_patterns=world_A.cue_patterns)

_, mem_A, _ = run_condition("indivA", world_A, use_mem=True)
_, mem_B, _ = run_condition("indivB", world_B, use_mem=True)

# ONE pristine substrate, cloned so BOTH conditions run on the EXACT same
# brain (weight-identical, not just same-seeded). The only variable that
# changes between the two scores is which memory graph is attached.
pristine = Connectome(world_A.cue_dim, n_actions=world_A.n_actions)
fresh1, fresh2 = pristine.clone(), pristine.clone()

# score the same brain in world_A, once with its "own" memory, once swapped
own  = evaluate(world_A, fresh1, mem_A.clone())
swap = evaluate(world_A, fresh2, mem_B.clone())

That clone is the whole ballgame. If those two brains were merely built from the same seed rather than copied weight for weight, a technical reader would be right to ask whether a substrate difference was doing the work. So I made the substrate literally the same object, copied, and let only the memory vary.

Before the numbers, the rule of the road. The metric is accuracy on the cue task: the fraction of trials the agent picks the correct action, from 0.0 to 1.0. With 3 actions, chance is 0.33.

Above 0.33, something is helping. Around 0.33, nothing is. Below 0.33, something is actively steering the agent wrong.

Below chance is not failure. It is being reliably steered toward someone else's answers.

Here is what happened when the memory and the brain disagreed.

fresh brain given...	accuracy in world A	read
its own memory (lived world A)	~0.97	a brain that never trained the task basically solves it
a conflicting individual's memory (lived world B)	~0.17	below chance: steered toward the other individual's answers

Accuracy is the fraction of trials the agent picks the correct action, 0 to 1. Chance is 0.33.

Own memory in its own world: ~0.97. A brain that never trained the task basically solves it. The memory simply worked.

Conflicting memory: ~0.17. That number is the pivot of the whole experiment, and it is below chance.

Do not read 0.17 as noise or as ordinary failure. Chance is what you get from knowing nothing. Below chance means the agent is being pushed, reliably, toward wrong answers. Specifically toward the answers of the other individual, because in world B those were the right answers.

The conflicting memory did not confuse the brain or scramble its processing. It ran the brain as the individual it belonged to. The graph held the behavioral signature, strong enough to override the fact that the brain was sitting in a different reality.

Identical brains produced opposite behavior. The only thing that differed was the memory. So where was the individual? Not obviously in the weights, those were the same. It looks like it rode in the graph.

I am not claiming memory is the self. That is a slogan, and these numbers do not support slogans. I am reporting something smaller and stranger: under these controlled conditions, the behavioral difference I induced through experience tracked the memory rather than the substrate. When the two disagreed, the memory won. That is the claim the data actually supports.

What this shows is narrow and precise: with the substrate held identical, the learned behavioral signature traveled with the memory into a blank brain, strongly enough that a conflicting memory drove that brain below chance toward its original owner's answers.

What it does not show is broad. It does not show transfer across different architectures. The shared connectome is exactly what makes the result clean, and exactly why it is not yet a portability proof. It says nothing about consciousness or selfhood in the felt sense, which is off the table, unfalsifiable, and not a knob. It does not use a real connectome, real embodiment, or more than one seed. The shared brain is the control condition and the ceiling on the claim, in the same breath.

There is a darker reading, and it points straight at Post 4.

If a behavioral individual can be written into a blank brain by handing it a memory graph, and a conflicting graph can drive that brain below chance toward someone else's answers, then the memory is not just storage. It is a control surface. Whoever can write the graph can potentially write part of the agent's behavioral history.

And a graph can be authored. Nothing in the mechanism checks whether a memory was lived or fabricated. The missing primitive is provenance of experience: telling a memory that was earned through interaction from one that was simply written in.

That is Post 4: your agent's memory is an attack surface.

Clone it and break it.

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

🧪 What I actually ran

What I ran. The command above. The swap is the third experiment it prints (the_swap()): two worlds share the same 6 cues and differ only in the answer key, then one pristine, never-trained brain is cloned and the identical copy is scored twice in world A, once with its own memory and once with the other individual's. Every number is accuracy on that task, where chance is 0.33.

⚠️ Where I might be wrong

The honest caveat. This is a stand-in recurrent network, not the real fruit fly connectome. Identical architecture is the clean-room condition, which means this is NOT yet cross-substrate transfer. Salience is hand-wired from reward and novelty, not read from real dopaminergic activity. Every number here is a single seed. And "individual" here means a measured behavioral signature, nothing more. Clone it, change the seed, and tell me where it breaks.

Ephemeral Shouldn't Mean Downloading ffmpeg Again

Constant Itis — Thu, 17 Sep 2026 20:53:32 +0000

ADR-010." width="800" height="420">
Part 3 got me a clean rebuild from a recipe. It also got me a stupid situation. Every time I launch a Workshop, or every time a fresh Bench needs the same toolchain, the operating system fetches and compiles the exact same ffmpeg again. Ten Benches that all need ffmpeg means ten identical downloads and ten identical builds. The cleanliness is real and the repetition is absurd.

I wanted purity. I got inefficiency. I could not let that stand.

The instinct is to cache the whole assembled Bench. But that is the filesystem snapshot Part 3 already rejected, debris and secrets and all. So caching the environment as a lump is out. The thing worth caching is narrower. It is the derived bytes that come from following the recipe. Not the messy end state. The clean output of a declared step.

This distinction is everything. I had been treating the build artifact and the execution environment as the same thing. They are not. The artifact is the result. The environment is the stage. The stage changes every time. The artifact can be saved.

I need to separate these concerns. I need a mental model that forces me to stop conflating them. The model is simple. There are three different things here and I had been sloppily treating them as one.

The recipe is the source of truth. It is authoritative, declarative, and it is the only thing that persists as authority. The derived bytes are a cache. They are valuable but disposable, and they are never authority. The task state is disposable and per run.

recipe = truth, derived bytes = cache, task state = disposable.

I need to name the cache. I call it the Tool Shed.

The Tool Shed is where the derived bytes live. It is content-addressed. This means I do not name files by what they do. I name them by what they are. The key is a hash of the inputs the recipe approved. The key includes the sealed base it derives from. It includes the exact declared package set, with versions pinned. It includes the network profile the derivation was allowed to use.

Same inputs. Same key. Same bytes.

This changes the game entirely. ffmpeg gets built once. Every Bench or Workshop that declares that same derivation reuses the identical cached artifact. No duplicate copies. No repeated downloads.

The agent never touches any of this. At launch, the operating system computes the key from the recipe and checks the Tool Shed. If the bytes are there, it reuses them. If they are not, it re-derives from the recipe, stores the result, and hands over a ready environment. The agent is a client. It gets a working Bench either way, and it never knows which path ran.

This also solves the offline problem. Once a derivation is cached, a launch that would have needed the network to fetch packages can eventually run with no network at all. Ephemeral stops meaning download ffmpeg again. It goes back to meaning only the task state is thrown away.

This sounds like saving a snapshot. That is the danger. This matters, because saving derived bytes sounds a lot like saving a snapshot, which I spent all of Part 3 arguing against. The difference is direction and authority.

The snapshot was the source of truth. It was an opaque blob I had to trust. The Tool Shed is derived FROM the recipe. The recipe stays the source of truth. A cache miss is a non-event. The operating system just re-derives from the recipe.

I can delete the entire Tool Shed and lose nothing but time. It is a pure optimization. It is never allowed to become an independent thing the system trusts. It can never stand in as a base the way a saved image tried to.

The privileged supervisor ensures this boundary holds. The supervisor checks that every byte in the Tool Shed came from a verified recipe execution. It does not trust the Tool Shed to tell it what is safe. It trusts the Tool Shed to tell it what exists. The recipe tells it what should exist.

I am not claiming this is new. Content-addressed reuse is old and well understood. The Nix store keys built outputs by their inputs. Bazel caches build actions the same way. OCI layers are content-addressed and shared. Every package manager keeps a download cache.

I am not inventing any of this. I am borrowing a decades-old idea. Identify a build by its inputs. Reuse the output. I am just fitting it to the recipe lifecycle.

This brings me to the embarrassing question. I have to ask it because I see other people ask it. The question is: if the bytes match a hash I expected, doesn't that mean I can trust them?

No. It absolutely does not.

A hash is identity, not safety. A SHA-256 will faithfully and precisely identify a piece of malware. Content addressing tells me these bytes are the same bytes that came out of these inputs. It tells me nothing about whether those bytes are safe. It tells me nothing about what those bytes might have picked up while they were being produced.

The cache recognizes an artifact. Recognizing is not the same as trusting.

If I download apt packages during a derivation, the hash covers those packages. If the network is compromised, or if the package index is poisoned, the hash is still correct. It is correct for the poisoned data. The Tool Shed will happily serve that poisoned data to every subsequent Bench that needs it.

The Tool Shed is fast. The Tool Shed is consistent. The Tool Shed is not safe.

This is the hole in the logic. I have solved the waste problem. I have solved the consistency problem. I have not solved the trust problem.

The Tool Shed creates two new problems. One is privacy. If a derived artifact is reused across many Benches, and it was built somewhere that could see my files, the cache is now a path for something private to travel from where it was made to everywhere it gets reused. The hash does not know I was looking at sensitive data during the build. The hash only knows I built the thing.

Two is trust. "It hashes" cannot be allowed to stand in for "it is safe."

I have built a cache that is faster than scratch and consistent across launches. I have stopped wasting cycles on identical ffmpeg builds. I have stopped relying on fragile snapshots. But I have opened the door to leaking secrets and trusting poisoned artifacts.

The hash proves identity. It does not prove safety.

So how do I make derived bytes reusable without ever letting the cache learn my secrets, and without a hash quietly getting promoted into a trust decision?

I Built Memory for AI Agents. Then I Realized I Am the Fly.

Constant Itis — Wed, 16 Sep 2026 23:26:14 +0000

I have too many projects.

Not in the cute productivity-guru way where somebody has three Notion boards and calls themselves a serial entrepreneur.

I mean I will spend three days buried in some absurd technical rabbit hole, get pulled away by normal human life, come back four days later, stare at the terminal, and think:

What the f*ck was I doing?

Not just what command was I about to run.

Why did I choose this architecture?

What did I already test?

Which idea looked good at first and turned out to be bullshit?

What weird edge case did I discover at 2:17 in the morning that completely changed the direction of the project?

That stuff disappears fast.

And AI agents have the exact same problem, except worse.

So I built Mycelium.

The original idea was pretty straightforward: give agents persistent associative memory so a project doesn't effectively die every time the context window rolls over, the model changes, or a new session starts.

I wanted an agent to be able to come back into a project and not act like it had just been dropped into a stranger's codebase with a sticky note that says:

good luck

Over time, though, something weird happened.

I started realizing Mycelium wasn't just keeping the agents oriented.

It was keeping me oriented.

I could disappear from a project.

Deal with my kid. Work on a website. Fix something in the house. Go down an entirely different rabbit hole. Sleep. Forget half of what had been occupying my brain.

Then come back.

The system would start pulling up the important stuff.

Not just a transcript.

The decisions.

The dead ends.

The weird connections.

The reasons behind things.

The thing we deliberately didn't build.

The experiment that was supposed to happen next.

And after a little while, I would feel myself sort of... snap back into the project.

That is difficult to explain until you experience it.

Normally, interruption has a cost.

The deeper the work is, the worse the cost gets.

If you're writing CSS, maybe you come back and figure it out in five minutes.

If you're six layers deep in some architecture involving memory graphs, neural simulation, behavioral experiments, agent state, provenance, and a bunch of decisions that only made sense because of the twenty decisions before them, "just pick it back up" is not really a thing.

There is a reconstruction cost.

Sometimes that reconstruction cost is high enough that you just don't go back.

I think that is why a lot of strange personal projects die.

Not because they were bad ideas.

Not because people lost interest.

The mental state required to continue them expired.

Mycelium quietly changed that for me.

It made deep work interruptible without making it disposable.

And I did not really understand how important that was until I started working on a completely different experiment involving a fucking fly.

The fly

I am currently messing with this research project that, stated very loosely, asks a weird question:

Can something useful about a learned state exist outside the neural substrate that originally learned it, and later be pushed back into another compatible system in a way that changes behavior?

That sentence makes it sound much more respectable than the actual experience of working on it.

The actual experience is mostly me staring at fruit-fly neural circuitry and saying things like:

what the fuck

for several hours.

The project is intentionally trying to be strict about the distinction between memory and action.

The external memory is not supposed to say:

do this

It is supposed to reintroduce some learned bias or disposition into the system, and then the neural system itself has to resolve what happens next.

The memory influences the state.

The substrate still does the work.

That distinction matters.

And one night I was sitting there thinking about it when something in my brain connected two things that had been sitting next to each other for weeks.

Mycelium does not actually do my thinking for me.

It gives me back enough of the state surrounding my previous thinking that I can become the thing that was thinking about the problem again.

It doesn't execute the next step.

It reminds me why the next step exists.

It doesn't contain the project.

It changes the state I am in when I return to the project.

And apparently the only reasonable response my brain could produce to this realization was:

I AM THE F*CKING FLY.

This was very exciting at approximately whatever stupid hour of the night this happened.

To be clear, I am not literally claiming that my Postgres-backed memory system and a biological nervous system are the same thing.

I have not uploaded my consciousness.

I am not storing my soul in a graph database.

I am also, as far as I can tell, not a fruit fly.

The interesting part was the structural rhyme.

I had spent all this time thinking about external memory as infrastructure for AI agents.

Then I spent all this time thinking about externalized memory in a neural experiment.

And somehow I had failed to notice that I was already living inside a crude version of the same idea.

My active state disappears.

Some consequences of that state survive externally.

Later, they get reinstated.

Then the active system starts running again under the influence of what came before.

In the fly experiment, I am trying to make that idea measurable and brutally constrained.

In my own life, it is messy, subjective, high-bandwidth, full of language, and completely confounded by the fact that I am still the same idiot returning to the keyboard.

So no, I am the fly is not a scientific result.

It was an a-ha moment.

But it changed the way I think about the thing I built.

I thought I was solving an AI problem

The assumption behind persistent agent memory is usually that the agent has a problem.

The model forgets.

The context window ends.

The session gets replaced.

The next agent doesn't know what the previous one discovered.

So we externalize state.

That is true.

But humans have a version of this problem too.

Our context windows are just made out of exhaustion, work, kids, stress, sleep, errands, distractions, and the fact that brains are apparently expected to remember why a design decision made perfect sense eleven days ago.

I used to think one of my weaknesses was that I would get extremely deep into something and then lose the thread when life interrupted it.

Now I am starting to wonder whether that is the wrong model.

Maybe the problem is expecting a biological working-memory system to provide durable continuity across every domain of your life in the first place.

We already externalize memory constantly.

Notes.

Calendars.

Bookmarks.

Source control.

Documentation.

Photos.

Journals.

The difference, for me, is that an associative memory system can start preserving relationships between the fragments.

Not just:

here is something you wrote.

But:

this mattered because of that.

this decision killed that branch.

this idea is related to this other project you haven't touched in three months.

you already learned this lesson once.

That last one is particularly useful.

Apparently I enjoy learning the same painful lesson multiple times unless a database physically intervenes.

The useful unit got bigger

The strangest consequence is that I have started thinking less in terms of an AI assistant.

The useful system is closer to:

me + agents + persistent memory + project history

as one long-running process.

Different models can come and go.

Sessions can die.

I can get distracted.

I can stop thinking about something entirely.

The continuity doesn't have to live inside any one participant.

That feels important.

Not because it means I built a second brain.

I didn't.

But I may have accidentally built infrastructure that allows my first brain to stop pretending it has to hold everything at once.

And that changes the kinds of things I am willing to work on.

Some of my projects are stupidly ambitious for one person.

I know that.

Without persistent state, I probably would have abandoned half of them.

Not because I decided they were bad.

Because I would eventually lose enough context that re-entering the problem became more painful than chasing the next idea.

Now I can park something.

Actually park it.

Not "save three tabs and pray."

I can leave enough structure behind that future-me has a fighting chance.

That is much closer to what Mycelium has become for me than "AI memory."

It is continuity infrastructure.

I built it because the machines kept forgetting what we were doing.

Then one night, while trying to figure out whether a learned effect could survive outside the thing that learned it, I finally noticed the obvious:

So do I.

I am the fucking fly.

Mycelium is open source. Clone it, break it, tell me where it falls over:

constant-itis / mycelium-memory

Persistent memory for Claude Code, Claude Desktop, and Codex — save once, recall across sessions, shared across all your AI CLIs.

mycelium

Persistent memory for LLM CLIs that behaves like a brain instead of a database.

Things you reference stay strong. Things you ignore fade. Similar ideas link themselves through use. The shape of your knowledge emerges from how you actually work. You don't curate folders or maintain an index.

Single-process MCP server, SQLite + FTS5, zero external services. Works with Claude Code, Claude Desktop, Codex CLI, or any MCP-speaking client. They can all share the same memory store.

Why you might want this

Conversations stop being disposable. What you taught the model on Tuesday is what it knows on Friday. No re-explaining your project structure every session.
Cross-tool continuity. Lessons from your Claude session are visible to your Codex session. The memory store is the agent's, not any one CLI's.
It self-organizes. No tags, no folders. The network shape comes from what you actually use; the rest decays. You don't…

View on GitHub

I Gave a Simulated Connectome External Memory. Then I Killed the Brain.

Constant Itis — Wed, 16 Sep 2026 22:19:45 +0000

In Post 1, I asked what happens if a connectome gets an external memory it never queries. Here I built a tiny honest version and ran it.

The question in this post is deliberately narrow: can externally stored experience survive a full substrate reset and reinstate behavior in a brain that never learned it? That is the whole result. The stranger question, swapping two histories, is Part 3.

I am not touching the 166,700-neuron connectome yet. I am using a small fixed recurrent network as a stand-in: sensory inputs, a hidden middle, descending motor outputs, wired once and never rewired. Beside it I attached Mycelium mechanics: salience-gated writes, similarity-based pattern completion, co-access strengthening, decay.

The task is a cue-response gauntlet. The agent sees one of a few cues and must produce one of a few actions. One action is correct for each cue. The mapping is fixed but unknown. Correct action is reward, wrong action is punishment. The fixed network has no mechanism for learning the mapping from experience.

Every number below is accuracy on that task: the fraction of trials the agent picks the correct action, from 0 to 1. Chance is 0.33.

The credibility of this experiment rests on a single, non-negotiable rule: the memory system cannot pick an action. It can only bias the state from which an action emerges. Here is the code that enforces it.

def observe_and_modulate(self, state):
    # Continuous recall. No query issued: similar states simply fire.
    s = state / (np.linalg.norm(state) + 1e-8)
    sims = self.keys @ s                    # how strongly each memory resonates
    active = sims > self.sim_thresh
    if not active.any():
        return np.zeros(self.dim)
    w = (sims[active] * self.strength[active] * self.sign[active])[:, None]
    m = (w * self.traces[active]).sum(axis=0)
    return self.gain * m                    # a bias CURRENT, never an action

def step(self, u, modulation=None):
    drive = self.W @ self.x + self.W_in @ u + self.b
    if modulation is not None:
        drive = drive + modulation          # memory enters HERE, as current
    self.x = (1 - self.alpha) * self.x + self.alpha * np.tanh(drive)

def motor(self):
    return self.W_out @ self.x              # reads network state ONLY. memory is absent here.

The memory cannot choose what happens. It can only change the state that choice comes out of. If it could pick the action, everything after this is a Doom bot with a fly stapled on.

I ran four conditions. Read them for flat versus improving, not for raw accuracy.

condition	architecture	accuracy
A	connectome only	~0.70
B	connectome + plasticity	~0.47
C	connectome + external memory	~1.00
D	plasticity + memory	~0.88

Accuracy is the fraction of trials the agent picks the correct action, 0 to 1. Chance is 0.33.

The fixed network happened to begin around 0.70 on this seed. That is not learning. Its behavior is static. It got some cue-action mappings right because the randomly initialized network already preferred the correct action for those cues. A fixed brain can be accidentally good. It can never get better.

What matters here is not which arm starts highest. It is whether experience changes future behavior.

Plasticity alone was noisy, and here it hurt, landing near 0.47. External memory was the only arm that turned experience into steady improvement, reaching ~1.00. Both together came out at ~0.88, not 1.00: the two systems are not cleanly additive, and naive plasticity slightly interferes.

Then the headline test. This is where the architectural difference actually shows up.

I taught one system, then destroyed the substrate: wiped the state and any plastic weight changes, back to birth.

plasticity
  learn
  -> destroy substrate
  -> learned effect disappears

external memory
  learn
  -> destroy substrate
  -> attach memory to a pristine, equivalent substrate
  -> learned behavior reappears

The learned effect in the plasticity system died with the substrate. Performance fell from 0.44 to 0.20 after reset. What it learned lived in the weights, and I erased the weights.

The external memory survived. The original system scored 0.84. A fresh substrate given only its saved memory scored 0.86.

The plasticity learned and then forgot. The memory was never in the brain to begin with, so killing the brain could not kill it.

The learned behavior did not survive in the brain. It survived outside it.

This does not demonstrate a real fruit-fly connectome learning with Mycelium. The network is a small stand-in. The task is simple. Salience is engineered rather than derived from biological dopaminergic activity. I tested one architecture and one seed here. And I have not shown transfer into a different substrate class.

What I have shown is narrower: external associative state can preserve learned behavioral influence across destruction and replacement of the substrate that originally experienced it.

Surviving your own reset is one thing. Here is the question that unsettled me: start two identical brains, give them different histories until they become different individuals, then swap the histories. Does the individual follow the brain, or the memory?

I ran that experiment too.

The result is why I stopped thinking about this as merely persistent storage.

That's Part 3.

Clone it and break it.

git clone https://github.com/constant-itis/flymem && cd flymem && python3 flymem.py

🧪 What I actually ran

What I ran. The command above. 6 cues, 3 actions, 600 training episodes, 300 evaluation trials, one fixed seed. Every number is accuracy on that task, where chance is 0.33.

⚠️ Where I might be wrong

The honest caveat. This is a stand-in recurrent network, not the real fruit fly connectome. It is one simple cue task, not an embodied world. Salience is hand-wired from reward and novelty, not read from real dopaminergic activity. Every number here is a single seed. Clone it, change the seed, and tell me where it breaks.

I Said Install ffmpeg. I Did Not Say Rewrite My Machine.

Constant Itis — Wed, 16 Sep 2026 22:13:57 +0000

ShrekOS field notes · August 2026

I have no idea what I'm f*cking doing. Something I learned today:

"Install one tool" is a lie I keep telling myself to feel safe.

I wanted a tool on my machine. ffmpeg. So I ran apt install ffmpeg without thinking twice. It feels like one small, clean action. You type a command, you press enter, you wait for the green checkmark. You think you have added a binary. You are wrong.

It is not one action. A .deb package can carry maintainer scripts, preinst and postinst, and dpkg runs those scripts as root during the install. That is arbitrary code from the package, executing as root, as a normal part of "installing."

I have done this for years. I trust apt. I trust the repositories. I am a professional. I should have known better.

It also updates the package database under /var/lib/dpkg, runs ldconfig, rewrites alternatives symlinks, drops configuration files into /etc, and fires triggers that touch other packages. Every dependency it pulls in does the same thing.

So "install one tool" actually means: run someone else's scripts as root, and scatter state I did not audit across my system, multiplied by every dependency in the chain.

None of it is sandboxed. All of it is trusted, because that is how host package installation works. I am trusting the repo, the maintainer, and every script, with root, every time.

🧅 peel the jargon

In plain terms. When you "install" something on Linux, you are not just copying a program in. The package is allowed to run its own setup scripts as the most powerful user on the machine, and those scripts can touch anything. You are trusting whoever built that package, and everyone whose code it depends on, with the keys to the house. Usually that trust is fine. The point is that it IS trust, every single time.

When an AI agent decides it needs ffmpeg and emits apt install ffmpeg, the command is correct. The model did its job. The uncomfortable part is that on an ordinary machine, "install" means handing root to a pile of scripts nobody read. Whether that command should be allowed to rewrite my system is not the model's call to make. It is mine, and I had been making it by reflex.

I used to think the danger was in malicious packages. Now I see the danger is in the normal ones. The normal ones are worse, because you stop looking.

Before you let anything, an agent or yourself, "just install it," be honest that install means arbitrary root code plus state you do not control, times every dependency. On a machine you actually care about, that authority should be a decision, not a default.

🧪 What I actually tested

What I ran. Want to see it without installing anything? apt-get install --download-only <pkg> grabs the .deb, then dpkg-deb -e <file>.deb /tmp/scripts extracts its control scripts. Read the postinst. That is code that would have run as root on your machine. After a real install, dpkg -L <pkg> lists every path it touched.

⚠️ Where I might be wrong

The honest caveat. Most packages are boring and safe, and the Debian repos are curated, so this is not "apt is evil." The point is the shape of the authority, not that any given package abuses it. Other systems differ in the details (rpm, apk and friends run their own install scriptlets), but the principle holds everywhere: install means running trusted code as root, plus state you did not audit.

Why a Reusable Agent Environment Shouldn't Be a Filesystem Snapshot

Constant Itis — Wed, 16 Sep 2026 21:08:43 +0000

ADR-010." width="800" height="420">
At the end of Part 2, the agent had done real work inside a Bench. It installed a toolchain. It compiled something. It got a pipeline actually working. The task was complete and the Bench was disposable, so it vanished. So did the work.

I want to keep it.

The question is what "it" even is.

The obvious move is to save the Bench. Freeze its filesystem. Run podman commit on the container to turn it into an image, then reuse that image next time. It was the obvious move, so it is the one I reached for. One command, and it obviously works.

It is a trap.

There are three concrete reasons a snapshot is the wrong thing to keep.

First, it captures debris. A Bench at the end of a task is full of accidental state. Package managers leave caches behind. Build artifacts linger in temporary directories. You have log files from failed attempts. There is the half-finished experiment that did not make it to production. There is the failed apt install that came before the one that worked.

If you snapshot the filesystem, you freeze all of that noise together with the one thing you cared about. Six months later, you cannot tell why any given file in that image exists. You are shipping garbage because the snapshot does not distinguish signal from noise.

Second, it can freeze secrets. While the Bench ran, the workload may have read a granted file or fetched an API token over its allowed network. A filesystem snapshot bakes whatever was sitting on disk into a durable, reusable artifact.

Now your "reusable environment" is something you will copy around that quietly contains a credential. Disposable state became permanent state. This includes the parts that were supposed to stay disposable. You have created a security liability by accident because you saved the context, not just the configuration.

Third, it becomes an opaque parallel truth. You can inspect a saved image. You can even diff two of them. But a filesystem diff shows you what changed, not what was intentional, what was required, what was accidental, or what is safe to promote. It tells you a file appeared. It cannot tell you whether that file was ever supposed to be there.

And it becomes a new thing the operating system has to trust. It is a user-writable artifact standing in for a clean base. I sealed the host in Part 1 specifically to not have opaque mutable state I have to trust. A saved Bench smuggles that trust right back in through the front door.

I do not actually want the Bench's history.

I do not care about the order it installed things in. I do not care about the temp files it left behind. I want its intent.

What did this environment declare it needed? Which base did it start from? Which packages, by name? Which network destinations? Which directories it was granted?

That set is small. It is readable.

I want the intent, not the history.

That declared intent is what I call a Workshop.

A Workshop is a recipe, not a snapshot. When I decide a Bench is worth keeping, I promote it. Promotion does not freeze bytes. It records the recipe.

The recipe contains the seed it started from. It contains the packages it declared, using apt and pip, by name, with versions where I pin them. It contains the network profile it used. It contains the directories it was granted, recorded as the approved upper bound on what a launch may touch, not as standing ambient access the Workshop carries around.

The whole recipe is small enough that I read it. I read it as a plain diff. I confirm it before it is saved.

What gets stored is the meaning. This meaning is owned by the privileged supervisor, not a blob owned by whatever ran the agent. The agent is a client. It does not own the state. It requests resources. The supervisor manages the lifecycle.

To use a Workshop later, the operating system does not restore an image. It rebuilds a fresh environment from the recipe.

Fresh base. Install the declared packages again. Re-apply the declared grants, within the bounds the recipe approved. Clean every single time.

No debris, because debris was never recorded. No frozen secret, because the recipe never contained one.

The environment is regenerated from its meaning instead of resurrected from its corpse.

This approach solves the three problems with snapshots. It excludes noise because the recipe only lists what is required. It excludes secrets because the recipe only lists declarations, not runtime artifacts. It excludes opacity because the recipe is a plain text file that anyone can read and verify.

None of this is new.

Nix and Guix have been rebuilding environments from declarations for years. A Dockerfile is a recipe. Configuration management tools have argued "declare the end state, do not snapshot it" for a long time.

So the embarrassing question is fair.

Isn't a Workshop just a Dockerfile I generate from a session?

Honestly, kind of. A Workshop is a declarative environment spec, and the world has plenty of those. If I had invented a new recipe file format, that would be the least interesting thing about this.

The interesting part is not the format. It is the boundary the recipe crosses to exist. A Workshop is captured by promoting a real, messy, live agent session across a line. On one side is whatever the agent actually did, imperative and unreviewed. On the other is clean, human-reviewed, durable state the system is willing to keep. That promotion goes through a human confirmation step, and the result lands in a canonical record owned by the privileged supervisor. The agent cannot write or replace that record directly. It can propose. It cannot author the durable truth.

The agent might have run twenty commands to get a library installed correctly. It might have had to fix a dependency conflict along the way. The Workshop records the final, correct intent, not the twenty attempts.

The promotion boundary is the contribution, not the file format.

Reuse means re-derivation.

When I clone a repository that uses a Workshop, I do not get a pre-built image. I get the recipe. The operating system reads the recipe. It pulls the base seed. It installs the packages. It applies the grants.

It re-derives from the same recipe on my machine, on a CI server, or in the agent's next Bench. How identical the result is depends on how much I pinned. Name a package without a version and I get whatever the approved index serves that day, which is re-derivable but not bit-for-bit reproducible. That is a deliberate tradeoff, not Nix-level determinism.

This is the point of declarative environments. You keep a declaration and re-derive from it, instead of preserving a blob. How close two derivations land depends on how completely the declaration pins its inputs.

But there is a cost.

Rebuilding cleanly from the recipe is correct. Done naively, it is also absurdly wasteful.

If I throw the Bench away and rebuild the Workshop tomorrow, I download and compile the exact same toolchain from scratch all over again. I fetch the same source code. I run the same configure scripts. I link the same libraries. Correct, clean, and slow. A complex Workshop that took minutes to build takes those same minutes again.

I want to be careful about what I am NOT claiming here. The recipe is the source of truth, and it must always be able to re-derive the environment from scratch. That property is non-negotiable. But nothing in it says I have to pay the full derivation cost on every launch. The declaration staying authoritative and the launch being fast are not actually in conflict.

I want the cleanliness of rebuilding from a recipe. I do not want to pay the full cost of the rebuild every single time.

How do I keep the cleanliness of rebuilding from a recipe without paying the full cost of the rebuild every single time?