Why we built Arcflux: governed AI for the physical world

A truck's engine-temperature sensor crosses a threshold. A CNC machine reports a spindle fault. A warehouse robot stops mid-route. Each of these is an event worth acting on — and each one arrives over a protocol that most automation platforms cannot hear.

That gap is why we built Arcflux.

The gap

The current generation of workflow builders is genuinely good at one shape of problem: a webhook fires, a few steps run, something gets written back. That covers a lot of software-to-software automation. But it stops at the edge of the network. The moment the trigger is a sensor, a vehicle, or a machine on a plant floor, you are on your own — standing up a bridge service to subscribe to the broker, normalize the payload, and re-emit it as an HTTP call the builder can accept.

So you write the bridge. Then you operate it: keepalives, reconnects, QoS, back-pressure, an on-call rotation for the day a broker drops and runs silently stall. None of that is the workflow you actually wanted to build. It is plumbing — and it is the reason "connect the AI to the machine" so often dies in a proof of concept.

The wedge

Arcflux speaks the protocols the physical world already runs on. You point a workflow at a broker topic — MQTT, NATS, or AMQP — with wildcards and QoS, the same way you'd add a webhook. No bridge, no glue service to babysit. Every connector reports broker liveness over keepalive, so a dropped device shows up as a health signal instead of a workflow that quietly went dark.

That is the one axis no workflow-builder competitor ingests natively, and it is deliberately the front door of the product rather than a footnote.

Why governance comes first

Connecting to a firehose of device events creates an obvious new problem: cost and noise. A chatty sensor can emit thousands of messages an hour. If every one of those spun up a multi-step AI run, your bill — and your signal-to-noise — would be wrecked in an afternoon.

So governance is not a feature bolted on the side; it sits between the source and the run. Before a single credit is spent, every event passes a policy gate:

• Dedupe — collapse repeats inside a window.
• Cooldown — enforce a minimum interval between runs.
• Throttle — cap the rate.
• Condition — run only when an expression over the payload says so.
• Safety — always-on payload and platform guards.

Events that don't pass are dropped before they cost anything. And because every policy can run in shadow mode first — recording what it would have done without actually blocking — you can tune the gate against real traffic before you let it enforce.

The same gate applies to every source. An MQTT event is governed exactly like a webhook. There is no second-class trigger.

Humans stay in the loop

Speaking to machines also means workflows can act on machines — dispatch a work order, file an incident, actuate something. That is precisely where you want a person. Arcflux workflows pause at approval gates: a run holds, a human sees the full context, and nothing proceeds until someone clicks Approve. Every run is auditable step by step, so "what did the agent do, and why" is never a mystery.

What you build on

Underneath, a workflow is a graph you draw on a canvas in Studio — triggers, agents, tools, branches, and human approvals as nodes, no orchestration code. Switch the model per step without rewriting the flow. Bring any MCP server or native integration; tools are scoped per workflow. Trigger the same workflow from many sources at once — a webhook, a schedule, a chat message, the API, or a live device stream.

Where we are

Arcflux is in alpha. The protocols above are live today; CoAP and MAVLink are on the roadmap. If your events come from the physical world and you want to put a governed agent in front of them, join the waitlist — members get access first.

We think the interesting automation of the next few years doesn't live entirely in the cloud. It starts at a sensor. We built Arcflux to meet it there.