Platform overview
Superprocess is a platform for running business processes that mix software, AI judgement, and humans. You model the flow visually — what should happen, in what order, under what conditions — and the platform runs the flow for you. When the flow needs to understand something (a document, an email, a request), an AI agent handles it. When a decision genuinely needs human judgement, the platform queues a task and pauses the process until someone acts. When the answer is mechanical, the platform just does it.
Three properties define what the platform brings to the table:
- Visual modelling, no code. Processes are diagrams; agents are configured, not coded; connectors are set up from a catalog. The people who understand the work are the people who build it.
- AI as a first-class building block. Agents aren’t bolted on. They sit alongside human tasks and automated steps as one of the kinds of work a process can do.
- Durable execution. Once a process starts, it runs to completion. Crashes, restarts, network blips, vendor outages — the platform recovers and continues. You don’t write retry loops or build state machines. You declare the flow; the runtime handles the rest.
The moving parts
Section titled “The moving parts”Superprocess groups its surfaces by what you do with them, plus a runtime that ties them together.
flowchart LR T([Trigger]) --> P[Process] P --> A[AI agent] A -->|calls| I[Integration] A -->|hands off| K[Human task] I --> O([Outcome]) K --> O
Build — where you author the pieces of a process:
- Processes. A drag-and-drop canvas where you build a BPMN diagram of the workflow. See BPMN basics for the visual language.
- Agents. Where AI agents live. Each agent has a system prompt, a structured output type, and a set of tools it can call — including connectors and MCP servers. See AI agents for what an agent is and isn’t.
- Functions. Small units of custom logic, written in Python, for the mechanical steps a diagram shouldn’t carry inline — a calculation, a validation, a data transform. A function has typed inputs and outputs and is versioned, so a process step calls it the same way it calls anything else.
- Decisions. DMN decision tables for rule-based branching. When a choice comes down to a table of conditions — credit tier by amount and region, routing by ticket category — a Decision keeps those rules out of both code and agent prompts, where they’d be hard to read and impossible to audit.
Monitor — where you watch work happen:
- Workflow Executions. Every run of every process, in a searchable inbox: filter by status, follow the sub-process tree, and open a run to its step-by-step timeline.
- Insights. Dashboards and charts built over your workflow data — throughput, bottlenecks, cycle times, outcomes. Compose a dashboard yourself, or ask the AI to build one from a plain-language question.
And a few surfaces sit alongside the flow:
- Tasks. The inbox of work waiting on people. See Tasks and human-in-the-loop for when tasks get created and how the lifecycle works.
- Forms. The structured screens people fill in to complete a task — designed once in a form builder, bound to a user task, and versioned like any other building block. A form can show fields conditionally, validate what’s entered, and let people add or remove rows.
- Integrations. Typed connections to external systems — your ERP, your ledger, your CRM — set up from a connector catalog. Credentials are stored centrally so they’re never embedded in process configuration, and the same connector can be handed to an agent as a callable tool.
Underneath all of it, a durable runtime keeps every running process alive. If a worker crashes mid-execution, the process resumes on another worker from the last completed step. If an integration call times out, the runtime retries with exponential backoff. None of this requires user-visible configuration — it’s the default.
Lifecycle of one piece of work
Section titled “Lifecycle of one piece of work”To make the abstractions concrete, here’s what happens when something arrives:
- A trigger fires. An email lands; a webhook arrives; a scheduled time hits. The trigger is part of the process model.
- A process instance starts. The runtime creates a fresh instance from the deployed process definition. Input data (the email’s attachment, the webhook’s payload) becomes the instance’s starting variables.
- Steps run in order. Each step is one of three things: an automated action (call an integration, transform a value), an AI agent (extract data, classify, summarise), or a human task (review and decide).
- Decisions branch the flow. When the process hits a gateway, it evaluates a condition against the instance’s variables and follows the matching branch. See How a process runs for the mechanics.
- The process completes. A terminal event ends the run. The instance’s full history — every step, every input, every output — is preserved for audit.
A single piece of work usually takes seconds to minutes if no humans are involved, hours to days if approvers are in the loop.
When Superprocess fits — and when it doesn’t
Section titled “When Superprocess fits — and when it doesn’t”The platform is designed for processes that have at least two of these properties:
- Multi-step. Work moves through several steps in a defined order. A single API call doesn’t need a process engine.
- Mixes automation and judgement. Some steps are mechanical, others need human review or AI inference. If everything is mechanical, a script or workflow tool is simpler. If everything needs human eyes, a ticketing system is simpler.
- Recurring. The same process runs many times — invoices arrive every day, tickets keep coming. Build-once-run-many is the value.
- Auditable. Someone needs to know what happened on a particular run. Regulatory, internal compliance, or just operational visibility.
It’s a poor fit for:
- One-off scripts or batch jobs (use a script).
- Real-time, sub-second latency requirements (use a microservice).
- Pure data pipelines moving rows between databases (use an ETL tool).
- Anything where you’d want to write the orchestration logic yourself in code — Superprocess prescribes a model, and the model is the value.
How the pieces fit together
Section titled “How the pieces fit together”The most important relationship to internalise: processes orchestrate, agents reason, decisions rule, integrations act, tasks engage humans, and Workflow Executions observe. Each surface has one job. Mixing them — putting business logic in an agent’s prompt, putting integration credentials in a process variable, building a custom UI to replace the task inbox — usually means the model is being stretched in a way that costs you the platform’s guarantees.
The user guide walks the invoice scenario end to end through the designer, agents, integrations, tasks, and Workflow Executions. Reading it after this page tends to make the abstractions click.