One Conductor per workflow
The controller node is deliberately singular. Two things in charge is the same as nothing in charge.
Symphony is the canvas where agents, apps, data sources, and people become one process. You drag the parts out, connect them, and put a Conductor over the top. Then you run it and watch every player from the podium.
Multi-agent systems fail in a specific way. Each agent does something defensible and the aggregate does something nobody sanctioned. The fix is not smarter agents, it is a score everyone plays from and someone at the front who can stop the piece. Symphony is built around that structure rather than around the agents.
The controller node is deliberately singular. Two things in charge is the same as nothing in charge.
The canvas shows which agents the Conductor oversees, on by default, because a governance tool should tell the whole story on first look.
A checkpoint where a person decides is part of the diagram, not an informal step somebody remembers to do.
A kill node is something you place on the canvas, and a running workflow can be cancelled mid-flight.
Every workflow is built from the same small vocabulary. Small enough that a committee member can read a canvas without training, expressive enough to describe how the work really runs.
The supervising node. It dispatches work to the agents beneath it, waits on results, and holds the running parameters the whole workflow shares.
Any agent you have built, dropped in as a step. It arrives with its own tools, guardrails, and approval gates already attached.
A Vibe app as a node, either as the place the workflow puts its results or as the interface a person uses partway through.
Read your own tables or call an external service. The systems a process depends on appear on the diagram instead of hiding inside an agent's prompt.
Split work across parallel branches, wait for them to converge, or send the flow down one path based on what came back. Ordinary control flow, drawn.
Deliver a result outward, pause for a person to approve or decide, or halt the run. The three ways a process reaches the outside world or stops.
Agents and Vibe apps both declare what data they take in and what they hand back. When you draw an edge between two nodes, Symphony compares the two contracts. If the upstream node does not produce what the downstream node needs, you find out at design time, on the canvas, with an offer to reconcile it. Not at three in the morning during the first real run.
Input and output shapes are declared per asset, so an edge is a checkable claim rather than a line on a picture.
When an edge does not line up, the platform can patch the contract in place without disturbing the app's code or the agent's prompt.
Place a node with nothing to point it at and jump straight to Agents or Vibe to create it. You return to the canvas with the new asset already selected on the node.
A run carries parameters every node can read, so the same workflow serves a different department or period without being rebuilt.
A run executes in the background rather than tying up a browser tab, and the canvas follows along. You can see where the flow currently is, open a conversation with an individual agent node while it is working, and stop the whole thing without waiting for it to finish.
The canvas polls the run and reflects progress on the nodes themselves, so the diagram you designed is the same diagram you monitor.
Open a chat against an individual agent while the workflow is executing. Ask what it is doing and why, in the middle of it doing it.
Kill a running workflow from the canvas. The runner checks for cancellation between steps rather than only when it finishes.
Past runs are listed per workflow with their outcomes, so a process that has drifted shows up as a pattern rather than an anecdote.
Inside a workflow, agents get tools for dispatching to peers, waiting on them, and reading their output. Coordination is a recorded tool call, not an emergent side effect.
A run started by a schedule or another system shows up on the canvas of anyone watching, instead of executing invisibly.
Building a workflow and putting it into production are separate acts. Publishing raises a request to the committee that owns the area, and until they approve it the workflow runs for the person who built it and nobody else. It is the same approval machinery that governs policies, use cases, and agents, which is the point. One oversight process, not a different one per feature.
Book a demo and bring a process that currently spans three teams and a chain of email. We will lay it out on the canvas, put a Conductor over it, mark the step that needs a human, and run it while you watch.