Omnara turns its remote-coding app into an Apache 2.0 control plane for durable agents

Sehgal's July 23 post, "Serverless Agents", sets out the loop the platform runs on ^[5]. Each worker picks up an event, loads the agent's state, moves the task forward a step, writes down what should happen next and then shuts down ^[5]. When a tool result, an approval or a new message arrives, the next worker picks up from there ^[6]. Sehgal argues that an agent should be reconstructible from its durable event history, so no single continuously running process has to hold it ^[7]. The design depends on every input that changes the agent, tool results and approvals included, reaching that history before a worker exits ^[5][7].

In my view this is good engineering for agents whose steps are separated by approvals and tool calls. The public repository implements a version of it. Per the documentation, the platform writes agent state to Postgres, and that state can be restored after a crash, a restart or a machine briefly dropping its connection ^[8]. History and lifecycle information live in the control plane. Connected machines supply the filesystem, operating system, private network or other compute a task needs ^[9]. A machine can be a laptop, a VM, a container or a third-party sandbox ^[3].

That split leaves one seam. Recovery, as documented, covers agent state ^[8]. Files stay on whichever machine is attached ^[9]. I'd expect most of a coding agent's work to land in those files, and RuntimeWire's account does not describe how a working directory follows an agent when a later step resumes on a different machine ^[9].

The usage numbers on record come from the earlier product. Omnara reported that more than 6,000 people had sent over two million messages through it ^[14]. Taken at their floors, the two figures work out to about 333 messages a person ^[1]. RuntimeWire notes the figures are company-reported and were not independently audited ^[15].

That app let developers run coding agents on their own machines and steer them from web and mobile interfaces ^[17]. Sarangmath described developers using agents while walking a dog, commuting or at the gym ^[16]. A dog walk is a different load profile from an internal Slack workflow. The new customer is a team building agents into its own products and workflows ^[18]. For the old traffic to predict anything about the control plane, one developer steering one session from a phone would have to behave like a team's agents running inside a product.

RuntimeWire places the control plane in a market that already has named control-plane and execution-layer alternatives, and calls its adoption the main unanswered measure ^[19].