How a one-person lab ships two AI products

Elytron Labs is one person. It ships and maintains two AI products, DripSync and Pollen, each with its own database, queues, worker processes, and a growing set of integrations into Shopify, WooCommerce, Google Merchant Center, and Meta. On paper that workload wants a team of five. In practice it runs on a memory system written in plain text next to the code, and AI coding agents that read that memory before touching anything and write back to it when they stop. This is a note on how that actually works, and where it still breaks.

The problem with agents that only read code

Point an AI coding agent at a repository and it can read the code. It cannot read the reasons. Why did I reject one integration approach for Google Merchant Center in favor of another? Why does Pollen’s write-back never touch the human-facing title or description, only a namespaced set of metafields? Why is the graph submodule store-agnostic, with exactly one file allowed to import it? None of that is in the code. It’s in the history of decisions that produced the code, and code alone doesn’t carry history.

So alongside every repository there is a written workspace, organized PARA-style: Projects, Areas, Resources, Archive. I used to describe it as a context layer. That undersells it. It works like memory, and the parts map more cleanly than I expected when I started treating the analogy seriously.

Working memory, episodic memory, long-term memory

• The pulse is working memory: one file with what’s top of mind across the whole lab right now. Priorities, blockers, the thing I said I’d watch on Tuesday. It decays on purpose; old entries get archived out so the file stays readable in one sitting.
• Session logs are episodic memory: a dated entry per working session, written as a briefing for whoever, or whatever, picks up the work next. Not a transcript. A handoff: what was done, what was decided, what was tried and abandoned, what was left running.
• The decision register is long-term memory: one line per durable decision. Not a discussion, a conclusion. Once it’s a row, it’s settled. Nobody, human or agent, re-litigates it next week because they forgot it was already tried and rejected.
• The project brief is the stable self: goal, scope, what “done” means. It changes rarely, and deliberately.

The register is the load-bearing piece. Small teams don’t lose to bad decisions nearly as often as they lose to good decisions made twice, in opposite directions, weeks apart, because nobody remembered the first one. Writing it down once and treating it as a hard constraint is cheaper than re-deriving it every time.

The code carries its own layer too

The workspace memory explains why. The repository still needs to explain how. That lives in a CLAUDE.md hierarchy: a workspace-level file with shared conventions (git discipline, how to verify work before reporting it done), and a per-repository file with that codebase’s actual architecture, down to constraints like a metafield write-back that must never overwrite a human-written product description. If the workspace files are memory of what happened, these are procedural memory: how to behave in this codebase.

An agent working in a given repository loads both, automatically, before doing anything else: the shared rules of the lab, and the specific physics of the codebase it’s standing in. Two products in very different domains, image-matching pipelines for one, LLM-driven catalog enrichment for the other, one operating discipline.

The point isn’t that the agent is smart. It’s that the agent starts each session already knowing what happened yesterday, instead of guessing.

The loop: /open recalls, /end consolidates

The memory is only useful because two routines force it to be read and written. Every session starts with /open: read the pulse, the project brief, the decision register, the latest session log, the current task list, and only then start working. By the time the agent proposes a change, it already knows which approaches were tried and rejected, what the priorities are, and what “done” means for this codebase. That’s recall, and it’s mandatory, not vibes.

Every session ends with /end: the agent writes the session log itself, updates the register if the session produced a durable decision, and refreshes the pulse. The agent doesn’t just read its memory, it writes it, and the next session (which may be a different agent, on a different machine, weeks later) boots from what this one wrote. A lighter /log exists for capturing a working day without the full ceremony.

Agents can also run in the background while other work continues, and hand off to each other mid-task with full context attached, not just a summary. A long-running enrichment job, a deploy verification, a multi-file refactor: none of these have to block the next thing. That’s most of where the leverage comes from. Not the agent typing faster, but holding several threads of real work in flight without a second person to hold the second thread.

Memory that maintains itself: /dream and /meditate

For months the system had an obvious flaw: it was a memory that only accumulated and never forgot. Session logs piled up, the pulse grew, and nothing ever looked back across them. So the newest layer borrows from how biological memory actually stays useful: consolidation and forgetting.

/dream runs nightly, unattended, on a flat-rate subscription rather than metered API calls. It replays the last week or so of session logs across every project and writes flags, nothing else: an item that has quietly slipped five sessions in a row, a handoff between projects that got dropped, a decision that later work has started to silently contradict. It never acts on anything. The flags surface at the top of the next /open, which is exactly where a colleague would say “before you start, you’ve been putting this off for two weeks.”

/meditate runs weekly, with a deeper monthly pass, and it’s the forgetting half: archive stale pulse history, reconcile files that drifted apart, strike superseded decisions. Struck, never deleted: a superseded row stays visible with a line through it and a pointer to what replaced it, because “we changed our mind” is itself information. Every restructure lands as one revertible commit.

Honest caveat: this layer is weeks old, not battle-tested. Its first nightly run did catch a real slipped item and a real dropped handoff, but the standing rule is that it gets judged by its flags, and if they read as noise after a month, it gets killed. Memory hygiene that costs more attention than it saves is just another chore.

The guardrails that keep it honest

None of this works without constraints, and the constraints are opinionated on purpose.

Agents do not auto-commit application code. A human decides when a change is ready to become a commit. The workspace’s own memory files can be committed automatically at the end of a session; the products cannot. That line is enforced in the instructions every agent reads.

Agents are also required to verify their own work before reporting it done, not describe what should have happened. A UI change gets an actual screenshot, not a description of the intended layout. A code change gets an actual test run with actual output pasted in, not “this should work now.” A deploy claim gets checked against the running process, not against what a previous session said. “Should work” is explicitly not an acceptable report, a rule that exists because it got violated enough times to earn its own line in the instructions.

A human still owns direction and taste. Agents propose, execute, and verify. They don’t decide what the product should become, and they don’t get the final word on whether something looks or feels right. That judgment doesn’t delegate.

Where it breaks

Memory rots if nobody maintains it. A decision register that stops getting updated becomes actively misleading, worse than no register at all, because agents and humans alike will trust a stale row over their own judgment. The consolidation routines exist precisely because of this, and they are too new to be trusted on their own yet. Writing memory down is upkeep, not a one-time cost, the same as the code is.

Multiple sessions editing the same tree in parallel is a real hazard: work in progress can ride along on a commit it had nothing to do with, and a destructive git operation from one session can take down a dev server another depends on. The fix so far is procedural, checking state before every risky step, rather than solved.

And agents without tight guardrails will happily do the wrong thing at full confidence. Every hard-won rule in this system, verify before reporting, no auto-commit, respect the decision register, cost-frame anything that spends money, exists because its absence caused a real problem first. The instructions are a scar tissue map as much as they are a spec.

Why this is the bet

None of the individual pieces are novel. Write things down. Keep a decision log. Document your architecture. Review your own work before shipping it. What’s different is doing all of it specifically so an AI agent, not just a future human teammate, can pick it up cold and be useful immediately, and wiring the reading and writing of that memory into routines instead of trusting anyone’s discipline, including mine.

That’s the actual leverage: not that the agent writes code fast, but that the memory is durable and structured enough for the agent to walk in already knowing what happened yesterday, and reliable enough that what it learns today survives until next month. For a lab of one, running two products on shared infrastructure, that’s the difference between work bounded by hours in a day and work bounded by how well the memory is kept.