Nyx / inside the agents

One orchestrator,
a team of doers,
on one self-healing spine.

The Assistant does not do the work. It understands you, remembers you, routes the request, and aggregates the result. The actual work is done by specialist doers: a Coder, a Researcher, and a Reviewer. Underneath, the spine (nyx-core) is the engine-room orchestrator that runs every task and cannot wedge.

01The Assistantorchestrator

A pure orchestrator and aggregator. It classifies each request and hands it to the right doer, then assembles what comes back into one coherent answer. It never researches, codes, or builds automations in its own loop.

SURFACES Telegram API GUI Memoryfacts, prefs, historyrecall via embeddings Toolsetweb fetch, files,time, scratchpad Router + Aggregator classify, delegate, assemble the answer chat / code / research / automate / long-goal DELEGATES TO Codercode, on the harness Researcherresearch grunt work nyx-engineautomations Marathonlong goals chatanswer direct results flow back up; the assistant aggregates them into one answer PROACTIVE: the assistant also runs scheduled + triggered work (daily briefing, reminders, watch-and-notify)
The assistant routes to a doer and aggregates the result. It does no grunt work itself, including research, which now goes to the Researcher.

02The Coderdoer

The engineer. Works a loop (understand, change, verify) on a confined workdir, with a self-compacting memory and a moderator layer that decides whether work is actually done. Also watches and fixes GitHub issues like a teammate.

Bootstrapdetect test/build/lint Commit / PRopt-in delivery GitHub issueswatch + fix + PR THE LOOP Understand Change Verify (repeat)until done Memoryevent log+ compaction Moderator acceptance gate supervisor (stalls) safety rails: own branch, auto-rollback, token + cost budget Routeplanner/worker/vision/image/embed
Understand, change, verify, over sandboxed tools, gated by the moderator, on the configurable Route. Now also a GitHub teammate.

03The Reviewerdoer

An independent QA agent. The acceptance gate proves the code builds and matches the diff intent; the Reviewer proves it actually works and looks right. It opens a real browser, clicks through the flows, checks every format, and judges the result against the product vision. If anything is wrong, it writes it up and sends it back to the coder.

Coderbuilds it Acceptancegatetests + diff Reviewer open browser, click flows desktop / tablet / mobile vision-match the product Shipsigned off pass fail: a written report of everything wrong goes back to the coder, loop repeats
The verify loop. The gate is a fast pass/fail; the Reviewer is the human-grade check that actually exercises the product and sends fixes back.

does it work

Browser E2E

Opens a real browser (Playwright), clicks through the key flows, and confirms they actually function, not just that the code compiled.

every format

Responsive check

Screenshots at desktop, tablet, and mobile widths and vision-grades each for layout and responsiveness.

is it the right thing

Vision match

Judges the result against the product vision and spec for the task, not just whether it renders.

the loop

Back to the coder

On any failure it writes a structured report of what is wrong and sends it back as a coder task. It repeats until it signs off.

04The Researcherdoer

The investigator. When the assistant gets a question that needs digging, it hands it here. The Researcher fans out searches, fetches and reads sources, ranks them with the embedding role, and returns a synthesized, cited answer. The assistant only aggregates the result.