Describe what you want to happen in ordinary words. ServAI turns that into a validated plan, checks it against the same gates as the rest of the platform, and builds it inside an automation tool you own — your licence, your instance, your credentials, your data.
How it works
- You describe the outcome. "When an invoice arrives, match it to the purchase order and flag anything that doesn't line up." No diagrams, no configuration screens.
- ServAI writes a plan. The request becomes a structured specification — every step, every system it touches, every action that changes something.
- The plan is checked, not trusted. It runs against the same thirteen gates as any other work: authority, blast radius, reversibility, spend, data egress.
- You see it simulated first. A dry run shows what it would do — which records, which recipients, what it would cost — before anything is live.
- A person clears it. Higher-risk automations wait for a named human. Some categories cannot be cleared automatically at all.
- It deploys into your tool and runs there, with a receipt for the build and a receipt for every execution.
You own the estate
This is the part that matters commercially, and we hold the line on it:
- You buy the licence directly from the vendor. ServAI never resells a seat and never marks one up.
- ServAI never hosts or operates your instance. If you have no automation tool yet, we can give you a verified, version-pinned recipe you run on infrastructure you control — a recipe you run, not a service we run for you.
- Credentials go straight to a vault. Connections are authorised on the provider's own sign-in page. ServAI never asks for, stores, or sees a password.
- No embedded editor. Opening your tool opens your tool, in your own browser tab.
ServAI is a client of your systems, never an operator of them. The value isn't that something can build a workflow — it's that ServAI can explain, evidence and stand behind the one it built.
When a connection breaks
If a credential is revoked, a token rotates, a permission narrows or an instance goes unreachable, the connection moves to suspended — and every workflow depending on it is suspended with it, deliberately. You get told what broke and what stopped.
A workflow that fails quietly is worse than one that never deployed: you find out from a customer complaint. A suspended workflow is a visible state you can act on.
Who supports what
| ServAI supports | You and your vendor own |
|---|---|
| The generated configuration | Instance uptime and hosting |
| Build and validation defects | Licence, billing, seats |
| Gate, receipt and clearance behaviour | Tool version upgrades |
| Connection health monitoring | Vendor product defects and provider outages |
We publish this boundary rather than leave it implied, so there is no confusion about who to call.
Capable is not cleared
A workflow that compiles and validates has demonstrated capability. It has not thereby earned the right to run. That distinction is the same one applied everywhere else on the platform — see the thirteen gates and the governance model.
Governed Workflows is in active development and is released progressively as each target reaches the same technical and human validation standard as the rest of the platform. Confirm current availability for your stack with our team before planning a deployment around it.
Have an automation tool already, or none at all? Either way, tell us the outcome you want and we'll show you what a governed build looks like.
Request a Governed Workflows demo →