xAutonomics lets anyone create a tailor-made autonomous optimization system for resource and energy conservation — built from readily available components: off-the-shelf smart devices, existing industrial equipment, and a small local computer.
The concept generalizes a pattern proven in autonomous laboratory research: a closed loop in which an AI proposes a change, the system executes it, sensors measure the result, the AI learns from it, and the cycle repeats — converging on optimal operation without human trial-and-error. Carnegie Mellon's "Clio + Dragonfly" work used exactly this loop to discover new battery electrolytes in days instead of years.
xAutonomics brings the same pattern to everyday systems: irrigation, HVAC, industrial processes. The mechanism is the pitch — no magic, just a loop that never gets bored, never guesses, and never stops measuring.
A backyard irrigation system built from an app-controlled sprinkler controller and an unrelated wireless soil-moisture sensor. The xAutonomics Runtime sits on a small local computer and autonomously learns the watering schedule and durations that minimize water use while keeping soil moisture in the acceptable range — treating two consumer devices as one coherent system, even though they were never designed to work together.
Autonomica Studio is the design-time environment — a web and desktop application where you define the system you want to optimize, guided by an AI agent named Mica. You describe devices, objectives, and limits; the Studio turns that into a formal, inspectable definition. Its output is not a report. It is a generated, containerized Runtime.
The Runtime is a self-contained container deployed to your own local compute — a mini PC, an industrial gateway. It runs the optimization loop autonomously and includes everything needed to talk to your devices: the optimization engine, the device interfaces, and the monitoring and safety layer. No cloud dependency in the control path; connectivity is an enhancement, not a structural requirement.
Mica is the AI agent inside the Studio. Instead of forcing you to fill out engineering forms, Mica conducts a structured interview — the questions a good controls engineer would ask:
What do you want to optimize? What outcome do you want? What does "acceptable" mean for you?
What devices are involved? Is each controlled by a phone app, a web dashboard, or RS-485/Modbus? What are its inputs and outputs?
What hard limits must never be crossed? What ranges are acceptable? When must the system never act?
From the interview, the Studio produces a formal optimization problem definition — variables, objectives, constraints, device mappings — which you inspect and edit visually before any Runtime is generated. What you approve is exactly what gets built.
The Runtime integrates devices without requiring APIs or vendor cooperation — three pathways cover nearly everything that can be sensed or switched:
This is what makes "readily available components" real: the phone app or web dashboard the device already ships with becomes its control interface.
The platform runs on a mixture of open-weight language models, each assigned the role it performs best: reasoning, code generation, vision and UI understanding, document extraction. Every AI-generated artifact then follows established software development process — nothing ships on trust.
The differentiating stage is Lean-based auto-formalization: the optimization problem definition and the control code built around the Bayesian optimization core are formally verified. The constraints and safety bounds you set in the Studio are translated into formal statements, and the generated logic is checked against them — mathematically, not by review.
Around it sit the industry-standard stages: static analysis, unit and integration testing, and simulation replay against recorded device behavior. Every generated Runtime passes the same quality bar, regardless of what devices and objectives it was built for.
A deployed Runtime does not immediately start changing things. It follows a staged, trust-building lifecycle:
Exploration and enforcement are separate layers. The Bayesian optimization core is honest about what it knows: a model with explicit uncertainty, which narrows around every measured sample. Where uncertainty hides potential value, it proposes the next experiment.
But no proposal — however promising — can leave the envelope you defined. Hard limits, watchdog timers, and failsafe behaviors are enforced at the execution layer, independent of the optimizer, and stay active even when devices become unreachable or behave unexpectedly. The optimizer proposes; the enforcement layer disposes.
Wherever a system runs on settings someone chose once and never revisited. Thermostat schedules set years ago. Irrigation timers set by the installer. Compressor pressures set "to be safe." Charge windows that ignore today's tariff.
Every one of those is a standing invitation for an optimizer that never gets bored, never guesses, and never stops measuring. Below: what an xAutonomics deployment looks like in practice. Each one is the same platform — a Studio conversation with Mica, an approved problem definition, one generated Runtime — pointed at a different system.
Your home already makes half a dozen energy decisions per hour: when to charge the battery, when to sell back, when to run the heat pump, when the EV should draw. Each device optimizes selfishly, or not at all. Meanwhile the economics have inverted: with collapsed feed-in tariffs, self-consumed solar is now worth several times what exported solar earns — yet most systems still run the inverter's factory mode.
The Runtime fuses them: tariff data, the inverter, the heat pump's app, the charger's Modbus meter — one objective, minimum cost of comfort. It learns the house itself — thermal inertia, real morning demand, how your panels actually perform under your sky — and schedules energy flows against tomorrow's prices. Not a rule engine; a model of your house.
The honest numbers: field-credible studies put whole-home optimization around 16% cost / 22% energy savings — and co-optimization is exactly where that comes from: optimizing HVAC alone yielded 8% in the same study that reached 16% when battery, PV, and shading were folded into one loop. Battery-plus-tariff arbitrage alone is worth on the order of £700–950 a year on a 10 kWh pack under a dynamic tariff.
A clock timer keeps watering through a rainstorm, waters a cool cloudy week like a July heatwave, and gives the shaded clay corner the same minutes as the sun-baked sandy knoll. The EPA estimates as much as half of residential outdoor water is wasted this way — and outdoor use is more than 30% of household water, up to 60% in arid regions.
The real control problem is a soil-water balance run forward in time: the root zone is a leaky bucket, filled by irrigation and rain, drained by evapotranspiration. The Runtime waters on evidence — soil-moisture probes, the ET and rain forecast, per-zone soil and planting — and treats new trees, established shrubs, and turf as genuinely different buckets. Because it experiments, slightly earlier here, slightly less there, it discovers what your soil and microclimate actually respond to. "Safe" schedules routinely turn out substantially over-watered.
Measured, not marketed: weather-based control lands around 16% average savings in landscape studies (21–50% across sites in the Irvine ET-controller study), WaterSense-certified control is at least 20% better than a clock, and soil-moisture-guided turf programs run 20–40% — the difference between surviving a mandated drought cutback and losing the greens. Flow and pressure telemetry doubles as the safety layer: a stuck valve or burst lateral triggers shutoff instead of a flooded zone.
A greenhouse is the textbook coupled system: opening a vent dumps heat and humidity and the CO₂ you just injected. Every actuator — vents, screens, heating, lighting, fertigation — moves several variables at once, and the variables fight each other. That coupling is precisely what defeats rule-based climate control, and precisely where co-optimization pays.
The proof point is public: in Wageningen's Autonomous Greenhouse Challenge, AI teams have repeatedly out-yielded and out-profited professional growers while using less energy — one winning entry posted +27.8% net profit, and in recent editions every algorithm team beat the professional reference. Energy is a grower's #1–2 operating cost, with 20–40% documented savings on the table — thermal screens alone are worth 30–75% of heating.
Deployment is an overlay, not a rip-out: the Runtime reads state from and writes setpoints to the climate computer you already run, respecting its interlocks. You set the strategy — crop, targets, limits; the loop runs the tactics, day and night.
For commercial and industrial customers, demand charges are 30–70% of the bill — set not by how much energy you use, but by your single worst 15-minute interval. On many tariffs that spike ratchets: one bad afternoon when the compressor, the CNC, and the AC all kick on together can raise your bill for the next eleven months.
That asymmetry is exactly where anticipatory control beats reactive rules. The Runtime watches the interval meter, forecasts the coincident peak, and schedules flexible loads apart: pre-cool the cold room ahead of the window, stage the compressors, discharge the battery into the peak — while food-safe temperatures and process constraints hold as hard limits, not suggestions.
Documented outcomes: peak-shaving programs cut C&I bills 20–40% with 3–6-year paybacks; supermarket-style refrigeration control shifts 5–12% of load out of peak windows for only ~2% more energy; EV depots save tens of thousands per year on demand management alone. The hardware — interval meter, inverters, rack controllers — is usually already installed. The missing piece is the loop.
A house, a field, a greenhouse, and a machine shop look nothing alike — but they are the same control problem wearing different costumes: a physical process with a few knobs, a stream of sensor readings, an economic objective a human chases by hand, and hard limits that must never be crossed. Sense, forecast, co-optimize, constrain, fail safe.
That's why one platform covers them all: describe your system to Mica, approve your definition, and get a Runtime built for it and nothing else. See how it works →
This section is coming together.
We'll be direct: we take on a small number of projects, reviewed and approved individually — with founder-level attention, real candor about fit, and one goal: a runtime on your site, delivering measurable value on your equipment.