Cortex
The metafactory ecosystem's layer-7 collaboration surface — the M7 application that consumes the myelin stack and presents collaboration, dispatch, and observability to operators.
Source on GitHub ↗ Architecture spec ↗
Where it sits
Cortex is one application at M7 — among siblings pilot (the review loop), signal-collector (telemetry), and any future M7 app that connects to the bus. It consumes contracts from M2–M6 and owns no part of M1–M6 itself.
The brand metaphor
The metafactory ecosystem uses a nervous-system family of names. Cortex slots in cleanly:
- myelin — insulator wrapping signals on the axon — the protocol (M2–M6).
- signal — action potentials carrying telemetry — an M7 app (OTLP collector).
- pilot — rhythmic coordinator — an M7 app (the review loop).
- compass — heading control — SOP knowledge artefacts cortex consumes.
- blueprint — body plan / wiring diagram — cross-repo feature graph.
- cortex — conscious processing surface where the operator perceives and acts (this app).
What it does
Three jobs, one process boundary:
- Consume the bus. Subscribe to myelin envelopes, validate them, route them to internal handlers.
- Render the work. Mission Control v3 — Kanban / Inbox / Cards — backed by Durable Objects that track per-agent state.
- Adapt to platforms. Discord, Mattermost, Slack, PagerDuty — each a thin adapter that translates between platform events and bus envelopes.
Three-tier visibility
The original problem cortex was built to solve: a single Discord channel conflates three concerns and produces two opposite visibility failures.
Bots that log every tool call flood the channel with Read · Grep · Bash · Edit noise.
Bots that don't log anything go silent for ten minutes and leave operators wondering whether the agent stalled.
Both failures share the same root cause: a single surface trying to answer three different questions.
Cortex splits them:
- Tier 1 · Work management. Mission Control answers is it alive? what is it working on? at a glance.
- Tier 2 · Cortex drill-down. Click a card and see where is this specific agent in its lifecycle?
- Tier 3 · Signal observability. The full tool-by-tool trace — for the operator who wants to drill in. Lives on the signal app's surface, not in chat.
Internal componentisation
cortex/src/
bus/ — M2–M6 client code (NATS connection, envelope validator,
surface-router; the G-1100 ladder lifted from grove-v2)
surface/ — operator surfaces (Mission Control v3, future TUIs)
adapters/ — platform-specific (Discord, Mattermost, Slack, PagerDuty)
runner/ — workflow runner (CC orchestration, worklog state)
taps/ — publishers onto the bus (CC hooks, GitHub webhooks)
cli/ — operator CLIs (discord, cldyo-live)
common/ — shared types + utilities
Each subtree owns one M-layer concern boundary. The bus subtree is the only one that knows about NATS; adapters know about Discord but not about envelopes; surfaces render state and emit dispatch events. Moving between subtrees costs the price of crossing one named contract — never which file is this in?
Where the code comes from
Cortex inherits source from grove-v2,
ported over phases MIG-0 (bootstrap, currently shipping) through MIG-8 (legacy retirement).
The migration plan at
docs/plan-cortex-migration.md
is the per-file inventory + acceptance criteria for each phase.
Legacy grove (v0.29.0) is in maintenance-mode
and contributes nothing to cortex. It will be archived at MIG-8.
Status
- v0.1.0 — MIG-0 bootstrap. Repo seeded, design docs landed, no source code yet.
- MIG-1 — bus runtime ports the G-1100 ladder from grove-v2.
- MIG-7 — rebrand
grove-bot→cortexon the deployed Discord identity. - MIG-8 — archive grove and grove-v2; migration document retires; cortex switches to normal feature-work mode.
Authors
- Andreas Åström — Christchurch
- Jens-Christian Fischer — Zürich