Tasks and human-in-the-loop
A task is the platform’s way of pulling a human into an otherwise automated flow. When a process hits a step that needs human judgement — approve this invoice, review this contract clause, decide which path to take — the platform creates a task, lists it in the inbox, and pauses the process until someone acts. When the person submits a decision, the platform unblocks the process and the next step runs.
This sounds simple. It’s also the platform’s most consequential design choice. Most automation systems treat humans as a fallback — something you grudgingly fall back on when the automation fails. Superprocess treats humans as a first-class step type, equal to agents and integrations. The whole platform is built around the assumption that real business processes mix software, AI, and humans, and that the boundaries between them shift over time.
Why human-in-the-loop matters
Section titled “Why human-in-the-loop matters”Three reasons HITL is structurally important:
- AI agents are wrong sometimes. A model that’s right 99% of the time, run a thousand times a day, is wrong ten times a day. For low-stakes decisions that’s fine — auto-classify and move on. For high-stakes decisions (approving a payment, signing a contract, escalating to legal) those ten errors a day need to be caught. The cheapest way to catch them is to have a human look at the cases the model is least sure about.
- Some decisions never automate. A vendor’s first invoice. A refund larger than the customer’s lifetime spend. A line item that doesn’t match any historical category. The right answer is judgement, not pattern matching. Trying to encode judgement in a rule or a prompt usually fails.
- Regulators and auditors expect human oversight. A regulated process (finance, healthcare, legal) that runs end-to-end without human touchpoints draws scrutiny. A documented human-approval step gives auditors something concrete to point at.
HITL is the answer to all three. The cost is the latency of waiting for a person; the value is correctness, judgement, and accountability.
When tasks get created
Section titled “When tasks get created”Three patterns account for most tasks in production:
- Explicit user tasks. The process diagram has a user task element. Every run hits that step and creates a task. The most common case — a designed-in approval gate.
- Confidence-based routing. An agent step produces output that includes a confidence score. A subsequent gateway routes low-confidence cases to a user task. The high-confidence majority auto-progresses; the low-confidence minority gets human review. This is where HITL pays for itself on agent-heavy flows.
- Exception handling. Something unexpected happened — an integration returned an error the process can’t auto-resolve, a value fell outside expected bounds. The process catches the exception, creates an exception-handling task with the context, and waits for a human to decide whether to retry, escalate, or abandon.
Other patterns exist (timer-driven escalation tasks, second-opinion tasks for compliance) but they’re variants of the three above.
The task lifecycle
Section titled “The task lifecycle”A task moves through a small set of states from creation to closure:
stateDiagram-v2 state "In progress" as InProgress [*] --> Created Created --> Assigned: claim / auto-assign Assigned --> InProgress: opened InProgress --> Completed: form submitted InProgress --> Assigned: released Assigned --> Escalated: timeout / reassign Escalated --> Assigned: reassigned Created --> Cancelled: process ended Completed --> [*] Cancelled --> [*]
- Created. The process emits the task. It carries the context the human needs to decide: variables from the process instance, agent outputs, source documents, and (optionally) a deadline. It’s visible in the inbox to everyone in its assignee group.
- Assigned. Someone claims it — or the task’s assignment strategy hands it to a specific person. It’s now theirs; no one else can act on it. This prevents two people from approving the same thing.
- In progress. The person opens the task and works through it — reviewing the context and filling in the completion form.
- Completed. They submit. The platform records the outcome and unblocks the waiting process; the next step runs.
Two side states round it out: a task can be escalated (raised to a higher authority — for example after a deadline passes) or cancelled (its process was cancelled, so the task disappears). A claimer can also release a task back to the queue, or reassign / delegate it to someone else.
Common patterns
Section titled “Common patterns”Beyond the lifecycle, four patterns appear repeatedly in real processes:
- Approval. Single-decision gate. “Approve or reject this invoice.” Usually has a configurable threshold (above $X requires manager, above $Y requires VP). The default for any flow involving money or external commitment.
- Review. Multi-field check. “Verify the extracted invoice fields look right.” The reviewer can edit values before approving, not just say yes/no. Common for cleaning up agent output before it lands in the system of record.
- Escalation. A task that wasn’t decided in time gets re-created at a higher authority level. “Manager has 24 hours; if no decision, escalate to director.” Implemented as a timer event attached to a user task.
- Second opinion. A first reviewer approves, but the process requires a second independent reviewer for cases above a certain threshold or matching a flag. Two sequential user tasks with different assignee groups.
Each pattern is built from the same primitives — user task, gateway, timer event, signal — composed differently. The user guide’s handling tasks page shows the approval pattern in concrete detail.
How tasks integrate with the rest of the workflow
Section titled “How tasks integrate with the rest of the workflow”A user task is conceptually the same as a service task: it’s a step in the diagram, it consumes process variables as input, and it produces variables as output. The difference is just how it’s executed — a service task calls a function; a user task waits on a human signal.
This consistency matters: gateways, conditional flows, parallel execution, error handling — all of it works the same way regardless of whether the upstream or downstream step is human or automated. You can have a gateway downstream of a user task that branches on the decision (approve → post; reject → notify). You can have multiple user tasks in parallel (two approvers required, either can act independently). You can timeout a user task and fall back to an auto-decision.
The platform doesn’t impose ceremony around HITL. It’s just another step type.
What humans see
Section titled “What humans see”When a person opens a task in the inbox, the detail page shows everything they need to make the call: the process instance’s variables, any source documents (the invoice PDF, the contract, the email), the agent’s output, and a form to complete. The fields to fill and the actions to take — approve, reject, request info — are defined by the form bound to the user task, not a fixed set of buttons. An AI review assistant rides alongside the form: it summarises the task, flags fields that need a closer look, and answers questions about the case. They never see the process diagram unless they ask — the task is self-contained context.
This separation matters: an approver doesn’t need to know the shape of the process to do their job. They need to know what they’re deciding and why. The platform optimises for that.