What Symphonix is

A platform for building AI agents that your organisation runs itself — described in a file, compiled into a project you own, deployed one at a time, and watched from one place.

The problem it solves#

Organisations that try to put AI agents into real use meet the same three difficulties, and they arrive in this order.

The first is that an agent is easy to prototype and hard to pin down. A prompt and a few tool calls demonstrate something in an afternoon. What that demonstration does not have is a definition — something a second person can read, review, change and be sure they have understood. Symphonix makes the definition the artefact: an agent is a flow file, and everything the agent may do is declared in it.

The second is that the thing you demonstrated has to become something you can run. Running it means a process with an address, secrets it reads from somewhere, a record of what it did, an upgrade path and a way to stop it. Symphonix compiles a flow into an ordinary Node project with all of that already in it, and the engine is vendored and pinned inside the project rather than installed around it.

The third arrives when there are nine of them. Nobody can tell which are up, which are failing, what they are spending, or which of them is allowed to call the tool that writes to the CRM. The Control Panel is for that, and it is deliberately a separate component: the agents keep running when it is down, and it has no power to change what an agent is.

Who it is for#

Three roles, and the platform is divided along them rather than along technology.

• Whoever builds the agent. Works in the Studio. Needs to describe behaviour, connect systems, test, and deploy — and does not need to write the client code for an MCP server or the plumbing of a chat page, because those are generated.
• Whoever runs the estate. Works in the Control Panel. Needs to know what exists, what is healthy, what is costing money, who may do what, and how to stop something quickly.
• Whoever uses the agent. Gets a chat page served by the agent itself, which may be open to anyone or restricted to named people, and which is where forms, tables, charts and approval requests appear.

What an agent is here#

In this platform an agent is a graph of steps over a shared set of named channels, compiled to LangGraph, the graph runtime underneath. That sentence is doing real work, so taking it apart:

• Channels are the agent's state — named, described, and declared up front. Every step reads and writes them, and the descriptions are the contract that generated code is written against.
• Nodes are the steps. Some ask a model something; some run a tool; some call out to an MCP server; some search a knowledge collection; some stop and wait for a person.
• Edges join them. A plain edge always goes the same way. A conditional edge chooses, and which route it takes is decided by generated code — or, where the decision depends on what somebody meant, by a model, which the platform will insist on in the one case where it matters.

What an agent is not is a prompt with tools bolted on. Everything it may reach — a tool, an MCP server and the specific tools on it, a knowledge collection, a database, who may talk to it — is declared in the flow, which means it can be read, reviewed and refused before anything runs.

The three components, and how they divide the work#

Symphonix Core — the language, the compiler and the runtime#

Core owns what a flow may say. It validates a flow against the language version the flow declares, refuses the ones it cannot accept, generates a complete project from the ones it accepts, and provides the runtime that project uses. It is also what runs inside every deployed agent, vendored into the project and pinned to a version.

Two things worth knowing from the outside. Every flow declares a language version and gets exactly that version's features, and every version from the first still compiles — so an agent written a year ago does not stop working when the language moves. And a flow may not contain code: there is no node that carries JavaScript. Where behaviour has to be written, the flow carries a description and the installation generates the code from it, which is what makes a flow reviewable and a shared solution safe to accept.

Symphonix Studio — where agents are built#

A visual editor for flows. You draw the graph on a canvas, or describe what you want in the Ask bar down the left and have it written for you; both produce the same file.

The canvas sits in the middle. Down the right is a panel whose tabs are everything a flow declares — Flow, Chat template, Page, Views, In & out, MCP servers, Knowledge, Databases, Services, Settings, Tools and State — and which becomes the selected node's own settings when you click a node on the canvas. Along the bottom is Problems, the validator's standing opinion of the flow rather than something you run: it reads valid · ready to generate when the flow is sound, and otherwise names each refusal and hint with the exact place in the file it came from. Save and Play are in the top bar, and Open project… and Deploy all… beside the project name.

Symphonix Control Panel — where the estate is run#

The board every deployed agent reports to. It holds people and their roles, the list of agents and what each is doing, health and runs and what a run cost, the approval groups and rules that decide who is asked when an agent pauses for a person, organisation policy, and the catalogue of MCP servers available to the organisation.

It is a governance surface, not a host. Agents run whether or not it is up; what it adds is the ability to see them, to stop them, and to narrow what a particular agent may do.

Design time and runtime, and why the line matters#

The Studio and Core's compiler are design time. They turn an intention into a project. Nothing they do is needed again once that project exists.

A deployed agent is runtime. It is an ordinary Node project — npm install and node run.js, or one container image — containing the flow, the generated code, the engine vendored at a pinned version, and its own .env. It serves its own chat page on its own port, keeps its own journal and its own waiting state on its own disk, and dials out to the Control Panel to report.

The practical consequences are what the line is for:

• The Studio can be off. Agents do not need it to run, and nothing a running agent does goes through it.
• Upgrading the platform does not upgrade your agents. Each project carries its own pinned copy of the engine, so a new Core version changes what you build next, not what is already running. Agents move when you redeploy them, one at a time.
• Blast radius is one agent. A flow that misbehaves, a bad dependency or a crash takes down that project and nothing else. There is no shared process for agents to interfere in.
• They scale and fail separately, and can sit on different machines, in different networks, with different credentials.

How external systems are connected#

Four doors, and each one is declared in the flow and configured in the deployment.

• MCP servers. The flow names a server and the tools it may call. Where that server is, and what credential reaches it, come from the deployment's environment; the client code is generated from the declaration rather than written by a model. Released
• Knowledge collections. A named body of documents, indexed once and asked many times. The flow names the collection; the folder of documents belongs to the deployment, and lives on the machine the Collection Server runs on. Released
• SQL databases, through the SQL Connection Manager — a separate component that owns the database drivers so that neither the engine nor any generated agent has to. It holds the connections, reads a schema, and the saved diagram decides what an agent is offered of a database. Postgres, Oracle and SQL Server. Released
• Triggers. What starts an agent when nobody is talking to it: a schedule, an event, or a webhook. Released

From an idea to a watched agent#

1. Describe or draw it in the Studio. The result is a flow file.
2. Check it. The Problems panel runs the validator and the readiness checks, which refuse some things outright and warn about others.
3. Test it with scenarios, and score it with an evaluation if the quality of the answer matters.
4. Deploy it. The Studio writes a complete Node project — the flow, the generated units, the vendored engine, a Dockerfile, a .dockerignore and an .env.example.
5. Start it, as a folder or as a container image. It prints the address it is listening on.
6. It registers itself with the Control Panel by dialling out, and from then on it reports what it is doing.
7. Watch it. Health, runs, what each run did, what it cost, and what needs attention.

Build your first agent walks all seven.

What the platform does not do#

Stated here because a reader evaluating it should not have to discover these.

• There is no hosted service. It is software you run, on your own machines. Released
• The engine is not on a public registry and will not be; it is vendored into each generated project instead.
• There is no notification path out of the Control Panel — no mail, no pager. It shows what needs attention; it does not come and find you. Planned
• Nothing is restarted or retried for you. The Control Panel groups problems by cause and leaves the acting to a person, deliberately.
• There is no guarantee of a single active agent across machines. If you start the same flow twice, the board notices and the second copy stands down — but that is a reaction, not a lock. Released