We settled on a naming decision this week: Neuron is the system. Orion is the agent. It helped clarify what I expect each part to do.
An agent can research a question, propose a change, or review an artifact. The surrounding system needs to know what was requested, what permission was granted, which version was changed, and what still needs a person's judgment. Those responsibilities should survive the end of a conversation.
That is the direction behind our current Neuron work. Orion gives the agents an identity inside it. Naming the two does not mean the integration is finished; it gives us a clearer boundary to build against.
The work needs a home outside the conversation
A chat is useful for deciding what to do. It becomes a difficult place to reconstruct a project when the instructions, files, approvals, and results are spread across several sessions.
I want to return to a task and answer ordinary questions: What is the current artifact? What evidence supports its status? What is waiting for me? If an agent stopped halfway through, where should the next attempt begin?
In the proposed architecture, Neuron owns that continuing record. An Orion agent takes an assigned role within it. Research, Build, and Review are useful possible roles because they describe responsibility. They do not, by themselves, establish that the work passed review.
A design has to keep its meaning as it moves
Our Journey Design System, or JDS, work brought this into focus. We were working through agent cards and a rehearsal of an experience, then considering where human review belonged.
The intended path is to describe the experience, preserve its meaning through a compiler, render an artifact, and have the person judge the result. Neuron is the proposed harness around that process: tracking the task, its evidence, and any required repair.
For example, a card might explain what an agent intends to do and where a person needs to decide. If the rendered version drops that decision point, a visually attractive card has still lost a requirement. A compiler check can help detect missing structure. A person still needs to decide whether the experience communicates the right thing.
Human acceptance is a distinct step
Passing a structural check, producing a file, and receiving human acceptance are different events. I want the workbench to make each visible.
A useful review handoff would contain the artifact, the checks actually performed, the remaining uncertainty, and the decision being requested. The person should be able to inspect a concrete result without rebuilding the entire conversation in their head.
That also gives repair a specific purpose. A rejected result should lead back to the requirement it missed, followed by another review of the changed artifact. Repeated attempts should leave a readable history.
Where this stands
The JDS-to-Neuron integration is architecturally specified. The Orion naming decision is accepted. The complete runtime connecting those pieces remains work to implement and verify.
The next useful demonstration is one task moving through the whole proposed path: a preserved requirement, a rendered result, recorded checks, a human decision, and a traceable revision if needed. That is the standard I want the names to stand for.
Record and method
Written September 28, 2026, from our recent agent-card, JDS, and Neuron design discussions. AI assisted with drafting. This article describes an architectural direction and its acceptance criteria; it does not announce an available Orion product or completed integration.

Compare notes
What happened when you tried it?
Questions, useful disagreements, and corrections welcome. Comments are reviewed before publication. Discussion guidelines.
Loading discussion…
Sign in to join the discussion