New Forest Workflows: everything regulated ops teams need to automate with control

Ops teams in regulated finance handle more volume every quarter, and their control requirements stay the same. The work is now shared between analysts, outsourced teams and AI agents.

Over the past year, we built with the teams at the forefront of agentic ops, the early adopters of Forest Workflows. Their feedback shaped every release. Workflows is now a complete solution for regulated ops, built on four capabilities:

• Triggers that match your operational context. A process starts when a record is updated, or when another tool or agent in your stack calls it.

• Rules where the policy is explicit, and AI where judgment is needed. You choose the mode step by step.

• Steps that complete themselves. AI agents can work inboxes under their own identity.

• Control built in. Exceptions escalate to a person, and every change is recorded down to the field.

Let's review these new features and how they work together to help ops teams automate and deliver.

Our vision for automated ops: processes run, humans supervise

When switching to automated processes, ops teams stop pushing each case through by hand. They design the process, the process runs, and they step in on the cases that need them. They also adjust the process themselves, without a developer ticket for every change.

We built Forest Workflows in stages, guided by that vision and by our users' feedback and insights. Workflows started as guided steps for operators. We then brought AI into the steps with AI decisions, Guidance Tasks and AI-suggested values. Deterministic steps came next. Automatic triggers and the controls that make automation safe in a regulated process complete the set.

Each workflow, and each step inside it, is configurable. The team decides what starts the workflow, which steps follow a rule, which steps use AI, which steps complete automatically, and where a person signs off.

Analysts, outsourced teams and AI agents work in the same workflows and the same inboxes. Each of them acts under their own identity, either as a user or as a service account, so every action can be traced to whoever performed it.

Triggers that match your operational context

Ops stacks are fragmented. A support team works in Zendesk, a manager works in Claude, and a specialist AI agent runs compliance checks. Forest keeps the data, the workflows and the actions in one place, and lets each process start from the tool where the work happens.

A workflow can be triggered in four ways:

• On record change (new). The workflow starts when a record is updated, for example when a status changes or a document is received. Nobody has to notice the change before the process starts.

• Webhook. Any system in your stack, such as a KYC provider, a core banking system or an internal service, starts a run on a record by calling the workflow's signed URL.

• MCP. An AI agent lists the available workflows and starts one on a record through the Forest MCP server. The agent can be a general assistant such as Claude or Dust, or a fintech specialist agent such as Sphinx for compliance checks.

• Manual. An operator starts the run from Forest.

Service accounts: dedicated accounts that run automations

A run started by a tool or an agent needs an identity, and a service account gives it one without borrowing a person's login. A service account has its own role and teams, so it reads and writes only the data and actions that its role allows. It holds the application tokens that tools and agents use to call Forest, and revoking one token disconnects only the tool that uses it. Every action it takes is logged under its own name, separate from the operators' actions. Inbox automations can also run as a service account.

Guardrails

Each trigger is switched on separately for each workflow. Only one run of a given workflow can be active on a record at a time, so duplicate events do not start duplicate runs. Every automated run is labelled in the activity logs with the channel that started it, such as "via webhook" or "via MCP".

How to set it up: Workflow triggers, MCP server, Service accounts.

Why deterministic steps, and where AI still helps

In a regulated process, most of the policy is already explicit: thresholds, required documents and deadlines. Those steps must give the same answer every time, and the team must be able to explain that answer to an auditor. AI is useful on the steps that require judgment.

Every step in a Forest workflow now has a deterministic setting:

• Get Data and Update Data read and write the exact field on the exact record.

• Decisions in "Automatic (Deterministic)" mode evaluate conditions on data from earlier steps. New operators are available for these conditions.

• Sub-workflows can be deterministic too, so a shared check runs the same way in every process that uses it.

A deterministic step produces the same outcome for the same input, and its result can be explained line by line. It does not call a model, so it runs faster and its cost does not vary from one run to the next.

AI remains available where judgment is needed. Decisions can be manual, AI-assisted or fully AI. Guidance Tasks let AI draft text, such as a case summary or a customer email, and Update Data can suggest values with AI.

For example, in a KYB review, the check "turnover is above the threshold" is deterministic, and the question "is the business activity consistent with the declared sector?" is AI-assisted. As a rule of thumb, if your policy can express a check as a condition, make that step deterministic.

How to set it up: Workflows overview.

Ways to control: fallback and the detailed audit trail

Automating a regulated process is acceptable only if every exception has an owner and every step can be proven afterwards.

Fallback inbox, with human-in-the-loop escalation

When an automated run reaches a step that needs a person, Forest sends it to the workflow's fallback inbox. Runs that fail also land in the fallback inbox, flagged as escalated. An operator picks up the run and finishes it from the step where it stopped, so no case is lost.

The team controls how far automation goes. Each step's completion can be set to manual or automatic, and action steps can execute automatically once the team trusts the AI's choice.

The fallback inbox uses the same controls as any Forest inbox: dispatch rules, automatic unassignment after an idle period, and a maximum number of concurrent tasks per operator.

The new detailed audit trail

Activity logs record who did what and when. Each automated run is attributed to the user or the service account it acted as, and it is labelled with the channel that started it.

The new audit trail records the field-level values before and after every create, update and delete. Forest stores these changes in a SQL database that you own, and the audit trail works with any datasource. The new Activity tab on each record shows the activity logs and the field changes side by side.

Every completed or aborted workflow run can be reopened in read-only mode, with each step, decision, input and output. Through the public API, you can send the activity logs to your SIEM or pull decision traces when a regulator asks for them.

How to set it up: Fallback inbox, Step automation, Audit trail, Workflow execution history, Public API.

One run, end to end

Take a KYB review. A record update starts the workflow. Deterministic rules clear the standard checks, and AI reviews whether the business activity matches the declared sector. When the case is clear, the Forest action executes automatically. When the case needs judgment, it goes to the compliance team's fallback inbox. In both cases, the full history is recorded on the record.

Forest Workflows now gives regulated ops teams everything they need to automate with control. You can watch the new Forest Workflows in action in our webinar replay:

If you run operations in a regulated fintech or bank, book a demo and one of our forward deployed engineers will map your first automated workflow with you.

October Changelog

What's new in Forest Workflows

Triggers

• On record change (new): a workflow starts automatically when a record is updated.

• Webhook: any system in your stack can start a run on a record through a signed URL.

• MCP: AI agents can start workflows through the Forest MCP server.

• Service accounts: non-human identities with their own role, teams and application tokens, for the tools and agents that act in Forest.

Deterministic steps

• Get Data and Update Data target the exact field on the exact record.

• Decisions can run in "Automatic (Deterministic)" mode, with new operators.

• Sub-workflows can be deterministic.

Automation and escalation

• Step completion and action execution can be set to automatic.

• Inbox automation lets AI agents work inboxes, running as a service account.

• The fallback inbox routes runs that need a person, and failed runs, to an operator, who resumes them where they stopped.

Audit

• The audit trail records field-level before and after values for every create, update and delete, in your own SQL database.

• A new Activity tab on each record shows activity logs and field changes side by side.

• Automated runs are attributed to a user or a service account and labelled with the channel that started them.

Docs: Workflow triggers · Service accounts · Step automation · Audit trail

Forest is the operational layer for regulated fintechs. Connect your core banking, payment and compliance providers as datasources, build the actions and workflows your team runs every day, and keep permissions and a full audit trail on every call. Runs on your own infrastructure.