engineering intelligence

If you can describe it, you can own it.

We built the runtime so that putting AI to work stops being an engineering project. Say what you want in your own words; the runtime works out the pieces, writes them, and runs them.

What you said, and what the runtime reached forA sentence in plain language, and the capabilities the runtime reached for to answer it: apps you author, workflows that run, tools you create, context it remembers, work on a schedule, something served at an address, and models running on your own machine. This request needed an app, the material it reads, and a time; the rest went unused.what you saidsummarise the support inbox each morningwhat the runtime reached foran appa workflowa toolcontexta schedulean addressa local modelyou named none of these
Why we built it

The hard part was never the intelligence.

Models got good faster than anyone could use them. To put one to work you still had to assemble a queue, a serving layer, an orchestrator, retries, secrets and somewhere to watch it — and then keep all of it alive. That is a team's worth of work standing between an idea and the thing that does it, and it is the reason most good ideas stop at the idea. We built the runtime to remove that middle, so the distance from describing a problem to owning its solution is one sentence.

Adoptionisthebottleneck.Everythinghereisbuilttowidenit.

What sets it apart

You describe a problem. You get the thing that solves it.

Not a prompt to keep tending, not a diagram to wire up — a real app, set up and started for you. Automate a chore, orchestrate the kind of workflow that used to need a team, or open one capability to your customers. There is nothing to provision and no cluster to keep warm: it is one program on your own machine, and it grows into the org without becoming a different thing.

Everything it makes, it also runs.
What you said, what it did, and what you haveThree columns. What you said: summarise the support inbox each morning. What it did: split the work, staffed each step, set it up, built it, and put it on a nine o'clock schedule. What you have: an app you own, running at nine, that you can hand to someone else.what you saidwhat it didwhat you havesummarise thesupport inboxeach morning✓ split the work✓ one agent each✓ set it up✓ built it✓ put it on 9aman app you ownruns at 9amyou can hand overyou did the first column
One app, its agents, and the single gate every call crossesOne app with three agents chained inside it. A schedule or a webhook can start it without you. Four arms leave it — a tool, an MCP server, a script, and your documents — and every one of them crosses a single gate. The arm that writes waits for your approval before it completes. When the run finishes it leaves a record, not a process.wakes ita schedulea webhookyour appagents, chaineda toolan MCP servera scriptyour documentsasks you firstone gate, every callwhen it's done it leaves a record, not a process
Every app is an agent

An app is an agent you can name.

Inside one, agents chain — in sequence, in parallel, or under a supervisor that plans and integrates. It decides for itself when to search, when to call a tool, and when to change plan, and a webhook or a schedule can wake it without you. It reaches the tools and services you already use, runs real code, and reads the material you gave it — every one of those through a single gate, under rules you set. Anything irreversible waits for your yes. When the work is done it leaves a record, not a process.

The gate is a property of the runtime, not a setting you remember to switch on.
Where we are

v0.1.0, in the open, and honest about it.

The runtime runs as a managed service — describe a task and it plans, acts, and returns a durable record. It runs end to end on a laptop and is single-system by default.

We would rather you found the limits here than in your own week. The page below is the one we keep current, and it is the first thing to read if you are deciding whether to build on this.