Is a process the same as a workflow?

Close, but with a stricter contract: a Raisy process is a directed graph whose steps are executed by bots and whose external edges carry approval gates, all logged per run.

Can a process branch?

Yes. Branches are just edges; the run follows the graph.

What happens at a gate?

The run pauses, the prepared action is shown, and a human approves, edits, or rejects. The gate decision is logged with the run.

Can I run a process without gates?

Autonomy is earned per bot, not turned off globally. Gates scale down as a bot proves reliable, but the run is always recorded.

AI Process Orchestration: Why Prose Playbooks Break

A playbook written in prose is not auditable. There is no way to point to step four and say "this is exactly what ran, in this order, and here is where it stopped for a human." A process written as a directed graph of steps: each step executed by a bot, some edges gated for human approval, can.

What we set out to change

Companies run on repeatable methods: qualify a lead, prepare an investor update, screen a candidate. In most tools those methods exist as prose: a doc, an email thread, a person's memory. Prose falls short in two ways. It does not execute, so a person still does every step by hand. And it is not auditable, because nothing records which steps ran, in what order, or where a decision was made.

The second is the boundary. The risky part of automation is not the drafting; it is the moment a prepared action crosses to the outside world. A playbook gives no natural place to pause there. (A process that runs and crosses a boundary is exactly the event every action's receipt records, and the steps load kernels , the rules each bot applies. Browse the blog.)

The idea / how Raisy fixes it

A process is a directed graph: nodes are steps, edges are order, and some edges carry an approval gate. Each step is executed by a bot. When a run reaches a gate on an edge that leads outside the company, it pauses and enters review mode: a human approves, edits, or rejects the prepared action before it proceeds. The graph is the source of truth; the run is a dated execution of that graph.

How it works

Steps are nodes. Each step names the bot that executes it and the kernels that bot loads.
Order is edges. Directed edges define sequence and branches; a run follows the graph, not a memory.
Gates pause external effects. An edge that would cross to the outside world carries a gate; the run stops in review mode until a human decides.
Approval modes scale. A bot in MANUAL is gated on every action; in SEMI_AUTO it passes routine actions and gates the external ones; in FULL_AUTO it runs and you audit anytime.
Every run is logged. The process run record captures the graph, the order that actually executed, and where it paused.

What the user actually sees

You open a process and see its graph: four steps, one branch, one gate before the final email step. A run starts, steps one through three complete, the run pauses at the gate with the prepared email and a prompt: approve, edit, or reject. You approve, the email sends, and the run is recorded end to end. The same graph runs the same method tomorrow, and you can point to where your judgment entered.

Figure 1. A process is a directed graph: bot steps feed a human review gate, and only an approved action crosses to the outside world — then the whole run is logged. Drag to reposition; the edge to the gate is the decision.

Enlarge

Why this matters beyond convenience

Structure is what makes automation reviewable. The moment a method becomes a graph, three things change: it executes without a person doing every step by hand, it pauses exactly where a human decision matters, and it produces a record a reviewer can reconstruct. That is the difference between a playbook that describes work and a process that does work, with the human still at the gate.

Write your first process as a graph at raisy.team