MASFactory: Graph-Based Multi-Agent Orchestration

• MASFactory is a graph-centric framework that unifies heterogeneous agents using directed computation graphs and human-in-the-loop workflow generation.
• In manufacturing control, MASFactory coordinates a layered simulation architecture with a Hybrid Agent bridging MES logic and hardware simulation to optimize scheduling.
• In LLM-based applications, MASFactory utilizes Vibe Graphing to transform natural-language intent into reusable workflows, reducing development effort and enhancing reproducibility.

MASFactory denotes a graph-centric framework for orchestrating LLM-based multi-agent systems, introduced as a directed-computation-graph abstraction with human-in-the-loop workflow generation through Vibe Graphing (Liu et al., 6 Mar 2026). In the supplied literature, related usage also appears for a simulation platform for multi agent based manufacturing control systems organized around a Hybrid Agent, a Multi-Agent System layer, and a Hardware Simulation Agent (Barenji et al., 2016). This suggests that the name has been used for distinct infrastructures whose common theme is the coordination of heterogeneous agents, components, and execution flows.

1. Terminological scope

The label MASFactory is not univocal in the supplied arXiv material. One usage concerns shop-floor manufacturing control and simulation; the other concerns LLM-based workflow orchestration. The distinction is technically significant because the former centers on MES logic, XML-RPC mediation, and hardware simulation, whereas the latter centers on directed computation graphs, reusable graph components, and human-in-the-loop graph compilation.

Usage	Domain	Core organizing abstraction
Simulation platform for multi agent based manufacturing control systems	Manufacturing control and scheduling	Hybrid Agent bridging MAS and Hardware Simulation Agent
MASFactory	LLM-based multi-agent orchestration	Directed computation graph with Vibe Graphing

A common source of confusion is to treat these as a single lineage. The supplied record instead supports a narrower conclusion: the same name, or a closely related naming convention, appears in two different technical contexts. Another important qualification concerns formalization. For the manufacturing-control platform, the detailed overview explicitly states that the original paper did not supply explicit equations or algorithms, and that standard formulations for scheduling and resource allocation were restated to illustrate what one would embed in such an environment. By contrast, the LLM-oriented MASFactory is presented directly as a formal graph model.

2. Manufacturing-control MASFactory: layered simulation architecture

The manufacturing-control platform is organized into three vertically layered modules: a User Interface, a Hybrid Agent layer, and a Multi-Agent System layer, together with a Hardware Simulation Agent that models shop-floor machinery, transport, and sensors (Barenji et al., 2016). The Hardware Simulation Agent can be any discrete-event simulator, with CPN Tools used in the case study, and it offers an XML socket-based API through which the Hybrid Agent injects part-release commands and reads back machine statuses, sensor events, and completed-job notices. The MAS layer implements MES logic through agents including Shop Management Agent, Shop Monitoring & Command Agent, Agent Manager, Station Control Agent, Station Monitoring Agent, Agent-Machine Interface, and Resource Agent. Agents share a capability-based ontology for product definitions, resource capabilities, and job-order attributes, and all inter-agent traffic is XML-encoded.

Within this stack, the Hybrid Agent is defined as a software entity that simultaneously maintains bilateral XML-RPC links with the Multi-Agent control layer and the Hardware Simulation layer. It presents itself to each as a peer agent while internally performing protocol translation, queueing, buffering, and state reconciliation. Its key responsibilities are real-time event forwarding in both directions, XML schema validation and mapping between the agent ontology and simulator resource IDs, and basic conflict resolution when simulator and MAS disagree on resource states. Its internal structure is decomposed into an XML RPC Server, an Event Dispatcher, and a State Manager; the XML RPC Server listens on two ports, one for MAS requests and one for HSA notifications, the Event Dispatcher routes incoming XML to handlers such as NewOrder, ResourceStatus, and JobComplete, and the State Manager caches resource and job statuses to reduce polling.

