Luci — Orchestrator Flow
How work moves from a chat, through the orchestrator, to the workers — and loops back. Target architecture (MC-3718 + MC-3754 chat-first).
/ Entry — every door is a chat with the orchestrator
💬 Telegram
Message Luci from your phone. A real chat interface — a first-class door, not a fallback.
💬 MC — New Session
Open Mission Control → you land in a chat thread. Many threads possible.
↓ ↓both are the same orchestrator — one front door, two surfaces
Cron · Scheduled · Events
Automated triggers also route THROUGH the orchestrator (inbox digest), never straight at workers.
↓
/ Coordination layer
⬡ LUCI — Orchestrator
The luci-persistent session. Every chat and every trigger lands here. Holds context, decides what happens next — answer, ticket, do-now, or delegate.
understand intentdecompose
route + assign runtimesynthesise
gatereport back in-thread
↓creates / updates tickets · drains the inbox
/ Work queue
▦ Ticket Bus — Mission Control
mc.db tickets (the board) + orchestrator_inbox. The durable queue. A ticket = a deliverable; sub-steps are not tickets.
↓mc_pickup.py dispatches — runtime + tools picked per ticket
/ Work-doers
⚙ Workers
One per ticket. Each runs with the runtime + tools the orchestrator assigned.
ticket workerssubagents
Opus / SonnetGLM / Kimi (off-MC)
Larry (remote)
↓
/ The loop — quality gates before "done"
↻ Review & QA loop
Worker output is never trusted on sight — it cycles through gates, then back to the orchestrator:
Council / second-opinioncode review
QATessa — human-experience
✦ Pass → orchestrator gates in_review → done, synthesises.
✦ Fail → back to the worker.
✦ Dead worker → orchestrator recovers it by hand.
✦ Needs a decision → orchestrator escalates (non-coding only) to Elmar.
↻loops up to the orchestrator — and out as a reply in your chat
↑ Result back in your chat thread
Synthesised outcome — in the SAME Telegram / MC thread you started. The loop closes where it began.
/ Legend
chat (you ⇄ orchestrator)
automated trigger
ticket bus
workers
review loop