Product / Workflows
Describe it. The firm runs it.
Automation authored in plain language, constrained to the tools your firm actually has, and honest about what writes.
Join waitlist
Authored in English
An author agent constrained to your tenant's tool allowlist.
Read/Write badges
Every step declares whether it reads or writes.
Permissions at fire time
The runs-as principal re-binds on every execution.
Every firm runs on processes that live in one person's head and get done by hand — again and again. Automation tools exist; nobody has time to become their operator.
Say what should happen
Describe the process in plain English, or start from a template. An author agent drafts the workflow — constrained to your tenant's tool allowlist, so it can't invent capabilities.
Author agent is bound to the tenant tool allowlist.
See what it will do
Edit steps, triggers and the runs-as principal. Every step carries a Read or Write badge — you can see at a glance what merely looks and what acts.
Read/Write badges are derived from the step's tool, not declared.
Permissions apply at fire time
Execution re-binds the runs-as principal when the workflow fires, so per-user permissions always apply — no frozen credentials.
Runs-as is re-resolved at execution, not authoring.
Run it anywhere
On a schedule via the job queue, on demand, mid-conversation — or called by the agent as a tool.
Workflows are callable as agent tools.
Also in Workflows
Run history
Every run recorded — what fired, what it did, what it touched.
Run now
Fire a workflow on demand, or from inside a conversation.
Mined suggestions
IQ notices your recurring tool sequences and proposes them as workflows.
Self-proposed revisions
A workflow that keeps failing proposes its own next revision.
I described our Monday pipeline review in two sentences. The draft it produced used exactly the tools we have — nothing imaginary.
- A run that writes warns first, naming the write actions
- Nothing consequential fires unconfirmed
- Per-user permissions at fire time
- Firm-isolated