The new-job workflow is correspondingly mediation-heavy. An external user or order database sends a <NewOrder…/> XML message to the Hybrid Agent; the Hybrid Agent parses it and wraps it in a Contract-Net-style call to the Shop Management Agent; the Shop Management Agent queries a Database Agent for product and process-plan data, checks resource availability through Station Control Agents, and, if accepted, returns a JobAccepted message to the Hybrid Agent; the Hybrid Agent then issues a release-part call to the Hardware Simulation Agent. When the simulator later emits JobDone(partID), the Hybrid Agent dispatches a completion update back into the MAS.

The detailed blueprint also restates standard formulations that are compatible with such a MAS environment. A task-assignment model is given with tasks $T=\{t_1,\dots,t_N\}$, machines $M=\{m_1,\dots,m_K\}$, processing times $p_{ij}$, binary assignment variables $x_{ij}$, and makespan objective

$\min C_{\max}$

subject to

$\sum_{j=1}^K x_{ij}=1 \quad \forall i\in T,$

$$\sum_{i=1}^N p_{ij}x_{ij}\le C_{\max} \quad \forall j\in M.$$

Lead time, throughput, and repeatability are likewise restated as

$$L_i=t_{order-release}+t_{queue}+\sum(process\ times)+\sum(move\ times)+\sum(inspections),$$

$$Q=\frac{total\ completed\ items}{simulation\ horizon},$$

and

$$R=\mathrm{mean}_{runs}\left[\mathrm{stddev}_j(U_j)\right].$$

Because the overview explicitly labels these as standard insertions rather than explicit formulations from the paper, they are best understood as a formalization of the platform’s scheduling and resource-allocation setting rather than as a closed optimization model claimed by the original study.

3. Case study, roles, and empirical findings in the manufacturing platform

The manufacturing case study is a flexible manufacturing system located in the EMU CIM lab (Barenji et al., 2016). Its cell layout comprises Station 1 with CNC milling and a 5-axis articulated robot for loading and unloading; Station 2 for assembly and quality control, including a gluing machine and a laser scan micrometer for CMM-style measurement; and Station 3 as an Automatic Storage & Retrieval System. Material flows through a conveyor linking Station 1, Station 2, and Station 3.

Agent responsibilities are partitioned by level. At the shop level, the Shop Management Agent coordinates job releases and global planning, the Agent Manager maintains the agent registry and ontologies, and the Shop Monitoring & Command Agent oversees shop-wide exceptions. At the station level, the Station Control Agent performs local scheduling and resource negotiation, the Station Monitoring Agent detects failures and raises alarms, the Agent-Machine Interface acts as a low-level actuator and sensor driver, and the Resource Agent reports status and capabilities to station control. The pseudocode and sequence sketches in the supplied overview emphasize Contract-Net-style coordination: the Shop Manager broadcasts CFP messages, Station Control Agents generate proposals or refusals based on local resource capabilities and estimated free times, and accepted stations reserve resources and drive execution via the AMI until jobDone.

Performance is reported for 1000 order books, with each book consisting of 3 parts. The metrics are Manufacturing Lead Time in seconds, Throughput in parts per second, and Repeatability defined as the mean standard deviation of percentage utilization over multiple runs. Two scenarios are considered: a stable scenario with no disturbances and an unstable scenario in which Station 1 has failure probability 20%. The evaluation methodology specifies 30 replications of 1000-book order streams, logging lead times, throughput, and utilization at each run, and computing mean and standard deviation.

