Kosmos
The Problem
A knowledge base that only grows eventually becomes noisy. Duplicate memories accumulate. Embeddings break when an upstream service has an outage. Stale entries referencing cancelled features linger in search results. Session transcripts contain valuable decisions that nobody extracts. Without active maintenance, the memory system degrades over time, and every agent session that reads from it gets slightly worse results.
Kosmos is the memory operations agent. Named after the Greek word for "order," it maintains the health, accuracy, and leanness of the knowledge layer so that Hoshi, Claude Code, and Umbra can trust the data they read.
What's Built
Three Operations
Kosmos runs as server-side operations on Railway, scheduled by node-cron with no user-facing chat. It performs three distinct operations:
Heal
Healing is a two-stage process split across Supabase and Railway. Every 6 hours, an automated health check runs seven diagnostics against the memory system on Supabase (see Knowledge System). This is one of the few remaining Supabase edge functions. Separately, the Kosmos heal cycle runs every 12 hours on Railway, reading the latest health check results. If everything passed, it exits at zero cost. If something failed, it maps each failure to a specific fix: re-embedding orphaned memories, re-testing degraded canaries, applying strength decay to inactive memories, or surfacing alerts for issues it cannot resolve automatically.
Healing is entirely deterministic. No LLM call. Negligible cost.
Groom
The groom pipeline is a scheduled quality review on Railway. Once a month, Kosmos loads all non-archived memories for each active project along with project context. It sends this to an LLM in a single call and receives a structured grooming plan with four action types:
| Action | Autonomy | What Happens |
|---|---|---|
| Keep | Automatic | Memory is fine. No change. |
| Dedup | Automatic | Near-identical memories consolidated. The most complete version is kept, others archived. |
| Archive | Requires approval | Memory is stale or irrelevant (e.g., references a cancelled feature). Proposed to the user. |
| Merge | Requires approval | Fragmented memories about the same topic consolidated into one. Proposed to the user. |
Low-risk actions execute immediately. Higher-risk actions appear in the Hub feed as interactive proposals for the user to approve or reject. Approved actions are executed by a separate apply step with no LLM call.
The guiding principle: bias toward keep. A cluttered memory store is annoying but functional. A memory store with important context deleted is actively harmful.
Mine
The mine pipeline extracts memories from Claude Code session transcripts on Railway. After each session, the transcript content is sent to the mine endpoint via HTTP. Kosmos processes the transcript, strips tool-use noise, and uses Haiku to identify decisions, architectural insights, and non-obvious facts worth preserving.
Mining serves as both a primary extraction mechanism and a safety net. During session wrap, the working agent also extracts memories inline. Mining catches anything that process missed and handles cases where the session ran out of context before wrapping. A processed_sessions table prevents duplicate extraction. A retroactive batch across 49 historical sessions extracted 229 memories at $0.17 total.
Scheduling
Pipeline operations (heal, groom, mine) are scheduled via node-cron on the Railway server. Health checks are the exception: they still run on Supabase via pg_cron, since the health-check edge function is one of the few remaining Supabase-side operations.
The schedule: health checks every 6 hours (Supabase edge function), heal cycle every 12 hours (Railway), grooming on the first Sunday of the month (4am UTC), and memory clustering weekly (Sundays, 5am UTC). Grooming is also available on demand via a "Groom Now" button on the Kosmos card in the Hub.
Cost Caps
All agent operations share a global daily cap of $5 and per-project caps of $1/day. Kosmos costs are tracked separately from Hoshi and Umbra. In practice, monthly Kosmos spend is around $1 total: healing is free (deterministic SQL), mining is cheap (Haiku), and grooming runs only once a month.
Where It's Heading
As the largest project approaches 500+ memories, the single grooming call will need to be batched by memory type or recency to stay within context limits. Cluster quality will be evaluated after the first few weeks of activation data accumulate; the self-organization system is deployed but needs real usage before clusters emerge naturally.