Deterministic where it must be.
Agentic where it pays.
Two execution models on one governed spine, and the freedom to mix them. An automation runs a fixed path you can read line by line before you ever turn it on. An agent reasons toward a goal and picks its own path. Hand one step of a fixed path to the agent and you get both. All of it runs under the permissions of the person who asked, and none of it skips your approval policy.
The question is who chooses the path
That is the whole distinction, and it decides which one you should reach for. Everything else, the permissions, the audit trail, the approval gate, is identical.
| Property | Automation |
|---|
A path you can read before you trust it
Trigger, condition, action, built on a canvas. A condition is a fork rather than a filter you either pass or fail: it has a true path and a false path, and both are paths you get to design. Same input, same output, and a run record either way.
At record scope, a branch is a set, not a loop
Most workflow tools answer volume with iteration: walk the list, evaluate each row, act on the ones that match. That is fine for a queue of a few hundred and it degrades exactly when pricing gets interesting, because a price list is tens of thousands of rows and every one of them is a round trip.
Record-scope automations do not evaluate conditions row by row. The condition is pushed down into the query as a filter, so the true path carries the rows that match and the false path carries the complement. Each branch is a subset, each action is one set-based write over that subset, and both paths run.
Practically: 1,842 SKUs cross that cost threshold and the flag is a single write, not 1,842 of them. The work scales with the number of branches you drew, not the number of rows you own.
A price list has to be recalculated before an automation will run against it. A stale sheet is not a safe thing to act on, so the engine refuses rather than acting on numbers that no longer hold.
Give it the goal, watch it work
An agent plans, calls a tool, reads what came back, and decides what to do next. It keeps going until the goal is met or it runs into something it should not pass on its own. You see every step as it happens.
What the agent cannot do
- Exceed your permissions. The tool list is filtered per call against the caller's role. A tool you cannot use is not a tool it can reach, so it is never even offered.
- Act unlogged. Every call is written to the audit trail with the resource it touched, before the result comes back.
- Run away with it. Thirty steps and it stops to ask. Two consecutive tool failures and it aborts rather than thrashing.
- Ignore the policy. When it moves something through a lifecycle it names the verb, and the policy decides whether that verb is legal from the current state.
You can also stop it mid-run. The abort is checked before each tool call, not after the batch.
One step of judgement, inside a path you fixed
Most work worth automating is deterministic apart from one moment that genuinely needs reading. Rather than choose between the two models, put the reasoning where that moment is and leave the rest alone.
Trigger and conditions do what they are good at: reduce thousands of rows to the ones that actually warrant a look, deterministically, the same way every run.
An Ask Copilot step takes the entity as its context, and is told what changed since the last run before it is told what to do. It plans, calls tools, and answers.
If something should now move, that is a transition step naming a verb, and your policy decides whether it is legal and who signs. Reasoning does not confer authority.
Worth being exact about
An Ask Copilot step is a real action type, alongside alert, set field, system task and transition. Drop it into a flow and that step runs the full agent: it gets the entity as its context, plans, calls tools, and comes back with an answer. So a flow can be wholly deterministic, wholly reasoned, or a fixed path with one reasoning step in the middle of it.
What keeps that honest is the frame around the step. The agent is told where it is running before it is told what to do, because nobody is watching and it cannot ask which entity you meant. It runs on a thread that exists only for that step. And the run record keeps the prompt, the reply and the tools it used, so a reasoning step is as readable after the fact as a set-field step.
It still cannot write a state. If the next thing that should happen is an approval, that is a transition step, and the policy decides whether the verb is legal. Reasoning gets you the answer. It does not get you the authority.
Six that earn their keep
Each of these is built from the triggers, conditions and actions above, on the four entity types that carry automations. Pick one to see the shape it takes and which model does the work.
Where this sits
Not screen-scraping RPA
Nothing here drives a browser or replays clicks against someone else's UI. Automations act on governed records through the same service layer the application uses, so a change cannot land in a state the product would not otherwise allow.
Not an autonomous pricer
No agent publishes a price on its own authority. It works inside the permissions of whoever asked, and a live change still meets the approval policy. Speed comes from removing the waiting, not from removing the sign-off.
Not a separate product
Both models run on the same spine as everything else: the same records, the same lineage, the same audit trail. An automation that flags a price list and an analyst who opens it are looking at one object, not two copies.
Bring us the workflow you keep doing by hand
The ones worth automating usually announce themselves: a spreadsheet that gets rebuilt every month, a check somebody does on a Friday, a change that waits three days for an approval nobody disputes. We will map it to the shape above and show you which of the two models it wants.