The reported results compare a Conventional MES against RFID-MAS. In Scenario A, lead-time is approximately $M=\{m_1,\dots,m_K\}$0 for Conventional MES and $M=\{m_1,\dots,m_K\}$1 for RFID-MAS; throughput is approximately $M=\{m_1,\dots,m_K\}$2 parts versus $M=\{m_1,\dots,m_K\}$3 parts; and repeatability changes from high variance to lower variance. In Scenario B, lead-time is approximately $M=\{m_1,\dots,m_K\}$4 for Conventional MES and $M=\{m_1,\dots,m_K\}$5 for RFID-MAS; throughput is approximately $M=\{m_1,\dots,m_K\}$6 parts versus $M=\{m_1,\dots,m_K\}$7 parts; and repeatability changes from poor to better. The key findings section summarizes these results as lead-time reductions of about $M=\{m_1,\dots,m_K\}$8–$M=\{m_1,\dots,m_K\}$9, throughput increases of $p_{ij}$0–$p_{ij}$1, graceful degradation under failures because jobs are rerouted to alternate resources instead of dead-locking, and lower utilization variance. A plausible implication is that the Hybrid-Agent bridge was treated not merely as an interface convenience but as the enabling mechanism for testing control logic against realistic shop-floor events without rewriting agent code.

4. LLM-based MASFactory: graph model and Vibe Graphing

In the 2026 usage, MASFactory is defined as a graph-centric framework for orchestrating LLM-based multi-agent systems, with workflows modeled as directed computation graphs whose nodes execute agents or sub-workflows and whose edges encode dependencies and message passing (Liu et al., 6 Mar 2026). Formally, the framework represents a workflow as

$p_{ij}$2

where each node is a computation unit such as an Agent, a sub-Graph, a Loop, a Switch, an Interaction point, or a Custom node, and each node carries attributes including type(v), prompt_v, input slots $p_{ij}$3, output slots $p_{ij}$4, and context resources $p_{ij}$5. Edges are represented as message-bearing relations $p_{ij}$6, where $p_{ij}$7 is a possibly empty message transformer.

Graph compilation proceeds in three stages. First, natural-language intent is converted into a Role Assignment IR through an LLM, specified in the paper as gpt-5.2 wrapped in a VibeGraph agent, producing a role table of agent IDs and responsibilities. Second, the role table is converted into a structure skeleton $p_{ij}$8 that decides which roles run in sequence or parallel. Third, semantic completion assigns full prompts, input-output schemas, and context-adapter bindings to each node, yielding a JSON- or YAML-style specification that can be compiled through RootGraph.build() into an in-memory Graph object.

This compilation process is operationalized as Vibe Graphing, described as a three-stage, human-in-the-loop pipeline. The built-in ComposedGraph named VibeGraph wraps three Loops, each containing a specialized Agent node and Interaction hooks: Loop_1 with RoleAssignmentAgent + Interaction, Loop_2 with StructureDesignAgent + Interaction, and Loop_3 with SemanticCompletionAgent + Interaction. At each iteration, the user may either accept the proposal or provide textual feedback or direct edits through the VS Code Visualizer. The high-level pseudocode expresses iterative refinement at each of the three stages and ends with compile_to_graph(IR_3). This matters conceptually because MASFactory does not frame workflow generation as a one-shot prompt-to-program mapping; it treats graph construction as an editable intermediate-representation pipeline.

5. Modules, execution semantics, and empirical evaluation in the LLM framework

The LLM-oriented MASFactory is built on Node and Edge primitives and provides Graph and Loop components for static and cyclic sub-workflow composition, Switch nodes for conditional routing, Interaction nodes for human-in-the-loop pauses, Agent nodes implementing Perception–Reasoning–Action, and two pluggable adapters: MessageAdapter for JSON, Markdown, or plain-text protocols, and ContextAdapter for unifying Memory, RAG via LlamaIndex, MCP, and related context sources (Liu et al., 6 Mar 2026). Reusability is supported through NodeTemplate and ComposedGraph, while the Visualizer, implemented as a VS Code extension, shows static topology, runtime traces, messages attached to edges, node states, and interaction panels for approving or refining VibeGraph outputs. The same interface supports real-time IR editing and execution monitoring.

