Temporal and Forest Workflows: Jobs for Developers, Processes for Ops

"We already use Temporal. Why would we need Forest?"

Fintech engineering teams ask us this often. The short answer: the two tools solve different problems, and the strongest setups run both.

Two tools, two owners

Temporal executes jobs that engineers write, deploy and own. Workflows live in code, ship through CI and change with a release.

Forest Workflows executes operational processes that ops teams design and change. Those processes run on the Forest backend, which your engineers customise with your data, actions and rules.

Where they differ: who handles the exception

Every workflow engine has to decide what happens when a step fails.

Temporal decides in code. Engineers set retry policies, make activities idempotent and write the compensation logic, and teams that run Temporal well have this under control.

Forest Workflows hands it to a person. Forest never retries a step with side effects (an action, a record update, an MCP call) on its own. If that step fails, or the runtime crashes while it is running, the run stops there and waits for an operator. The operator sees the record as it stands now, checks whether the change went through, then retries, revises or abandons the step.

For fully automated jobs, Temporal’s approach is the right one. In operations, the exception is the job: a KYB case that doesn’t fit the rules, a disputed refund, an AML alert. The person handling it needs a place to work, and Forest Workflows gives them one.

What building it yourself really takes

Temporal is a building block. It runs the workflow, but it does not give the person handling the exception a place to work. Teams that route human steps through Temporal end up building the rest themselves:

• a back-office screen showing the case and the customer data

• a queue that dispatches cases to the right team

• per-role permissions on who can see and do what

• an audit log of every decision and change

• a way for ops to change the process without filing a ticket

Then they maintain all of it, release after release. Forest Workflows ships these as the product, on top of a backend your engineers customise with your data, actions and rules.

What Forest Workflows guarantees on every run

• State is persisted. A run can wait for a person (a KYB review, an approval, a four-eyes check) as long as it takes.

• Runs resume after a crash. The runtime checks in with the orchestrator regularly and picks up unfinished steps. The one exception is a step with side effects caught mid-flight: rather than risk running it twice, Forest stops and hands it to an operator.

• Every step has a timeout.

• Calls from the runtime to the orchestrator are retried with backoff.

• Your data stays on your infrastructure. The runtime runs next to your Forest backend, and the orchestrator only receives step statuses, never record data. AI and MCP steps send their prompts to the model and the MCP tools the workflow uses.

• Every action and decision on a record is audited, and steps run under the permissions of the account running the workflow step.

What Forest leaves to Temporal

Forest Workflows does not retry failed steps automatically: a failed step waits for a person. It has no durable timers, so “wait three days, then send a reminder” belongs in Temporal. It does not offer deterministic replay.

Changing a process while runs are in flight also works differently. Runs already in progress finish on the version they started on. New runs use the updated process.

If your process depends on fine-grained automatic retries, long timers or replay, that part belongs in Temporal.

When Temporal is the right choice

• Fully automated orchestration with no human in the loop: sagas, ETL, batch processing.

• Strict reliability needs: fine-grained retries, long timers, replay and code versioning.

• High volumes and throughput, with engineers who own the workflow code end to end.

• Complex business logic that is easier to maintain as tested code than as a diagram.

• Processes designed and owned by developers, with no need for ops to change them.

When Forest Workflows is the right choice

• A person has to look, decide or approve: KYB and KYC reviews, disputes, refunds, account closures, AML alerts.

• Ops need to change the process themselves, without waiting for a release.

• Every action must be audited and bound to the permissions of whoever performs it.

• People, AI agents and your systems work in the same process.

At a glance:

Keep Temporal, add Forest Workflows

The two connect in both directions.

From Temporal to Forest, the connection is native. A Temporal workflow or activity starts a Forest workflow with a webhook (a signed HTTP call that returns a 202 with the run ID) or through MCP. Temporal keeps the automated job and hands the human step to Forest.

From Forest to Temporal, it takes one piece of glue code. There is no packaged Temporal connector. A step in a Forest workflow calls an action: code in your Forest backend that starts or signals a Temporal workflow through the Temporal SDK. Your engineers write it once, and ops can then reuse it in any process.

Example: business onboarding across both

1. Temporal runs the onboarding job: collects company data, calls the registry and screening providers, scores the risk.

2. When a case needs review, Temporal starts a Forest workflow through the webhook.

3. In Forest, an AI agent pre-checks the documents and flags gaps.

4. A compliance analyst reviews the case with the customer data on one screen, then approves or rejects.

5. The decision step calls an action that signals the Temporal workflow, which opens the account or closes the file.

Every action in Forest is audited, and ops can change the review steps without a release. Temporal handles the volume. Forest handles the judgment.