Multi-Agent Federation for SysML v2 Engineering

System agnostic

One method for any system

Nothing in the method assumes a domain. A subsystem is whatever your SysML v2 package tree says it is, and contracts come from the interfaces your model declares. The swarm is not tied to a vendor either: any MCP client can take part.

Reference architecture

Hub and spoke architecture

The hub is MBEstudio: one system with three inner parts, the orchestrator, the model and the conflict engine. Everything else is a spoke. Agents read contracts from the hub and submit fragments back to it, and engineers review what the hub proposes. Each spoke has its own port on the hub, and no spoke talks to another.

SysML v2 interconnection view of the swarm: MBEstudio at the center, highlighted at the center, each spoke on its own port: the orchestrator, three subsystem agents, a critic agent, the engineer and existing tools — Figure 1. Interconnection view of the swarm, drawn by the MBEstudio Diagrams view. The highlighted hub is MBEstudio. agentN stands for as many agents as the system needs.

SysML v2 interconnection view inside MBEstudio: orchestrator, conflict engine and model, with boundary ports bound to them — Figure 2. Inside MBEstudio. The orchestrator directs the swarm, the conflict engine is the only path into the model, and a commit is the only way the model changes.

The goal is for the swarm to take over authoring and analysis that used to need a separate tool for each job. Where a program still depends on those tools, they stay connected as a spoke, so nothing has to be replaced on day one.

AI orchestrators

AI orchestrators direct the swarm

An AI orchestrator is the agent that runs the others. It reads the system level mission and requirements, divides the work by subsystem, starts a specialist for each one, and reacts to what comes back. It holds the plan so no single agent has to hold the whole architecture.

Orchestration is moving into the hub. Today MBEstudio does not spawn agents, so you bring your own: any MCP client that can coordinate others can be the orchestrator, such as Claude Code with sub-agents. These tools are what it drives:

Orchestrator step	Tools
Find the work	`mbe_list_subsystems`
Brief each agent	`mbe_get_context`
Stage and merge results	`mbe_submit_fragment`, `mbe_reconcile`
React to conflicts	`mbe_list_conflicts`, then re-prompt the agent or `mbe_resolve_conflict`
Land approved work	`mbe_commit`
Export artifacts, records and reports	`mbe_export`, `export_model`

Workflow

From contracts to committed model

SysML v2 activity diagram with swimlanes for the orchestrator, three agents, MBEstudio inner lanes for the orchestrator, model and conflict engine, and the engineer, from decomposition through parallel build, reconciliation, review, commit and export of artifacts, records and reports — Figure 3. Activity view of the swarm. The highlighted inner swimlanes are MBEstudio: the orchestrator, the model and the conflict engine. Each swimlane comes from an allocation in the model; the band that groups them is added for this page.

SysML v2 state transition view: decompose, generate, reconcile, human review, committed and exported, with conflicts and rejections looping back through resolve conflicts — Figure 4. State transition view. This machine was executed in the MBEstudio simulator through a conflict, a re-prompt and a commit. Download the SysML v2 source.

Your orchestrator

1. Decompose

The orchestrator takes the system level mission and reads the top level requirements. It lists the subsystems and assigns a specialist agent to each.

Available

2. Generate to contract

Each agent in the swarm pulls its context through MCP and works independently, bound by frozen boundaries such as port dataIn : DataPort. It authors SysML v2 fragments without needing the internals of its siblings.

Available

3. Reconcile and review

Each fragment is compiled in the whole model. A changed value on a frozen boundary is an interface conflict. Two sides of a connection that disagree on throughput are a rate conflict. The orchestrator can re-prompt the agent, and a proposal is reconciled again if the model moved while it waited.

Why it fits MBSE

Why swarms suit systems engineering

Available

Scale past one context window

Large architectures outgrow a single prompt. A swarm divides the package tree, and each agent loads only its own slice and boundary.

Partly available

Parallel trade studies

Give each agent one architecture variant and have the orchestrator combine the results. Agents run declared studies of up to 256 design points each and get a Pareto front. NSGA-II runs in the studio; it is not yet enabled through the agent worker.

