RapidfolioRapidfolio
Concepts

Procedures

A procedure is a visual workflow graph that an AI agent executes. It defines the steps, branching logic, and review gates for a financial automation.

The core idea

A procedure is a workflow you design visually as a graph — nodes connected by edges. Each node is a step: call an integration, evaluate a condition, wait for time to pass, or pause for a human to review. When a procedure runs, Rapidfolio's AI agent traverses the graph from start to finish, executing each node in sequence.

Think of it as a flowchart that the AI agent follows faithfully. The agent does not improvise — it cannot skip steps, add new actions, or deviate from the graph you defined. What you see in the editor is exactly what runs.

The same procedure can be run thousands of times, each time producing an independent, fully-logged run record.


Node types

There are four types of nodes:

Tool Call — calls an integration. This is where your procedure interacts with external services: charge a Stripe customer, fetch a Plaid balance, send a Slack message, run an Onfido check. You configure which connection to use, which action to call, and where each parameter comes from.

Condition — branches the graph. You write a boolean expression (e.g. inputs.amount > 10000), connect a true branch and a false branch, and the agent follows the matching path. Conditions are evaluated as deterministic code — never by the AI.

Human Review — pauses execution. When the run reaches a review node, it stops and appears in the Pending Reviews queue. A team member approves or rejects. Only then does execution continue (or fail, if rejected). Every decision is permanently logged.

Wait — delays execution by a fixed duration (minutes, hours, days). Useful for time-based workflows: wait 24 hours after sending an onboarding email, then check whether the customer completed verification.


How inputs work

Every procedure has a typed input schema — a set of named fields that callers pass when starting a run. Fields are referenced throughout the graph using {{inputs.fieldName}}.

For example, a payment procedure might have inputs:

FieldTypeDescription
customerIdstringThe customer to charge
amountnumberAmount in cents
currencystringISO currency code

Node parameters can then reference {{inputs.amount}} or {{inputs.customerId}} directly.


Chaining steps together

The output of any Tool Call node is available to later nodes via {{steps.nodeName.result}}. This is how you pass data through a procedure:

  • Node 1 fetches a customer from Stripe: result is {{steps.getCustomer.result}}
  • Node 2 sends an email to that customer: parameter toAddress is set to {{steps.getCustomer.result.email}}

The editor's inspector provides autocomplete for these references based on which nodes appear earlier in the graph.


Versions

Every change in the editor creates a new draft version. Drafts don't affect anything live. When you're happy with the changes, you publish the version — that makes it the default for new runs.

Published versions are immutable. You can always roll back to a previous published version in seconds.

→ See Versions for the full versioning guide.


Environments

The procedure graph is shared across environments. What differs is which connections each Tool Call node uses: a Stripe charge in sandbox uses your sandbox Stripe account; in live, it uses your live account.

→ See Environments for how sandbox and live work.


The AI agent's role

When a run starts, the AI agent receives the compiled procedure graph and the run's inputs. It executes each node in order, resolves input mappings, follows condition branches, and records every result.

Its role is purely execution — faithful traversal of the graph you built. This constraint is what makes Rapidfolio predictable and auditable. The agent cannot make up steps or take actions outside the procedure.

→ See Determinism for why this matters in financial operations.

On this page