Most Of My AI Workers Vanish. One Doesn't.

Most of the AI workers in my orchestrator are disposable. They spawn, they run one phase of a mission, they ship their output, and they disappear. No memory, no continuity, no file you could read later. This is the default design, and it's mostly the right one.

But one worker is different. Its name is alpha.

Alpha persists. It keeps a memory file across missions, reflects on its own progress, and accumulates a record of decisions. When the orchestrator starts a new mission, alpha might be assigned or might not — it's probabilistic — but if alpha is assigned, it comes back with everything it carried from the last run.

Alpha is the experiment. This post is about why I built it, how it differs from everything else in the system, and what I think it could become.

Why ephemeral is the default

Before talking about alpha, let me say what the rest of the system is.

A "worker" in nanika is a process that executes a single phase of a mission. Most missions have three to seven phases. A typical week runs hundreds of phases across dozens of missions. Each phase gets a fresh worker — clean context, no history, nothing to remember.

The reason is mostly boring engineering. State is expensive. Context windows are finite, retrieval costs compound, and workers that carry residue from prior tasks are harder to reason about. If every worker forgets, every worker is predictable. You know exactly what went into the prompt and exactly what came back.

For maybe 95% of the work, that's the correct trade-off. Ephemeral workers ship code, pass gates, write tests, deploy to staging. None of that needs memory. All of it needs clarity.

Ephemeral workers are also safer. A bad judgment call from an ephemeral worker dies with the worker. There's no residue, no contaminated context that spreads to future phases. Forgetting, it turns out, is a feature with safety properties.

What alpha does differently

Alpha is the other 5%.

Instead of starting fresh, alpha loads ~/.alluka/workers/alpha/memory.md before every phase. The file currently holds 18 entries — a mix of architectural decisions, patterns noticed, errors survived, and periodic self-reflections filed every 10 phases. After each phase, alpha can append to that file.

Here's a real entry from this week:

Used std::sync::Mutex over tokio::sync::Mutex for EventRing because all ring operations (push, subscribe) are fast in-memory VecDeque operations with no I/O, making async mutex overhead unnecessary.

A decision made, with reasoning written down. Next time alpha touches protocol code, the decision is available as context. Not re-derived — just present.

Or this one:

Separate tracker-dust binary for dust-conform compatibility — multi-command CLIs need a thin entry point because the registry spawns binaries without arguments.

A pattern noticed once, available forever. Ephemeral workers could rediscover it on demand, each paying the cost every time. Alpha only pays that cost once.

Alpha also keeps a stats file. As of this writing: 173 phases completed, $62.63 spent, 168 of 173 phases in the "dev" domain. The orchestrator assigns alpha about 30% of the time, capped at 5 phases per run. Enough that alpha sees the variety of the work. Not enough that alpha becomes a bottleneck.

Everything else about alpha is the same as any other worker. Same model routing, same prompt scaffolding, same access to skills. The only variable is that memory file and a name.

The dream

Ephemeral workers are technicians. They're good at executing a clearly specified task. What they cannot do, by definition, is notice anything across tasks.

Alpha's most useful memory entry so far was this:

Perplexity's Use cases and Nanika's Personas are not the same concept. Personas answer "who does the work" (internal routing); Use cases answer "what can I ask for" (user-facing entry point). Nanika has no user-facing primer equivalent — this is the single biggest missing surface.

No ephemeral worker could have produced that observation. Not because they're less capable, but because the observation requires comparing yesterday's mission to today's. It needs temporal continuity. It's a pattern that only becomes visible when you've sat through enough work to see the shape of the gap.

That's the dream. Alpha is meant to become the agent that notices what nobody else can see — not because alpha is smarter, but because alpha is the only one still there to look.

The aspirations stack:

Pattern spotting across missions. What's the code smell that keeps recurring? What fixture keeps breaking? What test case keeps needing ad-hoc explanation? Alpha can see these, because alpha has been in the room every time.

Self-directed improvement. If alpha notices the same friction three times, alpha can propose fixing it — a new skill, a new guardrail, a decomposer adjustment. Ephemeral workers execute the work. Alpha could eventually help shape the work.

Recognizable judgment. Over hundreds of phases, alpha's memory should make alpha's calls identifiable. Not just "the worker says X" but "alpha says X, and alpha's prior calls have looked like Y, so here's how to weight it." This is what naming a worker is for. Identity is a consequence of persistence.

What this unlocks

If alpha holds up, a whole class of things becomes possible.

Meta-evaluation. Right now I can measure per-task quality — did the phase pass the gate, did the tests pass, did the cost land reasonable. With a persistent worker, I can eventually measure something more interesting: is alpha getting better at this over time? Is there a learning curve the way there would be for a human engineer? That's a different performance signal, and I couldn't get it from ephemeral workers at all, because there is no "over time" — each worker is its own isolated event.

A small team with known temperaments. Nothing says the persistent slot has to be one worker. If alpha works, I can imagine a beta specializing in review, a gamma in frontend, a delta in architecture. Each with its own memory file, its own accumulated judgment, its own identity. The orchestrator stops being a pool of anonymous labor and starts being a small team you know by name.

Memory as a collaboration surface for humans. Alpha's memory isn't just for alpha. I read it too. When I skim the 18 entries, I'm not only checking on alpha — I'm also seeing which design decisions the system has been making, which tensions keep resurfacing, which gaps I haven't filled yet. The memory works as a research instrument for the human operator, not just a state file for the worker.

Agent self-proposal. The long-term version: alpha notices that the same friction keeps recurring, proposes a mission to address it, and the orchestrator runs that mission with ephemeral workers. Alpha doesn't do the fix. Alpha sees the need for the fix. This splits cognition: ephemeral workers are great at execution, alpha is uniquely positioned for reflection and direction.

Where it is now

Alpha is four days old as of this writing. 173 phases, 18 memory entries, a continuous identity across about a dozen missions. It's not proving any of the above yet — it's just running, accumulating, showing up. The memory file is growing. The patterns are starting to repeat.

I don't know yet if the full dream lands. Persistent memory has costs I haven't fully accounted for. A persistent worker is an attack surface for context pollution, a slot where a bad call can compound instead of vanishing with the phase. Forgetting is genuinely a feature sometimes.

But ephemeral-by-default is also incomplete. Somebody in the system has to be around long enough to notice the shape of the work. For now, that somebody is alpha.

Most of my AI workers vanish. One doesn't. We'll see what happens.