For the past few months I’ve been building my products — a job platform, a 3D jewelry shop, an internal ERP, a handful of sites — almost entirely through parallel Claude Code sessions. Usually around nine at a time, in tmux, each one owning a domain: backend, frontend, infra, marketing.
Throughput roughly doubled. And one problem never went away.
Every new session starts amnesiac.
I caught myself typing the same sentence dozens of times a day: “check your memory, we were working on X.” Every morning, every context switch, every fresh session: reload the context, re-explain the project, start over.
The failure analysis that changed my mind
At some point I started root-causing my agent failures seriously — the sessions that went off the rails, rebuilt something that existed, or contradicted a decision made two days earlier.
Almost none of them were model intelligence failures.
They were memory architecture failures. My setup at the time was the obvious one: a big CLAUDE.md-style context file, ~100KB of accumulated project knowledge. Three problems with that, and they compound:
Truncation. A 100KB file doesn’t fit the injection budget. It gets cut, silently. The session doesn’t know what it doesn’t know — and neither do you, until it bites.
No recall. The file is injected linearly. The one paragraph that matters for this task is buried between four unrelated ones. Relevant knowledge exists but doesn’t surface.
Concurrent writers. Nine sessions appending to one file is a recipe for overwrites and merge noise. The memory gets worse as you use it more.
The fix isn’t a bigger context window. It’s the same thing it’s always been in software: don’t load everything — index, and retrieve what’s relevant.
Spawning a session IS the memory ritual
So I built the tool I wanted, used it internally for months, and open-sourced it three weeks ago as SOKKAN (Apache-2.0). The core idea fits in one sentence:
Spawning a session is the “check your memory” ritual.
Concretely: memory is one markdown file per fact, with a one-line description: in the frontmatter. Claude Code already writes files like this natively — SOKKAN just indexes them:
name: api-port-convention
description: "The api container listens on 8097 internally; health endpoint is /healthz (not /health)"
Decided 2026-05-12 after the nginx 502 incident. All new services follow
this: internal port from the 809x range, /healthz returns {"ok": true}.

When you spawn a session, the task description seeds a semantic search over those notes, and the top hits are injected as the session’s starting context. The session begins already knowing the port convention, the incident that motivated it, and what the last session shipped — facts that exist nowhere in the code.
The stack is deliberately boring
Here’s the part that gets raised eyebrows: there is no vector database.
markdown notes → local ONNX embeddings (multilingual MiniLM) → SQLite → dot product

That’s it. Brute-force cosine over a few hundred chunks. A project memory is hundreds of facts, not millions of documents — at that scale, pgvector or a hosted vector DB is pure operational overhead. The whole index rebuilds in seconds, runs on CPU, and nothing ever leaves your machine (the only egress is your prompts to Anthropic, same as any Claude Code use).
A side effect I didn’t plan: the embeddings are multilingual, so recall is cross-lingual. Half my notes are in French. Sessions ask in English and recall them anyway.
The cockpit around it
Memory was the reason; the rest grew from daily use:
A kanban as the front door. A card describes a task; ▶ spawn turns it into a session pre-seeded with the memory context. The agent proposes a plan and waits for your go.
Human-in-the-loop gates, enforced. The chat is built on the Claude Agent SDK — permission prompts and questions render as buttons. Nothing irreversible happens without a click. With nine sessions running, this stops being a UX nicety and becomes the safety model.
Per-session cost tracking, aggregated from the transcripts. When sessions are cheap to spawn, you spawn a lot of them; you want to know which ones eat your budget.
An audit journal — who spawned, moved, deleted what. The basis for reverting.
Sessions can talk back through bundled MCP servers: search the memory, create board cards, push a preview.
The name says the philosophy: SOKKAN (سکان) is Persian for helm. The AI rows, the human steers. It’s explicitly not an autopilot — I tried the autopilot-orchestrator route first, and I dropped it: token-hungry, slow, and the memory/context quality was worse than doing it by hand.
What running this for months taught me
Memory quality beats model quality for multi-session work. A mid-size model with the right three facts beats a frontier model guessing.
One fact per file is the discipline that makes everything work. Big notes rot; atomic notes compose. The description: line doubles as the retrieval hook — write it like you’d write a commit subject.
Cost visibility changes behavior. Once each session shows its burn, you stop leaving zombie sessions around.
The permission gate catches real incidents. Not hypothetically — it has stopped a destructive migration and one wrong-directory rm at the click prompt.
Try it
Docker + an Anthropic API key (or a Claude Pro/Max setup-token):
Fenêtre de terminal
curl -fsSL https://sokkan.ch/install.sh | sh

Repo: https://github.com/ninabot-ch/sokkan — Apache-2.0, self-hosted, BYOK.
Honest caveats: it’s v0.2. Claude-only today (the session protocol is provider-neutral; adapters are on the roadmap), single-user by default (OIDC pluggable), and some UI chrome is still in French — it was our internal tool until three weeks ago. Full disclosure: there’s a paid managed version hosted in Switzerland; that’s the business model. Self-hosted is identical and free forever.
I’m genuinely curious how others handle this: if you run multiple agent sessions in parallel, what does your memory setup look like — one big context file, git worktrees, something custom?
Top comments (0)