AI agents
An AI agent in Superprocess is a step in a process that uses a language model to do work that’s hard or impossible to express as conventional logic. Reading an invoice PDF and pulling out vendor, line items, and totals. Classifying a support ticket as billing, technical, or account-management. Summarising a customer’s history into three sentences for an approver. These are tasks where the rules aren’t clean — “find the vendor name” depends on a thousand variants of “where does vendor name appear on an invoice?” — and an agent handles them by reading the input and producing a structured answer.
You configure agents on the Agents page. You use them by attaching one to a service task in a process. The platform handles the rest: calling the model, parsing the output, retrying on failure, recording the call for the audit trail, surfacing the result to the next step in the flow.
What an agent actually is
Section titled “What an agent actually is”Under the hood, an agent is four things wired together:
flowchart LR IN[Input data] --> AG[AI agent] SP[System prompt] --> AG TL[Bound tools: MCP + connectors] --> AG AG --> OUT([Structured output])
- A system prompt — the durable instructions you give the model. “You extract structured data from invoice PDFs. Read the attached document carefully. If a field is genuinely missing, leave it None — don’t guess.” The prompt encodes the policy: what to do, what not to do, edge cases to watch for.
- A structured output type — a typed schema the model must fill in. For invoice extraction it’s a record with fields like
vendor: str,invoice_number: str,amount: Decimal,line_items: list[InvoiceLine]. The model can’t return free-form text; it returns a fully-typed record or fails. - A set of tools — typed function calls the agent can choose to make. Look up this PO number in the ERP. Verify this vendor name against the master. Tools come from connectors (an installed integration exposed to the agent) and MCP servers; the agent decides when to use them based on the prompt and the input.
- A model selection — which language model the agent talks to. Configurable per environment so production might use a more capable model and staging a cheaper one.
That’s it. An agent is not magic. It’s a model call with constraints on input and output, plus a way to reach out to other systems when it needs information.
Agent vs. regular automation step
Section titled “Agent vs. regular automation step”A regular automated step in a process is deterministic. Given the same input it always produces the same output. The logic is written down — “if amount is over $10K, route to manager; if vendor is on the trusted list, skip review.” You can read the rules; you can predict the output; you can debug by reading the code or the configuration.
An agent step is non-deterministic. Given the same input, the model might produce slightly different output across calls. The logic is encoded in the prompt and (to a much larger extent) in the model’s weights. You can’t read the rules in the same way; you can only observe behaviour.
Use a regular automation step when:
- The rules are simple and stable. (“Amount times tax rate equals total.”)
- You need predictable, repeatable output.
- The cost of an automation bug is high (financial calculations, regulatory routing).
Use an agent step when:
- The input is unstructured (PDFs, emails, free-text fields).
- The rules are too varied to enumerate (“classify this ticket” depends on phrasing the user picked).
- You can tolerate occasional imperfect output and have a fallback (human review, retry with a better model, escalate).
A common shape: agents for the cognitive work, automation for the deterministic work, humans for the judgement calls. A typical invoice flow uses all three.
Building an agent
Section titled “Building an agent”You build an agent from a single form on the Agents page — there’s no template gallery to pick from. You give it:
- a name and identifier,
- a model — the provider and model it calls, with an optional fallback model it cascades to if the primary fails,
- a system prompt — its durable instructions (a built-in prompt assistant can help you draft one),
- optional instructions and capabilities that shape how it behaves,
- and its tools — the connectors and MCP servers it may call.
Once it exists, you attach it to a process by binding it to a service task. A short dialog walks you through selecting the agent, mapping the step’s inputs, writing the task prompt, and configuring the output. See Create an agent for the full walkthrough.
Versioning
Section titled “Versioning”Agents are versioned. When an agent is working well, you publish a version — tagging it with a significance (major / minor / patch) and a changelog note. A process service task can pin a specific published version, so a running process’s behaviour can’t shift when someone edits the agent later. You can list an agent’s versions and roll back to an earlier one. See Version an agent.
Handling uncertainty
Section titled “Handling uncertainty”An agent can be wrong. You design around that with two patterns:
- Confidence routing. Have the agent include a per-field confidence score in its output schema. Vendor: “ACME Corp” (0.98). Amount: $12,345.67 (0.94). PO number: “PO-12345” (0.71). The process can then branch on the lowest score — high-confidence cases auto-route; low-confidence cases pull in a human via a task.
- Cross-check tools. The agent extracts a PO number. A subsequent step calls
lookup_po(po_number)against the ERP. If the PO doesn’t exist or its vendor doesn’t match the extracted vendor, the discrepancy triggers a human task. The agent does the cognitive work; deterministic checks catch its mistakes.
These patterns turn an agent’s occasional wrong answer from a silent error into a paused-for-review event. The user guide’s handling tasks page walks through what the human sees when this happens.
flowchart LR
A[Agent output] --> C{Confidence}
C -->|High| Auto([Auto-approve])
C -->|Low| Human[Human review task]
Cost and latency
Section titled “Cost and latency”Two trade-offs colour every agent decision:
- Cost per call. Bigger models cost more. A small model might handle 95% of invoices for cents apiece; the remaining 5% need a bigger model to read correctly. The agent’s fallback model supports a cascade: run the cheaper primary model, and fall back to a more capable one if the primary errors out.
- Latency per call. A typical model call is a few seconds. Multimodal calls (reading images or PDFs) are slower. Agents that call several tools sequentially compound the latency. For a process that runs in the background (an invoice flow that should complete within minutes), a few seconds per agent is fine. For a real-time interaction (a user is waiting on screen), you’ll feel it.
The Agents area tracks cost and latency over time. Use that to decide when to switch models or simplify prompts.
Limits
Section titled “Limits”A few things agents aren’t:
- Not a chatbot. Agents don’t carry a conversation. Each invocation is a one-shot call: input goes in, structured output comes out. If you want a chat experience, that’s a different product.
- Not deterministic. Two calls with the same input can return slightly different output. If you need exact reproducibility, an agent is the wrong tool.
- Not a replacement for business rules. “If amount > $10K, escalate” should live in a process gateway, not in an agent’s prompt. Encoding rules in prompts makes them hard to audit and easy to break.
The platform makes it easy to combine agents with everything else; the skill is knowing what to put inside the agent vs. outside.