Hello, world: how DomeCommand started

Problem

A cheap drone now forces a response that can cost a thousand times more. Send a hundred at once and the hard part is no longer the hardware. It is the decision: what to send, at what, and when, faster than a person can make it.

And the person making that call is already overloaded. Sensors pour feeds at the operator, but the data points that actually decide the outcome, a clean track, a confident classification, stay scarce. Too much signal, not enough of it good.

What holds the decision together in production today is, honestly, thousands of hardcoded rules. That is what a lot of "decision support" really amounts to: hand-written logic, brittle at the edges, and almost impossible to keep current with how fast the threat is changing.

So the problem is three things at once. A decision that has to be made faster than a human can make it. An operator drowning in feeds but starved of good data. And a status quo held up by rules nobody can maintain. DomeCommand is being built to take all three on. This blog is the log, in the open, from the start.

How it started

Years ago at Yojee I worked on route optimization, assigning vehicles to jobs under messy real-world constraints. Later I dabbled a little with programming my own flight controller using a Crazyflie. And for a while now I have been building Distri, an open-source agentic harness.

Applying a solver brain on top of an agentic brain sounded like a great fit for a counter-UAS proposition. So I built a demo.

The first demo

The first demo was a Space Invaders style planning screen, built on Distri and focused on C-UAS: waves of drones come down the screen at Singapore, and the screen models the cost of defending against them.

It runs two things at once. A solver continuously re-allocates the effectors you have against the threats that are inbound, under the constraints and the cost of each intercept. An agent reasons around the solver as the picture changes, deciding what to ask it next and what to recommend. Traditional planning algorithms and an agentic brain might be a good mix. This was the cheapest way to find out.

▶ Watch the demo

The solver does the maths. The agent does the small amount of reasoning around it, and that small amount is what changes the answer.

DomeCommand has since been invited to submit a proposal for a three-month project at the Singapore Defence Tech Hackathon.

After a number of conversations with defence consultants, military experts, and people who have spent years close to this, the idea has evolved and deepened a lot. The backdrop is hard to miss too: drones changed the fight in Ukraine, they are cheap and numerous and hard to stop, and the hardware is years ahead of the software that has to command a response to it.

Autonomous continuous planning, and decision support

What we aim to build is an autonomous decision support system that really aids an operator: one that can move the sensors to where they are needed, a fleet that auto adjusts, and an agentic brain aiding the traditional AI and ML approaches.

Rules are still in there. They are necessary. They just cannot all be hardcoded, because the threat moves faster than anyone can maintain them. We wrote our own DSL for how policy and instructions are expressed, and I will cover it in a later post.

Three bets follow from this.

01 · Dynamic aerial sensor fusion

Radar, RF, EO/IR and acoustic each see a different slice of the world, and they have to agree on one track. Most systems treat the sensors as fixed points on a map. Ours does not. When identity is uncertain, the system sends a flying sensor to go earn a better look. Fusion stops being passive.

Many sensors, one track. The harder version: some of those sensors are flying.

The deep diveDynamic sensor fusion: what if your sensors could move?Cross-cueing, slew to cue, and a picture that is honest about what it does not know.→

02 · Dynamic, multi-purpose drone swarm

One fleet you can task on demand. It defends, and it also watches, patrols, and scouts. Drones self-organize, reassign themselves mid-flight, and keep flying as links drop. Defence is the hard edge that forces the system to be fast and trustworthy. The everyday jobs are what make a fleet worth owning.

One fleet, many jobs: defend, watch, patrol.

The deep diveFour loops, two links: the architecture that keeps flyingHow the swarm holds together when GPS, the uplink, and the mesh each get taken away.→

03 · Agentic and solver decision brains

The solver carries the math, allocating assets under hard constraints of cost, coverage, and reach. The agent reasons around it: what changed, what matters now, what to re-solve, and briefs the trade-offs in plain language. Two kinds of intelligence in one loop, and a human approves the call.

Sense, plan, decide, act, assess. The operator sits in the middle of it.

The deep diveThe simulation engineWhere the two brains are exercised: scenarios generated across fleet and threat catalogs, and the history used to train them.→

Where this goes

That is where DomeCommand starts. A solver, an agentic harness, a hackathon proposal, and a problem that turned out to be very real.

Read moreInturai has signed an LOI to acquire DomeCommandAnd where all of it landed: sensing through walls, paired with a fleet that can act on it.→

I am building it in the open, and writing up each piece as it comes together. If this is your kind of problem, follow along. Hello, world.