Agentic Workflows
Agents that do the work nobody wants to do.
Your processes do not fail on the clean parts. They fail on the PDF from a supplier, the photo of a delivery note, the ticket in a shared folder — the work a person has to read, judge and retype. A flow puts a language model inside the process to read it, decide what it means, and hand the answer to the next step.
The messy half
The part of the job that never fitted a form.
Every business runs on documents that arrive in whatever shape the sender felt like. Automation that only handles the tidy path is automation that hands the hard half back to a person — which is most of the work.
A supplier invoice as a PDF attachment
A delivery note photographed on a phone
An expense ticket, creased, in a shared folder
A payslip that has to match what the ledger says
A spreadsheet somebody keeps by hand
An email that should have been a form
A flow reads all of these and turns them into fields the rest of the process can act on.
What makes it agentic
A model in the graph, not a chatbot beside it.
Four capabilities do the heavy lifting. Each one is paired with the constraint that makes it safe to hand real work to, because an agent you cannot bound is an agent you cannot use.
A model inside the process
One step in the flow is a language model with a job: a prompt, the exact set of tools you allow it, and a result whose fields you declare — severity, reason, amount, whatever the next step needs. It is not a chatbot bolted on the side. It is a step, and what it returns is structured enough for the rest of the graph to branch on.
The constraint
The model only ever reads. Every write is a separate step you can see on the canvas — so an action is never taken inside a model’s reasoning where nobody can review it.
Paperwork read for you
A supplier invoice as a PDF. A ticket photographed on a phone. A payslip, a delivery note, a form somebody scanned crooked. The flow reads it and returns fields: who issued it, their tax number, the dates, the totals, and every line with its quantity, unit price and tax rate. Invoices, bills, expense tickets and payslips have shapes built in — for anything else you declare the fields you want and get those.
The constraint
Extraction is metered, so a rehearsal of the flow answers from the sample you gave it rather than spending a real scan.
Documents where they already live
Suppliers do not send things the way your process wants them. A flow can list and fetch files straight out of a connected drive, loop over what it finds, read each one and act — so "the invoices are in a shared folder" stops being a person’s morning.
The constraint
The connection is a grant your company makes once. The flow never holds the credential, and nobody pastes a token into a node.
Describe it, and it drafts it
Say what you want to happen in your own words and get a working draft back — the steps wired, the conditions filled in, pointed at your actual data. It is allowed to look at your data while it drafts, so what it builds fits what you really have rather than a generic example.
The constraint
It cannot change your data and it cannot publish. What lands is a draft, and a person publishes it.
Around the intelligence
The rest of the process, drawn.
The model decides; the graph does. Everything a flow acts with is a step you can see, reorder and diff — not something buried in a prompt.
- Branch on what it found, and loop over a list
- Ask a person to approve before anything continues
- Send the email, the notification, or the request to another system
- Call any of the business operations the product already exposes
- Run your own code, sandboxed, when nothing else fits
- Build a report from what the run produced, at an address somebody can open
Starting a run
Five ways in.
Someone runs it
With the inputs the flow asks for.
On a schedule
Every night, every Monday, the first of the month.
Another system calls it
A signed URL something outside can post to.
Something happened
An invoice posts, a lead arrives, a document is signed.
The crew hands it over
A finding an AI Crew check files. Ask from the card; a person publishes the flow.
A run
You can always see what it did.
Every step records what it received, what it returned and how long it took. A run waiting on a person says so. A run that failed says where. Nothing about an agent’s decision is hidden — you can read the reasoning it submitted and the fields it filled.
Before it touches anything
Rehearse it, version it, and bound what it can reach.
Watched by
Compliance
Rehearse the whole thing
Run the graph with anything that would cost money or change data stubbed out, and read the shape of the run before it is real.
Drafts and publishing
Edit a draft as long as you like. A version is validated before it can go live, and a running instance never changes underneath itself.
It cannot exceed your permissions
A flow runs as a principal with real permissions. The agent inside it sees what that principal may see — decided by the database, not by the prompt.
Bounded reach
Calls to the outside world cannot be pointed back at internal addresses, and your own code runs sandboxed, with no filesystem and no network of its own.
Three automation surfaces
Not everything should be a flow.
Approvals and CRM automation are their own engines, because they answer different questions and need different guarantees.
Agentic workflows
Processes you draw, with model steps, document reading and code where you need it.
Approval workflows
Who must approve what, across 21 record types, with conditions, roles and managers as approvers.
CRM automation
Playbooks on conversations and deals, with send caps, opt-outs and a send window so nobody gets messaged at midnight.