Technology

Workflows

Nobody builds a workflow by dragging boxes onto a canvas, any more than they write a contract by opening a blank document. You answer questions about how the work is actually done — and the graph is the record of your answers.

The questions are the ones a new colleague would ask on their first week. What sets this off? What should I read it against? Which systems am I allowed to touch, and what may I do with them? Who decides the things that need deciding, and when should I stop and come to you instead? Answer six of those and you have described a process that would otherwise have taken a fortnight to specify and a month to build.

The steps that need reading, weighing and writing up go to a digital employee rather than to a rule, because that is what they are: judgement, not logic. The steps that are genuinely a person's to make stay with the person, at a threshold you set. Everything else runs unattended — tested against a real case before it goes live, and keeping the reasoning behind every decision it takes.

It interviews you

What starts it, what it should read, which systems it may touch, who decides, when to stop and ask. Six questions is usually a whole process — and every answer becomes a node you can see, argue with and change.

A digital employee takes the judgement

The steps that need reading, weighing and writing up are given to a named colleague rather than to a rule. Ava scores the supplier against your policy and shows her working, so the decision can be reviewed like anyone else's.

It stops where you told it to

Over a threshold, or wherever the answer is genuinely unclear, the run pauses and waits for a person. The pause is designed in, not a failure — a workflow that never asks is one nobody can sign off.

Then it is nobody's job

Tested against a real case, put on a schedule, owned by a team, versioned. It runs unattended until something needs you — and tells you what it did while you were away.

Steps

Eight kinds of step

A workflow graph is not a flowchart of boxes that all mean the same. Every step is one of eight types, and the type decides what it may do, what it may reach and who is answerable for it.

That distinction is what makes a graph reviewable. Anyone can look at a run and see immediately which steps loaded data, which ran an agent, which branched and which required a person to say yes — without reading a line of configuration. It is also what makes a graph checkable before it ever runs: a data loader that sits after the step that needs it, or a branch that can fail with nowhere to fail to, is a mistake the shape itself gives away.

ManualTrigger

Someone starts the run, and their instruction comes with it.

On demand · one trigger per workflow

ScheduleTrigger

The run starts on a cadence instead of on a person.

Every 15 minutes · weekday mornings

DataSourceData loader

Fetches from a connector or a file. Always before the step that uses it.

Postgres · a screening API · an attached policy

AgentAgent executor

Does the work — the only type that runs an agent, and the only one that carries a digital employee as its assignee.

Document AI · Table AI · Chart AI · Q&A · Code

ConditionalRouter

Branches the flow — only where there are two ways out or more.

Complete? · in tolerance? · over the threshold?

TaskManual review gate

Pauses the run until a person approves what was produced.

Approve the draft · sign off the exception

FileFile output

Produces something downloadable instead.

PDF · DOCX · PPTX · CSV

Edges

Five ways a step connects

An unlabelled arrow says only “and then”, which is precisely the detail a process cannot afford to leave out. Every edge in a Scalata workflow carries a condition, and the condition is what the runtime actually follows.

Whether a step ran on, succeeded, failed, replied to something earlier or gave up and escalated to a person are five different obligations — and they are what an auditor, a regulator or a new joiner will ask about first. Naming them costs nothing at design time and is impossible to reconstruct afterwards from an arrow that only ever meant “and then”.

Plain sequence — the default, and most edges are this.

The step before it finished cleanly. Only out of a step that can fail.

It failed. Every branch that can succeed needs one of these or a fallback.

An agent hands its result back to a step earlier in the graph.

The automated path is exhausted — escalate it to a person.

Retries are not an edge. A step that can fail carries its own retry budget — how many times to re-run it, and how long to wait between attempts — and only when that is spent does the failure take the error or fallback path.

Knowledge graph

Everything it has learned, in one shape

Every run leaves something behind: a document read, a decision explained, a system touched, a person consulted. The knowledge graph is what those add up to — your organisation's work, and the links between the parts of it.

It is why the second workflow is easier to build than the first. A new one already knows which system holds your vendor master, which policy governs onboarding, who signs off above a threshold and what the last four exceptions turned out to be — because all of that was learned while doing the work rather than gathered in a discovery exercise.

And it is inspectable. You can search it, see what is connected to what, and follow any edge back to the run and the source that created it. A memory nobody can audit is a liability; this one is a record.