Regulated processes need rules and a replay button. Here's why and how we built Forest Workflows.

In a regulated company, one case can now go through an external system, an AI step, an analyst, and a senior reviewer with wider permissions. Volume usually runs as a technical batch job, and individual cases are handled by people in a case tool. Two worlds, two logs. When a regulator asks how one case was decided, the answer is scattered across tools.

We built Forest Workflows around two requirements. A regulated process must run as one process, whatever mix of systems, AI and people works the case. And every case must be reviewable after the fact: who decided, under which rule, on which data. Automation runs the volume, people step in when judgement is needed, and every step has a fallback. Here are the choices behind it.

Every actor in a Forest Workflow acts under a known identity

Systems, AI agents, analysts and outsourced teams act inside the same workflow. Tools and agents that call Forest with an application token run as a service account, with its own role, teams and permissions. An assistant connected through MCP, such as Claude or Dust, acts as the Forest user who signed it in. Either way, every action is attributed to an identity with known permissions.

Permissions are enforced where data is touched: every read and write inside a run goes through the role of the identity the run acts as. Escalation follows the same model: the case moves to someone with wider rights.

Fallback. Revoking a token stops that one tool from starting new work, without touching the rest. A run already in progress fails on its next data access once the revocation has propagated, or can be aborted explicitly.

Forest Workflows use deterministic steps where policy is explicit, AI where judgement is needed

Each step picks its execution mode:

• Deterministic. Get Data and Update Data read and write exact fields. Decisions run in "Automatic (Deterministic)" mode. Sub-workflows can be deterministic too.

• AI-assisted or full AI. Decisions, Guidance Tasks that draft text, Update Data that suggests values.

• Manual. A person decides.

Some of our customers have to prove their process is reproducible, and they don't want a probabilistic model deciding a step that a rule can decide. When we know exactly what a step must do, a deterministic step is also cheaper: it calls no model, so it costs no tokens and its cost doesn't vary from one run to the next.

A deterministic step gives the same result for the same input, and that result can be explained line by line. An AI step adds judgement and leaves its reasoning on the record. Our rule of thumb: if the policy can be written as a condition, make the step deterministic.

One choice we made on purpose: we didn't put a confirmation prompt on every AI tool call. MCP Tasks call their tools directly, so the control sits upstream. Each step lists the tools the AI may use, and anything that sends an email or deletes a record stays out unless you add it.

Fallback. When an AI decision can't conclude, it doesn't guess. In an automated run, the case lands in the fallback inbox, flagged "AI couldn't decide", and a person picks it up from that step. In a manual run, the operator can handle any AI step manually.

Forest Workflows start from the system that sees the event first

A workflow has four triggers:

• On record change. The simplest of the four: when a status changes or a document arrives, the process starts, without anyone noticing the change first and without any integration to build.

• Signed webhook. A KYC provider or a core banking system starts the run.

• MCP. An AI agent such as Claude, Dust or Sphinx starts the run through the Forest MCP server.

• Manual. An operator starts it from Forest.

External systems start the process, and a person only receives the case when a decision needs them. High-volume and case-by-case work run on the same engine: one run per record, whichever system, agent or operator started it.

Triggers are enabled per workflow. Only one run of a given workflow can be active on a record at a time, so a duplicate event can't start a duplicate run. Automated runs are labelled with their starting channel in the log.

Fallback. A run that hits an error doesn't disappear: it lands in the fallback inbox, flagged as escalated, with the error recorded on the step where it stopped, and an operator picks it up from there.

Operators work from their main tool, and every action lands on the same Forest record

We observed that people work better in the tool they already live in. So operators work from there: the Forest app inside Zendesk, or a custom tool the team built for its own process on top of the Forest Gateway. Whatever the interface, every action writes back to the same Forest record, under the operator's own identity, and the log knows which tool it came from.

No automated Forest Workflow can start without a fallback inbox

Automated triggers can't be switched on until a fallback inbox is selected. A workflow that can start with nobody watching must have somewhere to send the cases that need a person.

Runs that need judgement, and runs that fail, land there. Operators resume from where the run stopped. Step completion and action execution can each be set to manual or automatic, and the inbox supports dispatch rules, automatic unassignment after idle time and per-operator task limits. In a regulated process, automation can pause a case. It can never drop it.

The replay button: a field-level audit trail in your own database

Replay here means review: every completed or aborted run reopens read-only, with each step, decision, input and output.

• Field-level before and after values for every create, update and delete made through Forest. In critical mode, a write whose audit entry can't be recorded is refused, so no change goes unaudited.

• Captured on any datasource, stored in a PostgreSQL database you own. You can audit a Mongo datasource into Postgres.

• One Activity tab per record, with activity logs and field changes together.

• Activity logs export to your SIEM through the public API. Field changes sit in your own database, so you query them directly when a regulator asks.

A workflow run carries no record data. Records stay on your side, in the runtime, and the orchestration only keeps track of the steps. The record of decisions belongs to you, in your own infrastructure. More in the audit trail docs.

A KYB review on Forest Workflows, step by step

One case, one record, reviewable end to end.

What Forest Workflows do to average handling time

Cases that don't need a person never reach one, and the ones that do arrive with the data already gathered. At a European neobank, [PENDING: average handling time figure, before and after, and the process it covers].

If your regulated processes run across several tools and several logs, book a demo to see one case on one record.

Forest is the operational infrastructure regulated companies grow on.