The AI assistant in Voldeno Studio builds logic from a description, writes missing blocks and proves them in a 1:1 simulation. Why AI-native architecture has to start at the bottom.
# An AI assistant for the smart home: simple to deliver, unlimited in what it can do
You hold the key by the door for two seconds. Every roller shutter comes down, every light goes off, heating switches to away mode, the alarm arms itself, and the gate opens as you walk to the car and closes behind you. Five systems from different manufacturers, one press, no extra app.
That is what a professional smart home looks like, and it is exactly why so few houses have one. Somebody has to design that behaviour, express it as logic and keep it alive for years. At Voldeno that work is taken over by the AI assistant built into Voldeno Studio, which leaves the installer doing what they are actually good at: the electrical installation.
# The trade-off we refuse to accept
Building automation has been asking the same question for years. Do you want a system that is easy to live with, or one that can really do anything? Consumer products pick simplicity and stop at scenes that cannot be extended. Professional systems pick capability and pay for it with an entry barrier a regular electrician will not clear.
Simple. Unlimited. is our answer to that question, and it was a constraint we accepted before the first module existed. The system has to be simple to deliver and unlimited in how it can be configured. Not "simple enough", and not "flexible if you are a specialist".
Professional systems left three problems unsolved:
- A house that depends on one installer. A professional system has to be programmed, not just wired: control logic, device protocols, integrations between separate systems. A regular electrician cannot deliver that, so every project waits for one of the few who can. And only that one person knows how the house works afterwards.
- One central unit deciding everything. In a typical professional system a single server sits in the switchboard, running every algorithm and driving every relay. An AI assistant does not help here, because this is a hardware architecture problem. We answer it with logic distributed across the modules, which we are building in parallel.
- New devices do not fit. Heat pumps, inverters, chargers and IoT hardware arrive faster than system vendors integrate them. The installer drops the feature, or spends days on an integration only a specialist can finish.
The first and the third are software problems. That is where the assistant works.
# What the assistant does
# It builds the whole logic from a description
You write a plain sentence describing the behaviour you want. The assistant reads the project stored in the installation, picks the logic blocks, connects their inputs and outputs, binds them to module registers, and then lists every single operation before anything touches the canvas.
What matters most is what the installer no longer needs to know. There are hundreds of logic blocks, new ones land every few weeks, and nobody knows them all by heart. The assistant does, because it reads their definitions and documentation on every request. The entry barrier for a new installer drops from "learn the library and the language" to "describe what the client asked for".
In the example above, a single instruction about bathroom ventilation grew the group from three blocks to seven: a numeric input from the outdoor humidity sensor, a subtraction block computing the difference, a hysteresis block for the "it is drier outside" condition, and an AND block tying that to the existing humidity threshold.
# It writes a missing block and proves it in simulation
No library will ever cover every device on the market. When a block is missing, the assistant writes one in Volang, over HTTP, TCP, UDP or Modbus, and immediately runs it in simulation to check that it behaves the way the description said it should.
This is usually where conversations about AI-written code end, because nobody wants to vouch for a generated script. Here the virtual machine vouches for it: VolangVM runs in Studio, in the digital twin and on every module. A block that passes its test in simulation behaves identically on a module in the switchboard, because it is not an approximation of the runtime, it is the same runtime.
A block written this way is an ordinary block. It goes into the library, gets placed and wired like any other, and it is reusable in the next project.
# It answers "why is this running right now"
The hardest question in any mature installation is why a given device is on. The answer is rarely a single cause. It is a temperature, a humidity reading, a schedule, an operation mode and a block somebody configured two years ago.
Instead of clicking through the whole graph, you ask. The assistant walks the dependencies backwards from the output to their sources, highlights the blocks that influence it on the canvas, and describes the situation in words. Asked about heating, it points to the per-zone climate_regulator blocks, the arbitration in climate_regulator_hub and the binary_limiter guarding every floor circuit. Along the way it flags anything configured but never connected.
Sometimes the answer is simply that nothing is broken. The fan is idle because humidity never reached the switch-on threshold, and the assistant shows that with the actual readings and settings instead of leaving you to guess.
# It rebuilds existing logic and edits schedules
Houses change. A child arrives, a room is added, the rhythm of the week shifts, a battery appears next to the inverter. The assistant does not only work on an empty canvas: it reads the existing graph, adapts it to the new requirement and edits schedules, leaving manually tuned values alone.
# It does not invent answers, because it reads the docs and the block source
The assistant works from the Voldeno documentation and from the source code of the logic blocks. The blocks we ship run on exactly the same mechanism as blocks written by users, and their source is available, so analysing any piece of logic in an installation is the same operation for the assistant as analysing what it wrote itself. Simulation closes the loop: instead of arguing that something will work, it shows the result.
The assistant is a configuration tool. Once deployed, the logic runs locally on the modules, and pressing a wall switch involves neither AI nor any cloud service. The installation works without internet.
# Why this has to be in the architecture
You cannot bolt an AI assistant onto an existing automation system and expect the same result. Three things have to be true at once, and each one is an architectural decision taken years earlier.
Our own language, because nothing else would fit on a module. No existing language was simultaneously small enough for the microcontrollers in our modules, isolated enough that one faulty script cannot stop the rest, and identical on a laptop and on the hardware. So we built the language, its compiler and its virtual machine.
Nobody has to learn it. Installers work with visual blocks and the assistant writes the code. Volang is the engine underneath, and it is what gives us full control over what actually executes on a module.
One engine everywhere. The same virtual machine runs in Studio, in the digital twin and on every module. Only that makes it defensible to let AI write control logic for a real building. Every Volang script runs in a sandbox with no reach outside its own space, so code generated by the assistant or written by a user has no way to hang a module, brick hardware or stop the bus. A faulty script stops only itself.
Competitors let a specialist write a script, or run a simulation. Nobody runs one engine both on a laptop and on every module in the switchboard. Catching up means re-architecting the whole software stack and replacing controllers already installed in people's homes.
# Why now
Three things changed at the same time.
First, AI can write working code. Our language runs every script in a sandbox, so allowing it is a safe decision rather than a leap of faith.
Second, homes are filling up with energy hardware. Poland alone has more than 1.63 million PV micro-installations (PTPiREE, January 2026), new PV subsidies require storage, and hourly spot prices only pay off if a system shifts loads in time. These are precisely the integrations vendor libraries cannot keep up with.
Third, systems have grown complex enough to need AI, and they were not built for it. Bolting an assistant onto a closed configuration achieves little, because there is no logic source to read and nowhere safe to run generated code.
# What changes for the installer
An installer earns from the number of jobs completed, not the number of hours spent on configuration. Cutting programming from days to hours therefore moves revenue directly, not just comfort.
Support calls change character too. "Add control for the new gate" today means a site visit, remembering how this house was built, and carefully poking at somebody else's logic. With the assistant it starts with a question about how the installation works, the change is listed point by point before approval, and it is checked in simulation before deployment. Faster, simpler and safer than hand-editing a graph nobody has looked at in two years.
There is one more thing that matters to an installation company: a new hire becomes productive in days rather than after months of training.
# What changes for the homeowner
The complete project lives in the installation, not in the head of the person who created it. You can ask the house how it works and get an answer naming modules, blocks and schedules.
Two practical consequences follow. Small changes, such as different irrigation hours, a new scene or a temperature setpoint in the child's room, are something you do yourself without waiting for a visit. And for bigger work you can call any installer, because they need nothing from the previous one. That is a real guarantee of independence, not a clause in a service contract.
# Simple. Unlimited.
An AI assistant for the smart home only makes sense when the rest of the system is built for it: your own language, a virtual machine that behaves identically on a laptop and on a module, a sandbox that contains the consequences of mistakes, and a simulation that gives the AI a genuine feedback loop. We have all four because we wrote the stack from scratch with this moment in mind. That is why we do not have to choose between simplicity and capability, and why we think nobody buying an automation system today should be forced to make that choice either.