Agent driven

Independent critics

While some agents author structure, critic agents can read the same model and your standards to look for gaps, missing verification criteria and orphan ports. Critics support a review; they do not establish compliance.

Responsibilities

Who does what

Layer	Provided by	Role
Orchestrator and swarm	You, in any MCP client	Decompose the system, spawn agents and generate fragments.
Hub	MBEstudio	Hold the model, serve contracts, compile fragments in context and return typed conflicts as one proposal.
Sign-off	Your systems engineers	Review the proposal and its conflicts before it is committed.
Export	MBEstudio	Produce artifacts (SysML, STL, scene JSON), records (engineering CSV and element provenance) and HTML reports from the committed model.
Exchange	MBEstudio and your tools	Send subsystems to SysML v2 API tools, .sysml files and Cameo through XMI. Conflict types and exchange details.

The model underneath

Evaluate the design in the model

One SysML v2 source connects the assembly, 3D geometry, interfaces, requirement margins, state behavior and design trades. Engineers work on it in the studio; AI agents work on the same model through the agent interface, and both get the same checks.

Open the studio Follow the demo

Architecture

How we construct the digital twin

A digital twin is only worth trusting when its electrical, software and mechanical parts are one model, not three models kept in step by hand. MBEstudio builds the twin around the same hub shown above: a typed, directed model graph behind the conflict engine. Its nodes are model elements (parts, ports, requirements, states) and the artifacts linked to them; its edges are typed relations such as owns, typed by, specializes, connects, satisfies, verifies and derived from. Every agent and tool is a spoke. A spoke either writes into the graph through the hub or reads what is derived from it, and no tool ever calls another.

SysML v2 cannot hold every kind of engineering data, and it is not asked to. The SysML v2 text is the authoritative serialization of the system model portion of the graph: MBEstudio's compiler builds that portion from the text today, with its owned by, typed by, specializes, subsets and redefines relations shown on the Ontology page. CAD solids, PCB layouts, meshes, simulation time series, FMUs, source code and test logs stay in their own tools' formats and attach to the graph as linked artifact nodes that record the source tool, the file and its version or hash. Artifact nodes are planned, not built yet.

One model, three disciplines

Electrical and electronic

ports · buses · power rails

Electronics are parts with typed ports, joined by interfaces. Each part states what it draws from or supplies to a bus or rail: positive consumes, negative supplies. The compiler sums every bus and reports its margin, and a bus with demand but no declared supply stays indeterminate instead of passing. A KiCad netlist brings component values, footprints and pin to net membership onto the parts it describes.

Software

states · latency · integrity

Behaviour is written as state machines with timed transitions, guards and assignments, and the simulator runs them so each requirement is checked across the states where it applies. Latency and data rate are budgets on the same buses the hardware rides. Integrity levels and isolation groups flag any connection that crosses a partition without a barrier.

Mechanical

envelopes · bodies · placement

Every part has at least an envelope, and can state its real shape as lofts, extrusions and revolves whose dimensions are expressions over its attributes, so a trade that moves an attribute moves the geometry. Placement follows the interface graph, and mass and packaging are evaluated against those shapes. An Onshape BOM maps onto part attributes, and STEP export writes the envelopes out.

What the architecture will not let you do

Tool A never talks to tool BBoth talk to the graph. A second copy of the design would be a second place for it to disagree with itself, so an import, an agent and a drag in the 3D view all end as the same thing: an edit to the SysML text that the compiler accepts or refuses.
One compiler, everywhereThe studio, the MCP server and the command line run the same Rust compiler, built to WebAssembly, so the verdict in the browser is the verdict an agent or a CI job gets.
Every value carries its sourceAn evaluated value says whether it was stated, computed from an expression or estimated and flagged for review. A missing input stays indeterminate; it never defaults to a pass.

Import source files stay in the browser; only the mapped values enter the model. An import can also add a new part and place it in the decomposition, with the owner suggested from the model and the evidence behind each suggestion shown. Connect an agent over MCP.