Build with AI

From one prompt to three supply variants, in under ten minutes.

Sympheny's REST API and Python SDK are fully documented, so an AI assistant or coding agent can build a project, set up scenario variants and start an optimisation run. What comes out the other side is unchanged: the same deterministic MILP engine solves the model, whether a person or an agent assembled it.

An assistant sets the model up. Sympheny solves it.

40-second walkthrough

One prompt, three supply variants — gas boiler, heat pump with rooftop solar, and district heating — set up through the documented API. Silent clip; every step is captioned on screen.

Get the details and the full setup guide in our documentation →
What the walkthrough shows

Five steps, from a written brief to three scenarios ready to optimise.

The clip runs through a real setup: a brief written in plain language, the script the assistant produces from it, the assumptions it flags back before running, and the three scenarios that come out the other side.

  1. Ask

    Describe the study in plain language

    The brief asks for a project with three supply variants — a gas boiler, a heat pump with rooftop solar, and district heating — covering heating, cooling and electricity demand for a 1,500 m² residential building over five floors, drawn from the Sympheny database. The assistant works from the published API specification, so it knows what a project, an analysis, a scenario and a hub are before it starts.

  2. It writes the script

    The assistant produces the setup script

    It writes Python against the Sympheny SDK, one branch per variant, instead of clicking through the interface. The script is yours to read, version and re-run — which matters more than the time it saves, because a colleague can see exactly what was built and on what basis.

  3. Check the assumptions

    It tells you what it had to decide

    Before running, the assistant flags the two judgement calls the brief did not settle: which demand year to take from the database, and where the cooling comes from. This is what makes the workflow usable on real projects — the ambiguities surface as questions rather than as silent defaults buried in a model.

  4. One analysis, three scenarios

    Three variants on one shared basis

    The three scenarios land in a single analysis, each with its own inputs, technologies and outputs, all sharing the same demand profile and assumptions. That shared basis is what makes the comparison defensible when a client or a committee asks why one variant won.

  5. What happens next

    Sympheny optimises them

    From there the workflow is the ordinary one. Sympheny runs the MILP optimisation across the technology and capacity combinations for each variant and returns the optimal configurations, with the trade-offs on a Pareto front. The assistant set the model up. It never solved it.

Light App Editor

“Add a new step after step 1 that lists every project…” — and the wizard has one.

AI helps you build the interface. Sympheny optimises deterministically, as always.

A light app is a small, focused interface built on top of Sympheny — a wizard shaped like the study your team actually runs, rather than the whole platform. You build one, and change it, in the Light App Editor.

The clip shows one being changed. A written instruction adds a step to a deployed four-step wizard, the steps below it renumber, and the new screen is live two seconds later. The added step is not a mock: it calls GET /projects against the Sympheny backend and renders what comes back — owner, status, last update — for every project in the account.

Light App Editor · 40 seconds

A deployed four-step wizard gains a fifth from one written instruction, deployed in two seconds and loading live from the Sympheny backend. Silent clip; every step is captioned on screen. It shows an existing app being extended, not one built from empty.

Talk to us about using AI for your own light app →
Three ways in

Everything an agent needs is already documented.

Two of the three are live today: the REST API and the Python SDK are fully documented and drivable now. The MCP server, which lets an assistant connect with no wiring on your side, arrives in the coming weeks.

Available now

REST API

Every endpoint is publicly documented, with JWT authentication, request and response schemas and a browser-based API Explorer. Projects, analyses, scenarios, stages, hubs, technologies and solver jobs are all reachable.

REST API reference →
Available now

Python SDK

sympheny-toolbox, the official client, needs Python 3.11 or newer and installs with pip. It exposes every documented endpoint as a typed method with Pydantic validation, offers matching sync and async clients, and handles login, token caching and refresh for you. Worked guides cover running a solver job and downloading results.

Python SDK guide →
Coming in weeks

MCP server

A remote Model Context Protocol server, so an assistant can call Sympheny over a standard connection instead of hand-written HTTP. Client setup for Claude Code, Claude Desktop, ChatGPT and Gemini CLI is documented ahead of launch, and the endpoint starts answering when the server ships in the coming weeks. Until then the REST API and the SDK do the same job — that is what the walkthrough above uses.

