Map of Neutron Core

The rest of this guide takes one part of Neutron at a time. This page takes all of them at once: what each element is, who touches it, where it sits on screen, what it writes down, and which gate stands in front of it.

Seven elements. One of them is a proposal and says so.

The whole product, drawn

The core is the middle and the gate is the ring around it. The four elements outside the core are not separate products; each one reaches the world through the same check, and each has its own name for the pause that check produces.

Every element, in one table

Element	What it is for	Who uses it	Where in the UI	What it writes	Which gate governs it	Section
The core	Chat, the people and rules behind it, and the machinery the rest runs on.	Everyone, plus agents on a turn and other programs over MCP.	The chat window, and the switcher that moves between sections.	Conversations, roles, approvals, the audit log, cost.	The gate itself, on every mutating call.	Architecture
Development engine	An issue in, a reviewable merge request out.	Developers, and the review agents policy hands it to.	Chat, an @mention on a merge request, or a schedule. Jobs under Settings › Code › Work.	A branch and a merge request on GitLab or GitHub.	The plan gate, then the merge gate.	Writing code
Revenue Engine	Writing to companies worth writing to, and reading what comes back.	Whoever runs outbound, and the agents that draft and read.	The Revenue section: Overview, Leads, Pipeline, Inbox, Approvals, Reports, Fleet.	A touch row for every letter out and reply in, on one timeline.	Send approval, decided by the reviewer ladder.	The Revenue Engine
Projects	What is moving, who holds it, and when it has to land.	Everyone in the company, outside collaborators, and agents.	The Projects rail: board, epics, sprints, timeline, plans.	Items, epics, sprints, plans, and a status label on a linked issue.	The review gate, which the author may not open.	Projects
Agents and MCP	One endpoint any agent can hold, reaching the same routes the screens call.	Agents in a harness, other programs, and operators driving an instance without a browser.	Settings › Access & Security › API, where the token is minted. Nowhere else.	The same rows the screens write, plus an audit line for every call.	Every gate the screens meet, plus the token’s own scopes.	Agents and MCP
Goals	Saying what a year is for. Proposed, not built.	Nobody yet.	Nowhere.	Nothing.	None yet.	How a company maps its work
Federation and orbits	Cores as peers, each driving satellite nodes where the work is.	Operators wiring instances together, and anyone whose agent must act on a machine.	The workspace switcher, and Settings › Devices.	Audit rows on both sides of every federated call.	The same gates, plus an orbit’s own local limits.	Federation

What each element is

The core

The core is the part that is always there: a chat window, the people and agents allowed to use it, and the rules that say what each of them may do. Behind the chat sits the engine seam, a thin adapter so the conversation can be run by Codex, the Claude Agent SDK or OpenCode without the rest of the code knowing which. Beside it runs the assay-engine, a small binary holding encrypted secrets and the timers that survive the pod being killed. Everything the core does lands in one Postgres database: the conversation, the approvals, the audit log, the cost. Every other element on this page is built on that seam and stopped by that gate.

Development engine

Hand it an issue and it gives back a merge request. It takes its own checkout pinned to an exact commit, writes a plan, and waits, because the plan passes the gate before any code is written. Then a bounded loop of verify, review and repair runs until the work passes or the retry limit is reached, and the result is pushed as a merge request that updates itself rather than opening a second one. Where it stops after that is a setting, not a hard-coded end: a person reviews and merges by default, and review agents can be granted the right to review, approve and publish instead.

Revenue Engine

The Revenue Engine works outbound email end to end, and every part of it has a name you will meet on a screen. A fleet is a batch of mailboxes bought together, warmed for about a fortnight before it may carry campaign mail and checked daily by the warden, which pauses a domain on evidence and opens an incident saying why. Finding an address runs a waterfall that spends nothing until it has to: syntax and mail servers, then likely patterns, then a direct probe, and only then a paid provider, which asks for approval before the money goes. Every person moves along one forward-only spine, so a reply read as positive cannot drag back somebody who has already asked to be left alone. The reviewer ladder decides who may clear a letter, and replies and drafted answers wait in the Inbox, where an agent may write an answer and may never send it.

Projects

Projects is the tracker of record. An item is the unit of work: epics group items under a plan, sprints hold the week the work is done in, and milestones hold the date it has to land on. A card moves through one door whether a person drags it, an agent calls a tool, or a merged change names it, so a rule that stops you stops the agent too. Review is a gate somebody else opens. An item marked as needing review stops in In review and waits for a person other than its author, an agent is never that person, and anything an agent finishes waits whether it was marked or not.

Agents and MCP

Every instance answers on one endpoint, POST /mcp, and an agent holding a token reaches the same routes the screens call. There is no second way in: a tool composes a request, hands it to the instance’s own router as the token’s principal, and meets whatever gate a person would have met. The tools cover the admin surface, the Revenue Engine and the Projects board, and each one keeps the rule its section already describes: an agent drafts and never sends, a dry run is the default on an import, the spine is forward-only, and a move to done parks in review. What a token may do is set when it is minted. Bound to a user it acts as that user; bound to nobody it carries only its own policies. Two scopes are withheld unless an administrator ticks them, one for the sixteen acts that put something beyond recall into the world, and one for running scripts of your own inside the instance. No token mints tokens.

Goals

Goals is a proposal, and nothing in it is running. The design, PD014, describes a goal as a sentence with an owner, and a key result as a number under it with a baseline, a target and a source, with everything else a link to work Neutron already tracks. There is no Goals screen, no table behind it, and no way to record an objective in the product. Until it ships, a quarter is a handful of plans and a year is the milestones on the timeline. Do not plan around it.

Federation and orbits

A Neutron Core is not one deployment everybody logs into. Cores federate with each other as peers over the same authenticated interface the rest of the product uses, so one core driving another is gated and audited like any other action. Wiring a peer is a deploy-time configuration step rather than a click, because the token involved is one a browser must never hold. Below each core sit its orbits, satellite nodes it controls centrally so an agent can act where the work is instead of on shared infrastructure. An orbit keeps its own limits locally, because a network round trip is too slow to stop a runaway input loop.

Last updated on 17 September 2026