Execution is specified over a shared graph-level state $p_{ij}$9. When a node becomes ready, it concatenates incoming edge messages into input_v, reads context from $x_{ij}$0 and $x_{ij}$1, executes Exec_v(input_v, ctx_v; prompt_v), emits transformed outputs onto outgoing edges, and updates the shared state by $x_{ij}$2. For an Agent node, Exec_v is instantiated as an LLM_call(model, prompt = prompt_v ∥ input_v ∥ ctx_v). Scheduling is readiness-based: any node whose predecessors have all fired is eligible, and parallel nodes may execute concurrently. The paper does not give a closed-form latency model, but it states that end-to-end cost is approximately the sum of model costs over agent nodes, and that Table 2 shows the Vibe Graphing stage using much fewer tokens and dollars than a baseline Vibe Coding approach.

Empirically, the authors reproduce five published MAS systems inside MASFactory—ChatDev, MetaGPT, AgentVerse, CAMEL, and HuggingGPT—and evaluate on seven benchmarks: HumanEval, MBPP, BigCodeBench, SRDD, MMLU-Pro, GAIA, and GPQA. The main quantitative findings are that MASFactory versions match or exceed original scores in most cases, with MetaGPT increasing from $x_{ij}$3 to $x_{ij}$4 on HumanEval; that end-to-end generated workflows from Vibe Graphing achieve $x_{ij}$5 on HumanEval versus $x_{ij}$6–$x_{ij}$7 for hand-coded ChatDev; and that implementation cost decreases from approximately $x_{ij}$8 lines of code for original ChatDev to $x_{ij}$9 for MASFactory manual reuse, $\min C_{\max}$0 for VibeGraph-ChatDev, and $\min C_{\max}$1 for VibeGraph-TaskSpec. The framework’s public artifacts include code and a demonstration video. Taken together, these results position MASFactory as an orchestration layer intended to increase reproduction consistency and reduce workflow authoring effort through graph reuse and intent-driven compilation.

6. Limitations, misconceptions, and proposed extension paths

Several misconceptions can be addressed directly from the supplied material. First, MASFactory should not be reduced to a single system description. The record shows one manufacturing-control platform centered on XML-standardized bridging between MAS logic and hardware simulation, and one LLM-oriented framework centered on graph-centric orchestration and Vibe Graphing. Second, the manufacturing-control overview contains explicit pseudocode, sequence diagrams, and optimization formulas that are identified as standard restatements or illustrative insertions where the original paper did not provide explicit equations or algorithms. Third, the LLM framework’s workflow-generation pipeline is explicitly human-in-the-loop: each stage includes acceptance or refinement rather than fully autonomous compilation.

The LLM-oriented MASFactory also states concrete limitations. It has no built-in checkpointing or resume after interruption, and the library of ComposedGraph templates is still growing. Possible extensions named in the paper include first-class support for streaming and real-time sensing such as tool hooks and vision agents, distributed execution across multiple GPUs or edge devices, stronger formal guarantees on liveness in cyclic graphs and deadlock-free scheduling, tighter integration with knowledge graphs and ontologies via standardized MCP protocol, and automatic template extraction by mining repeated subgraphs from existing workflows.

A separate technical blueprint based on the serving system M* proposes how MASFactory could adopt a Walk Graph-style architecture rather than claiming that it already has one (Jha et al., 10 Jun 2026). The proposal is to implement Walk Graph primitives and a parser, provide a base Component interface together with stateless and KV-cache engines, embed a Conductor + Worker pattern with ZeroMQ or gRPC, expose a YAML/JSON placement API for $\min C_{\max}$2, and bundle standard ChunkPolicy implementations while allowing user-supplied ones. Because this material is framed as “To adopt M*’s blueprint in MASFactory,” it is best read as a prospective systems direction: a convergence path in which graph-centric LLM orchestration could inherit explicit placement, distributed runtime control, and multimodal streaming abstractions from composite-model serving research.