Symphonix documentation

Everything needed to install the platform, build an agent, connect it to your own systems, deploy it and watch it run — without asking the people who built it.

Start here#

If you have never seen the platform, read these three in order. Together they take about two hours and end with an agent you built, deployed and watched.

• Step 1What Symphonix isThe platform, the problems it solves, how the three parts work together, and what is design-time and what is runtime.
• Step 2Installing the platformEvery component, in order, with the commands — and a checklist that says when the installation is working.
• Step 3Build your first agentFrom an installed platform to a running, monitored agent that answers a question.
• Step 4Build your first MCP agentAn agent that calls tools on an MCP server — declared in the flow, subscribed on the board.
• Step 5Deploy and monitorThe whole lifecycle: deploy from the Studio, start it, watch it, and find out what it did.

By what you are doing#

Evaluating the platform#

Start with What Symphonix is. It explains the problem the platform solves, how the three parts divide the work, what is design-time and what is runtime, and why each agent is deployed on its own rather than run inside a shared service. It is written for somebody deciding whether to bring this into an organisation, and it says what the platform does not do as plainly as what it does.

Installing it#

Installing the platform covers every component in the order they have to start, with the actual commands, the ports each one uses, the environment variables each one reads, and a final checklist that tells you whether the installation is working. It does not assume the components share a machine.

Building an agent#

Build your first agent is the shortest complete path: a flow, a test, a deployment and a conversation. Build your first MCP agent then connects one to tools on an MCP server — which is how an agent reaches your CRM, your database or anything else with an MCP front door.

Running agents in production#

Deploy and monitor is the lifecycle: what the Studio writes, how an agent registers itself, how to start and stop one, what health means, and how to read what a run actually did.

Looking something up#

The developer reference is the specification: every node type and channel a flow may declare, the programmatic surface, the package and collection formats, and the protocol an agent speaks to the Control Panel. Press / anywhere to search it.

Everything on this site#

Guided, start to finish#

Written for this site, each one numbered, each step saying which application it happens in, each section ending with something you can check before you go on.

• GuidedWhat Symphonix isThe platform, the problems it solves, how the three parts work together, and what is design-time and what is runtime.
• GuidedInstalling the platformEvery component, in order, with the commands — and a checklist that says when the installation is working.
• GuidedBuild your first agentFrom an installed platform to a running, monitored agent that answers a question.
• GuidedBuild your first MCP agentAn agent that calls tools on an MCP server — declared in the flow, subscribed on the board.
• GuidedDeploy and monitorThe whole lifecycle: deploy from the Studio, start it, watch it, and find out what it did.
• GuidedDeveloper referenceWhere the specifications are, and how they fit together.

The specifications#

These are rendered from the product repositories at build time, not copied. Each one is the same file the platform's own tests are written against, so it cannot fall behind the software it describes.

• ReferenceThe DSL referenceEvery node type, channel, edge and requirement a flow may declare, version by version.
• ReferenceThe API referenceThe programmatic surface: what each module exports and what it throws.
• ReferenceThe solution package formatWhat a solution package may contain, and the four gates into the library.
• ReferenceThe collection formatWhat a knowledge collection is on disk — the contract between whatever builds an index and whatever answers from it.
• ReferenceThe monitoring protocolWhat an agent tells the board, and what the board may tell an agent.

The subject guides#

One per subject, written by the people who built the platform and rendered here the same way. They go deeper than the tutorials and assume you have done one.

• GuideWriting a flowThe language from the inside: channels, nodes, edges and what the compiler refuses.
• GuideBringing the three upWhat to start, in what order, and the two traps that cost an evening.
• GuideDeploymentWhat the Studio writes, what it vendors, and how the folder becomes an image.
• GuideRunning agentsStarting, stopping, and what a running agent is doing when nobody is asking it anything.
• GuideMonitoringWhat the board knows, how it learns it, and what it will not store.
• GuideWhat a run showsReading a run: the tree, the journal, and the four questions kept apart.
• GuideTriggersA schedule, an event or a webhook — what starts an agent when nobody is talking to it.
• GuideSubflowsOne flow running another as a single step.
• GuideMulti-agentAgents that call other agents, and what that costs.
• GuideHuman in the loopThe points where an agent waits for a person, and who that person is.
• GuideTestingScenarios over a flow, and what a test can and cannot tell you.
• GuideEvaluatingScored evaluations with a judge, and reading the score honestly.
• GuideWorked examplesThe example flows in the repository, and what each one demonstrates.

What this documentation does not yet cover#

Stating it here rather than letting a reader find out at step nine.

• Five screens are shown; the rest are described. Every picture on this site was captured from running software — a Studio, a Control Panel and two deployed agents started for the purpose, on ports of their own. Nothing here is a drawing of the product, and no screen is illustrated with a picture of a different screen. Screens with no picture are named in words instead.
• Some of the Control Panel's procedures have been walked, and some have not. Registering an MCP server, narrowing an agent to two of its four tools, putting an agent on the board by hand, and reading a run and its journal were performed against a live board and each step confirmed. Pausing an agent, restarting one, and answering an approval from the board were not: they are written from the product's own documentation and named as its screens name them. The pages that depend on the second group say so where it matters. Beta
• Triggers, subflows, multi-agent, human-in-the-loop, knowledge collections, databases and evaluation have a rendered guide each and no step-by-step tutorial. Planned
• The SQL Connection Manager and the Collection Server are covered as far as installing them and pointing an agent at them. Their own screens have no page here. Planned
• The Solution Library — packaging, the four gates, and installing somebody else's solution — has its specification on this site and no tutorial. Planned
• Upgrading between platform versions is not covered: what moving an existing deployment from one version to the next involves, beyond redeploying it. Planned
• Hebrew and the other languages. The pages are built to carry translations and none exist yet; this edition is English. Planned
• Versions. This is edition one, so there is no version switcher — there is nothing yet to switch between. Every page's footer states the build it was written against.

Each of these is set out in full, with what was verified and how, in this site's verification report — verification.md in the documentation project.