Architecture
NodalMerge is the engine; Studio is the runtime. The Rust core provides durable graph storage, CRDT convergence, replication, replay, and branching. Studio is the collaborative environment humans and agents actually live in — goals, reasoning, execution, projections, and review — with NodalMerge as the storage engine beneath it. Studio is not a UI over a version-control tool; it’s a runtime that uses NodalMerge the way an application uses a database.Three-layer design
Key architectural principles
- NodalMerge is the source of truth. All persistent state resides in NodalMerge nodes.
- Agents reason over projections. Agents never consume raw DAG history.
- Work unit-centric execution. Every agent session is scoped to exactly one work unit.
- Human-governed promotion by default. Agents propose; a human approves merges unless a goal explicitly opts into agent-approved review, and even then a promotion branch can keep automated applies off
main. - Immutable history. DAG nodes are append-only; updates create new nodes.
Product surfaces today
Multi-peer goal sourcing
Goal creation isn’t limited to a human typing into the Goal Workspace. Anything that can reach the Studio host’s REST or MCP surface — another headless peer, an external system, or a different human’s Studio instance connected to the same room — can create goals and record constraint artifacts alongside interactively created ones. See Guides → Extending goals for the REST surface and Guides → Headless peer for how a connected peer joins a room and appears in the extension in real time — in the Model & Agent Studio tab’s Participants table, alongside interactively-spawned agents. This matters architecturally because every goal, regardless of source, funnels through the same governance surface: review policy (Human Required / Agent Approval / Hybrid), optional build/test execution gates, and domain observers
that record constraint artifacts reactively as work progresses. A goal created by a
webhook handler or a persistent monitoring peer is not treated differently from one
typed by a person — it still proposes, it doesn’t unilaterally merge.
In practice this means a persistent headless peer (PeerType: "persistent-agent")
watching logs, metrics, or alerts can turn a real-time operational signal directly
into a goal or a recorded constraint, without a human having to notice the signal
first and manually kick off the work. Combined with AllowAgentGitCommits /
AllowAgentGitPush and an external CI/CD pipeline, this is the shape of a system
that reacts to its own operational state — see
Guides → Extending goals
for the concrete pattern. Whether that loop closes all the way to production is a
function of what you wire up outside Studio (your CI/CD pipeline, your review
policy choices) — Studio’s job is to make sure every step in that loop, however it’s
triggered, stays inspectable, branchable, and gated the same way manual work is.
MCP integration
NodalMerge Studio exposes a frozen MCP v1 tool surface with 117 tools across 21 namespaces (nm_v1_*), 72 of which are dispatched in-process to autonomous agents.
A separate 14-tool nms_v1_* surface is the recommended entry point for external MCP
clients (Claude Code, Cursor, CI scripts) — see
Reference → API surface.