# AI in processes

> Describe the approval you need and get a working process - and put an agent inside a running scenario as a step that has to answer for itself

Source: https://aipril.dev/docs/processes/ai

## 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](https://aipril.dev/docs/engine/ai.md).

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](https://aipril.dev/docs/processes/automation.md) 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](https://aipril.dev/docs/processes/under-the-hood.md) - the two engines, what is guaranteed, and what is
bounded on purpose.