Turn a finding into a governed workflow

An agent is a worker with a defined authority that decides what to do within it. A workflow is a defined sequence in which AI does some of the steps, people do others, and the path is decided in advance. Embedding AI in how the organisation operates is the job of the workflow layer, layer 05 of the platform.

The distinction matters when you build from an insight. If the finding is that something needs watching and reporting, an agent is a good fit. If the finding is that the same kind of case keeps arriving and is handled inconsistently, you want a workflow: the same steps, in the same order, with the same checks, every time.

Workflows are also easier to govern. The steps are visible, the approval points are explicit and the record follows the same shape on every run. That is why they are often where a new use of AI goes into production first.

Workflows tend to rot in the same few places. A routing rule names a group that has been renamed. An approval step names a person who has left. An escalation path assumes a reporting line that changed two reorganisations ago. Each is a fact about the organisation, copied into a workflow and then left to drift.

The Intelligence Platform is designed to keep those facts in one place, with history, and to have workflows read them. The people, groups and reporting lines are within what the appliance reads today from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace, with accounts resolved into people. Ownership of services and systems, and ticketing and business-system sources, are on the roadmap, and workflows that depend on them are designed for rather than available.

Because every fact carries an evidence status and an age, a workflow can say what it will rely on. It may be allowed to route on a verified owner but required to ask a person when the owner is inferred or stale.

A workflow is not trusted because it was designed carefully. It is trusted because policy is enforced as it runs. Each step runs as a known identity with permissions scoped to the tools and data it needs. Policy can allow, deny, warn, filter, escalate or require human approval at a step, and a policy change alters what the workflow can actually do.

Human oversight is a property of the workflow and not an afterthought. An approval step waits for a named approver and records who approved, when and on what evidence. The workflow cannot approve its own work.

Everything is recorded in a tamper-evident log: the identity, the data accessed, the model used, the output, the tools called, the policy applied, the decision, the approval, the action and the outcome. That record is the evidence you hand to a reviewer.

A workflow built from a finding will need to change as the pattern does. Treat the change as you would a policy change: versioned, reviewed by the owner and recorded. A new version should say which finding or measurement prompted it, so the history of the workflow reads as a sequence of reasons and not a sequence of edits.

Because routing and approvers are read from the graph, many of the changes that usually force an edit, such as a reorganisation or a new approver, do not. The workflow follows the organisation. The changes that remain are the ones that should be deliberate: what triggers it, what it may do and where people must say yes.