cortex
A reverie mesh is a daemon, a memory store, and a shifting set of agent sessions doing real work across real repos. cortex is the one console you drive it from — bring the mesh up, watch what it’s doing, gate what it’s allowed to do, tear it down again. One binary, one surface, every milestone.
What cortex is
cortex is the operator console for the reverie mesh and the
reveried HTTP surface. Where reverie decides what an agent should remember,
cortex is how a human — or a supervising agent — sees and steers the agents
themselves: a single CLI that talks to reveried over HTTP and manages local sessions
over tmux and git worktrees. It was called meshctl through the early milestones; the
capability grew past “a control CLI” into the console the whole system is operated
from, and the name followed.
The surface
cortex is organized around a handful of verbs over the same mesh:
cortex init— first-run bring-up: wire the daemon connection and local mesh state.cortex sessions up/down— spawn and reap agent sessions (each its own git worktree + tmux pane), the unit of work in the mesh.cortex dash— the live TUI: roles, sessions, health, and activity in one pane.cortex gate— the operator gate: surface what is waiting on a human decision (a merge, an irreversible action) and approve or hold it.cortex health— a fast read of daemon + mesh liveness; the same signal external probes consume.cortex dream trigger— kick the offline consolidation cycle reverie runs over its memory (the “dream” in the daemon).- per-subsystem inspection — drift, graph, nodes, planner, roles: read the mesh’s internal state without attaching to a session.
Everything routes through one place. The CLI is a thin HTTP client against reveried
plus local session management — so the same commands drive a laptop mesh or a remote one,
and the daemon stays the single source of truth.
Using cortex
cortex ships in the same one-shot install as the rest of reverie:
git clone [email protected]:cerebral-work/reverie.git
cd reverie
scripts/install-reverie.sh # builds reveried, cortex, reverie-bench → ~/.local/bin A session, end to end:
cortex init # one-time: wire up the daemon connection
cortex health # confirm reveried is live
cortex sessions up <role> # spawn an agent session (worktree + tmux)
cortex dash # watch the mesh live
cortex gate # approve what's waiting on you
cortex sessions down <id> # reap it when done The mental model: reveried is the daemon and HTTP surface, reverie is the memory it manages, and cortex is the console you operate both from. You rarely talk to the daemon directly — cortex is the seam.
How it pairs with reverie
reverie and cortex are two halves of one system. reverie is the memory layer — placement-aware storage, offline consolidation, the bet that agent failure is a context problem and not a model problem. cortex is the control layer — the operator surface over the mesh of agents that use that memory. reverie answers “what should this agent know?”; cortex answers “what are these agents doing, and what am I letting them do?” They ship together and are versioned together.
What it isn’t
- Not a separate product. cortex is bundled with reverie and tracks its releases; there is no standalone cortex you install on its own.
- Not a CI/CD orchestrator. cortex drives interactive agent sessions and the reverie daemon — it is not a pipeline runner and does not replace your build system.
- Not an autonomous controller. The gate is deliberate: irreversible and outward-facing actions stop for a human. cortex surfaces decisions; it does not make the ones that matter on your behalf.
Status
Proprietary, bundled with reverie. Copyright © 2026 Christian M. Todie / cerebral.work — all rights reserved. Versioned with reverie (currently v0.9.13). This page tracks the surface as reverie and cortex shape up toward the v1.0 milestone — commands and flags will move until then. For commercial licensing, embedded use, or evaluation access, [email protected].