MCP setup, documented ahead of launch →
Agent-legible by design

The documentation is written to be read by machines as well as people.

docs.sympheny.com publishes llms.txt, a compact index of the documentation in navigation order with a one-line description per page, and llms-full.txt, the whole set concatenated in reading order. Both follow the llms.txt convention.

The practical effect is that you can hand an assistant a single URL and it has the platform in context — endpoints, schemas, model structure and worked examples — instead of crawling the site or guessing at the shape of an API.

llms.txtllms-full.txtDocumented schemasTyped SDK methods
What this does not change

The optimisation is deterministic, with or without an assistant.

Connecting an assistant changes how a model is built. It does not touch how the model is solved.

No AI in the calculation

Every result comes from the Mixed-Integer Linear Programming engine, and traces back to the constraints, cost parameters and energy balances that produced it. The same inputs always produce the same outputs.

Off by default

Sympheny ships no embedded assistant and connects nothing on your behalf. You decide whether to connect one, and which provider to use.

Your provider, your agreement

The scenario data an assistant sends and receives passes through the provider you chose, under your agreement with them, not ours. Sympheny embeds no third-party model in its own computation pipeline.

Nothing is trained on your data

No customer energy profiles, building data or project inputs are used to train any model, ours or a third party's.

Read the full AI & data transparency page →
Where teams use it

The parts of the work worth automating.

Scenario variants at volume

Set up ten variants of the same study from one specification, instead of building each one by hand and hoping the assumptions stayed aligned.

Sensitivity sweeps

Re-run a scenario across a range of tariffs, technology costs or demand assumptions, and collect the results in one place.

Setup from an existing spec

Turn a client brief, a spreadsheet of site data or an existing model description into a Sympheny project without retyping it.

Repeatable pipelines

Drive Sympheny from a notebook or an internal tool, so a study your team runs every month runs the same way every month.

Questions

Working with AI assistants and agents.

Can I use Sympheny with an AI assistant or agent?

Yes. Sympheny publishes a REST API and a Python SDK, both fully documented, so an assistant or coding agent can create scenarios, start optimisation runs and read results back. An MCP server arrives in the coming weeks. Setup is documented at docs.sympheny.com. Nothing is connected by default — you decide whether to use it.

Can I edit a light app with an AI assistant?

Yes. The Light App Editor takes a plain-language instruction and changes the app — the clip above adds a wizard step listing every project in the account, backed by a real API call and deployed in two seconds. What it shows is a change to an app that already exists; building one from empty is a longer job. Either way the optimisation behind it is unchanged: the same deterministic MILP engine solves the model.

If I connect an assistant, where does my data go?

To whichever provider you connect. If you point an assistant at Sympheny, the scenario data it sends and receives passes through that provider under your agreement with them, not ours. Sympheny does not choose the provider for you and embeds no third-party model in its own computation pipeline.

Does connecting an assistant change my results?

No. An assistant can build or modify a scenario, but the optimisation always runs on the same deterministic MILP engine. A scenario assembled by an assistant and the identical scenario assembled by hand produce the same results.

Note: An assistant can set the model up. It never solves it.

Do I need to be a developer to use this?

For the API and the SDK, yes — or you need someone on the team who is. Having the assistant write the script lowers the bar considerably, but somebody still has to run it and read what it did. The MCP server is what removes that step, and it arrives in the coming weeks. Until then this is a workflow for teams with some scripting capability; everyone else works in the web app, where the same optimisation runs.

Is under ten minutes realistic?

For the setup shown, yes: a three-variant project with demand drawn from the database, with the API specification available to the assistant and someone who knows what they want to model. A first attempt takes longer, and the optimisation run is on top of it. It is a claim about scenario setup, not about producing a finished energy concept.

When does the MCP server launch?

In the coming weeks. Client setup for Claude Code, Claude Desktop, ChatGPT and Gemini CLI is already documented, and the endpoint starts answering when the server ships. Everything the walkthrough above shows works today without it, through the REST API and the SDK. If you want to be told when MCP lands, mention it on a demo call or write to us.

Want to try it on a project of your own?

Start a free trial and drive it through the API, or book a demo and we will walk through the setup on a project that mirrors yours.

Book a demo