CONTEXT
Workflōz is for business teams whose processes run on copy, paste and reminders: a lead comes in, someone scores it, a manager approves, a row lands in a spreadsheet and a message goes to the team. The people who own those processes are rarely the people who could automate them.
THE PROBLEM
Most automation tools make you build the flow node by node. AI builders flip that, but they tend to produce flows that look right and break on the first real run. And business processes wait on people, which is exactly where fragile automation falls apart.
Plausible but broken
A model can sketch a convincing workflow that points at an app connection you don't have, passes the wrong data between steps or leaves a branch disconnected.
People are slow
An approval can sit for hours or days. If the server restarts in that time, a fragile engine loses the run or starts it again from the top.
Two clicks, one decision
When two people act on the same paused run at once, a naive system can record both, sending the lead to the spreadsheet twice or approving and rejecting it in the same moment.
HOW WE SOLVED IT
- 01
The copilot's work is checked by code, not by more AI
The copilot writes a one-line plan, then builds the workflow from the real catalog of available steps. Before you see it, the result is checked in code: every step must exist, every setting must match that step's schema, connections must be the right type, every link must join real inputs and outputs, and there must be exactly one trigger. Any problems go back to the model to fix, and whatever remains is shown to you as a warning instead of being hidden.
- 02
Every run is saved after every step
A run is a plain, serializable record that's saved after each step, so a restart picks it up exactly where it stopped. A step can pause to wait for a person while other branches keep going, with deadlines that route to a timeout path and reminders until someone decides.
- 03
One change to a run at a time
Every change to a run is a queued job with a key, and jobs that share a key never run at the same time. Workers claim jobs from Postgres with row locks and time-limited leases, duplicate jobs are merged, and failures retry with backoff before landing in a dead-letter queue you can inspect. Approval links only act when submitted, so an email scanner opening the link can't approve anything.
- 04
Everything on the record, including cost
Each step stores what went in, what came out, and for AI steps the tokens and cost. Publishing creates an immutable version, and dev, staging and production each point at a version, so promoting or rolling back is a pointer move rather than a redeploy.
WHAT WE CHOSE NOT TO DO
- No separate queue service. The job queue lives in Postgres, which already holds the runs, so there's one less system to operate and keep consistent.
- No vendor lock-in for AI. Every model call goes through one router, so Claude, OpenAI, Gemini or a local model can sit behind the same steps.
- No silent shortcuts. Unauthenticated webhooks must be chosen explicitly, pinned test data never touches production runs, and shared templates strip credentials.
WHERE IT STANDS
Built-in steps cover Slack, Gmail, Google Sheets, Outlook, HubSpot, Stripe, Postgres, email and HTTP, plus AI steps for generating, classifying, guardrails and knowledge search. Connectors for other services can be imported from an API spec, and owner-only production deploys are audited with the version they replaced.
- TYPESCRIPT
- REACT
- REACT FLOW
- FASTIFY
- POSTGRES
- PGVECTOR
- QUICKJS
- CLAUDE