How a fix runs, from first signal to the log.
Every run follows the same six steps. What changes between jobs is the shape: who reads, who decides and who signs off.
- NoticeSomething in your systems repeats: a ticket, an alert, a late load.
- ReadUpshot reads the history your team would read, across every connected system.
- ProposeIt finds the cause and drafts the work: replies, orders, reports.
- AskThe owner sees one proposal with its evidence and approves, edits or rejects it.
- ActIt does the approved work inside your tools, through their own APIs.
- RecordWhat it read and decided, who approved it and what it cost, kept per run.
Pick a job and watch it run.
Switch jobs and watch the shape change: who reads, who decides and who signs off.
The run log is the product you keep.
Every step lands here, with the evidence beside it. Your team can check any action after the fact, and so can an auditor.
Measured on every run.
Figures from five pilot customers. You see your own from the first week.
of proposed fixes approved without edits
median time from a trigger to a proposed fix
median model and tool spend on a run
Evals you can read.
Each workflow is scored against the outcomes your team records, and the score sits next to the runs.
Questions about the engine.
How is a workflow defined?
As a short list of steps and the systems each one may touch. The diagrams on this page are drawn straight from those definitions.
What stops it doing something it should not?
Each action is switched on separately, starts as Ask, and can have a spend limit. Anything over the line waits for a named person.
Can we see why it decided something?
Yes. The run log keeps the evidence and the reasoning for each step in plain sentences.
Start with a free pilot.
One workflow, read-only for the first three weeks, run by a founder from start to finish.