Describing a process instead of drawing one
The reason companies end up with approvals living in email is rarely that nobody wanted a process. It is that describing one properly - the statuses, the transitions, the conditions, the fields, who approves what, what happens on rejection - is a specialist job, and the specialist is busy.
So say it in words instead. What is being requested, who fills it in, who signs it off, what makes it go the other way, and what should happen when nobody responds. What comes back is a working process: the task type and its fields, the statuses and the transitions between them, the conditions on those transitions, and the roles that decide who does what.
The thing itself, not a diagram to hand to somebody for implementation.
And it is described, not generated into place
The output is an artifact of an application, the same as a data model or a workbook - which is what separates this from a tool that writes a configuration into a live system and leaves you to hope.
- It can be read and reviewed before it runs, by somebody who is not the author.
- It is versioned, and what changed between two versions is a question with an answer.
- It arrives with everything around it - the data model the fields resolve against, the pages where the form is opened, the dashboards the tasks feed - generated as one description, not as four separate asks.
- A published version is immutable: a process does not change underneath the people currently standing in it.
What that repository is and why it is the point is AI in the data layer.
There is also a catalogue of processes that already exist in the platform's applications, and the assistant reads it before inventing anything - so a purchase approval starts from how purchase approvals are built here, not from a blank page.
An agent as a step
The other direction is more interesting: an agent inside a running scenario.
A step in an orchestrated scenario can be a call to an agent - read this attachment and pull out the amount, classify this incoming request, draft the reply, decide which of these needs a human to look at it. The scenario continues with what the agent produced.
What makes that usable rather than alarming is that it is a step like the others. It runs inside the same durable machinery: its result is persisted, a restart does not lose it, a failure routes to the error path, and a compensation can undo what came before. It is bounded by the same timeouts, and its cost is metered like every other model call on the platform.
And where the agent is doing something consequential rather than reading, the pattern is already built into the process itself: the scenario asks a person and waits. A human step costs nothing while it waits, so "let the agent draft it and a person approve it" is the ordinary shape, not an extra system.
What it does not get to decide
An agent inside a process has exactly the permissions the process gives it, and the same recording applies to it as to anybody else: what it did is in the task's history under its own name. A transition that requires an approval still requires one. A field it may not write, it does not write.
The useful way to think about it: the agent is a very fast participant, not an exception to the route.
Next
Under the hood - the two engines, what is guaranteed, and what is bounded on purpose.