Orckai
Enterprise AI Workflow Automation: Building Processes That Run Unattended
The valuable automations are not the clever ones. They are the four-minute task somebody does two hundred times a week — read this, look that up, decide, type it somewhere else. Here is what has to be true before a workflow like that can run without anyone watching.
The pattern worth automating
Every organisation has a version of the same job. Something arrives — a file, an email, a form, a row in a table. A person reads it, works out what it is, looks something up in another system, decides, and types the result somewhere else. It takes four minutes and happens two hundred times a week.
Traditional automation could never touch this, because the reading and the working-out were the hard parts. Rules-based tools handled the structured 60% and escalated the rest, which is why so many RPA projects stalled at a partial win. A language model closes exactly that gap: it can read an unstructured document and produce a structured judgement.
What it cannot do is be reliable on its own. That is the actual subject of this article.
The reframe that helps: stop thinking of it as an AI project. Think of it as a workflow that happens to contain an AI step. The model handles interpretation; the workflow handles triggering, retries, branching, approvals, writing back, and recording what happened. Teams that get this order right ship; teams that start from the model spend months on prompts and never build the pipeline.
What has to be true before it is safe to run unattended
An automation that runs without a human watching needs six properties. Any one of them missing and you have a demonstration, not a process.
- It starts by itself. A schedule, a webhook, a file landing in a folder, a change in cloud storage — a workflow that needs someone to press a button has moved the work, not removed it.
- Failure is visible and retried. APIs time out and models occasionally return nonsense. Runs need bounded retries with backoff, and a failure that surfaces rather than disappearing.
- Uncertainty routes to a person. The model should be allowed to say it is unsure, and that path should be a designed branch rather than a wrong answer with a confident tone.
- High-consequence actions pause for approval. Reading and drafting can run free. Paying, deleting, and emailing a customer should wait for a human when the stakes justify it.
- Every run is reconstructable. Per-step inputs and outputs, the actor, the timestamp, tokens and cost. Without this you cannot debug it, and you certainly cannot defend it.
- Cost is bounded. A retry loop over a large batch can spend a great deal very quickly. Limits belong in the platform, not in a resolution to be careful.
The building blocks
Orckai's workflow engine exposes five trigger types and eight step types. The vocabulary matters less than the fact that it is small: most real processes are combinations of a handful of primitives, and the constraint keeps workflows legible to whoever inherits them.
| Step type | What it is for |
|---|---|
| Agent | Run a configured agent with its own system prompt, tools, and knowledge base — for anything needing reasoning across sources. |
| Inline prompt | A single direct model call for classification, extraction, or summarising, without setting up an agent. |
| MCP tool | Invoke a named tool on a generated connection to a database or API — permissioned, read-only by default, logged. |
| Condition | Branch on a value from an earlier step, including the model’s own confidence or classification. |
| Foreach | Iterate over an array — line items, records, results — with partial failures reported rather than swallowed. |
| Transform | Reshape data between steps: extract, merge, map, pick, join. Unglamorous, and most of what a real workflow does. |
| Code | Sandboxed JavaScript for logic that does not fit a step — no filesystem, no process, no arbitrary imports. |
| Action | Utility operations: send email, create a ticket, write a file, call an endpoint. Where the result lands. |
Execution runs through a Redis-backed queue with three retries and exponential backoff, so a transient failure in step four does not lose steps one through three. Variables pass between steps with {{ interpolation }}, and every run is stored with its per-step inputs and outputs for inspection, retry, or re-run.
Four processes that repay the effort quickly
Inbound document processing
A supplier invoice, a claim form, or a signed contract lands in a watched folder. The workflow extracts the structured fields, validates them against the purchase order in the ERP through an MCP tool, branches on whether the totals reconcile, and either posts it or routes the exception to a person with the discrepancy already explained. Note that a file-drop trigger fires once per file, so a folder of two hundred is two hundred independent runs — the folder is the loop.
The morning exception report
Someone currently opens three systems at 8am, compares them, and sends a summary. A scheduled workflow queries each through generated connections, has a model identify what changed and what looks wrong, and emails the summary before anyone arrives. This is the least glamorous and most reliably valuable pattern in the whole category.
Triage and routing
A webhook fires when a ticket, lead, or alert is created. An inline prompt classifies urgency and category; a condition routes it; an MCP tool enriches it with account history so the human who picks it up starts with context rather than a subject line.
Periodic reconciliation
Two systems that should agree, and quietly do not. A scheduled workflow pulls both, uses a foreach step to compare records, and produces a list of differences with a proposed resolution for each. The comparison is deterministic; the model's job is only to explain the discrepancy in terms a person can act on.
Governance, without a separate programme
Enterprise buyers ask three questions about any automation, and they are the right ones.
Who can change this? Workflows are organization-scoped objects under RBAC, so editing one is a permission, not a convention. What did it do? Every run is retained with per-step detail, and actions land in an audit log carrying the actor, IP address, and request id. What can it reach? An agent can only call tools you published on a generated connection — read-only unless you deliberately decided otherwise — so the blast radius is defined at design time rather than discovered later.
Cost gets the same treatment: usage is metered per organization with a visible balance and a hard stop, so a runaway loop is capped by the platform rather than by the invoice.
How to start without a six-month programme
- Pick a process someone already does badly. High volume, low variety, low consequence when wrong. Not the interesting one — the tedious one.
- Run it in shadow mode first. Let the workflow produce its answer and have the human continue as normal. Compare for a fortnight. You will learn where it fails, cheaply.
- Automate the confident path only. Route everything else to a person. A workflow that handles 70% cleanly beats one that handles 95% with occasional silent errors.
- Instrument before you scale. Failure rate, escalation rate, cost per run. Without those you are guessing about whether it is working.
- Expand along the same shape. The second process in a category takes a fraction of the first, because the connections and patterns already exist.
There are worked examples in five business operations you should automate, the foreach step guide for batch processing, and ten use cases for 2026.
Frequently Asked Questions
How is AI workflow automation different from RPA?
RPA follows deterministic rules and breaks on anything unstructured, which is why so many deployments handled the easy majority and escalated the rest. An AI step can read a document and produce a structured judgement, so the unstructured cases stop being exceptions. The surrounding engineering — triggers, retries, branching, audit — is much the same, and remains the part that determines whether it works.
What stops an AI workflow from doing something damaging?
Design, not trust. Tools are permissioned and read-only unless you deliberately allow writes; high-consequence actions sit behind an approval step; conditions route low-confidence cases to a human; and usage limits cap spend at the platform level. The agent can only call what you published, so the blast radius is fixed at design time.
What triggers can start a workflow?
Manual, schedule (cron), webhook with a secret and timing-safe comparison, file upload, and cloud storage change. Storage and file triggers fire once per file, so dropping two hundred files creates two hundred independent runs rather than one run over a list.
What happens when a step fails?
Execution runs through a Redis-backed queue with three retries and exponential backoff. Earlier successful steps are not lost, the failure is recorded with its inputs and outputs, and you can retry or re-run from the execution viewer. Partial failures inside a foreach step are reported rather than silently swallowed.
Can a human approve before an action is taken?
Yes. A workflow can pause for human input before continuing, which is the right pattern for anything that pays money, deletes data, or emails a customer. Reading, extracting, and drafting are usually safe to run unattended; committing an action often is not.
How do we keep costs predictable?
Usage is metered per organization with a visible balance and a hard stop when the allowance is exhausted, so a retry loop over a large batch cannot quietly run up a bill. You can also connect your own LLM key and pay your provider directly. Either way, measure cost per run early — it is the number that decides whether scaling up makes sense.