Some companies call a collection of cards, messages, and goodwill a workflow. It works right up to the first case that does not fit in the blue box.

TL;DR

A workflow is a working path that makes clear what comes in, who decides, what happens next, how one step moves to another, and what evidence proves the result. A process describes work that must exist; automation performs repeatable parts; an agent may choose steps within limits; a harness organizes context, permissions, validation, and interruption around those parts. The names vary among tools. The operational idea does not: without an owner, exception, transition criterion, and way back, automating a poorly understood process only makes chaos arrive faster.

I have watched many conversations about artificial intelligence (AI) start at the end.

“Can we automate it?”

Sometimes. But first comes a much less glamorous question: when someone makes a request, does anybody know what happens next?

Not “roughly.” Not “someone usually takes a look.” Not “there is a spreadsheet we update when we remember.”

What happens next, what data enters, who decides, how that decision is carried out, who checks it, where the result appears, and what remains as proof?

If those answers depend on organizational telepathy, you do not have a workflow. You have hope with steps.

And hope is a terrible integration tool.

Before choosing the tool, let us deflate five big words

There is no universal, perfect taxonomy — a system of classification — for these words. Every vendor arranges its slides as it sees fit; some call an automation with a model in the middle an agent. I will not pretend I found humanity’s final table.

For this article, these are working definitions:

• a process is recurring work that must produce a result: handling a request, approving a purchase, publishing a change;
• a workflow is that process’s operational route: states, owners, transition rules, exceptions, and evidence between beginning and end;
• automation performs predictable steps in that route through rules and integrations;
• an agent may select next steps and use tools inside a defined objective, scope, and permission set;
• a harness is the environment that organizes context, sources, tools, limits, validation, and approval points around all of it.

The more detailed map of those layers is in “AI is not one thing: model, agent, automation, and harness”.

Nothing on that list turns a tool into a manager, process owner, or person responsible for a loss. It only helps us choose the right component for each moment.

My editorial synthesis is simpler: a workflow is the verifiable agreement about what happens next. The tool comes after that agreement — if it comes at all.

A real flow starts before the “run” button

Think of a purchase, support, publishing, or system-access request. The drawing changes; the essential questions do not.

1. Request: what arrived, from whom, with what minimum information and for which objective?
2. Triage: is it complete, duplicated, in scope, or missing context?
3. Decision: who has authority, and which rule separates approval, refusal, return, or escalation?
4. Execution: which action changes the world — records, pays, publishes, grants access, sends a message?
5. Validation: how do we know the result matches the decision, rather than merely that a technical call returned “success”?
6. Publication or delivery: who receives the outcome, through which channel, and under which exposure limits?
7. Evidence: where does enough of a trail remain to explain the request, decision, action, and verification later?

This route does not need to be bureaucratic to exist. A simple request may cross it in minutes. But skipping the questions does not make complexity disappear. It merely returns later as rework, noise between teams, or somebody asking why the system did that at 6:47 p.m.

What belongs in a rule, automation, or AI

Not every step needs AI. That should be a relief, not a marketing defeat.

If a request can only move on with a number, owner, and mandatory document, an ordinary rule is better: predictable, cheap to test, and not required to interpret corporate poetry to notice an empty field.

If triage requires moving data between systems, sending a reminder, and opening a task for the right team, conventional automation may be enough. It performs a known route.

AI becomes useful when the input is less structured: summarizing long text, suggesting a category from natural language, locating discrepancies in documents, or preparing a recommendation for review. Even then, “useful” does not mean “authorized to decide everything.”

An agent may enter when it needs to observe results, choose among permitted tools, and adapt a sequence inside explicit limits. But the article on generic agents carries the warning: a job title does not contain a process. A “finance agent” does not receive your company’s rules, sources, exceptions, and authorities through divine inspiration.

Moment	Best starting point	What cannot stay implicit
Required data	rule	fields, format, and correction path
Repetition between systems	automation	trigger, idempotency — avoiding duplicates when the same action repeats — and technical failure
Ambiguous text or classification	AI as recommendation	source, expected confidence, and human review
Choosing among allowed actions	bounded agent	objective, tools, budget, stop condition, and escalation
A hard-to-reverse change	human decision or explicit approval	authority, impact, evidence, and rollback — a controlled return to a previous state

This is not a “more modern” scale. It is proportional choice. Using an agent to check three required fields is using a bazooka to kill a fly. The fly may fall. Maintaining the launcher is still your problem.

Transition criteria keep elegant limbo away

A workflow is not only a sequence of verbs. Every transition must answer: what lets it move from here to there?

“Triaged” may mean the fields exist, there is no duplicate, and the request belongs in that queue. “Approved” may mean the right person decided, inside known authority, with budget and evidence available. “Done” should mean the action happened and was validated, not merely that someone checked a box.

Without transition criteria, systems gain decorative states. Everyone can see “under review”; nobody knows whether it needs a document, a person, an integration, or courage to decide.

Exceptions need a place, too. An out-of-range amount, a restricted customer, one source contradicting another, an action that cannot be undone: these are not bugs in the drawing. They are part of real work.

A good escalation route says who receives the case, what information travels with it, and what stays forbidden while that person decides. “Send it to a human” without an owner, deadline, or context merely outsources ambiguity with a friendlier label.

Evidence is not bureaucracy; it is the ability to disagree later

When everything runs well, the trail looks unnecessary. When something goes wrong, it becomes the difference between investigating and improvising a story.

Terminal evidence — the record that closes a flow with reviewable proof — does not need to be a technical novel. It can be the request identifier, rule applied, approver, validation result, systems touched, and time. Enough to answer: “what happened, on what basis, and how did we check it?”

The AI Risk Management Framework from the U.S. National Institute of Standards and Technology (NIST) organizes AI risk management around activities such as governing, mapping, measuring, and managing. It is voluntary and broad; it does not hand you your company’s workflow or certify an automation. Its value here is smaller and more concrete: it requires responsibility, context, and measurement to be treated as part of the system, not as a footnote written after an incident.

For AI-supported systems, recording where a recommendation came from, which sources it used, and when human review happened helps avoid a common fantasy: treating a convincing answer as an explainable decision.

Reversibility is a question asked before regret

Some actions can fail and be repeated. Some can be redone by a person. Others change access, money, data, public communication, or production in a way that should not depend on “we will check the technical event records (logs).”

Before automating, I would ask:

• what is the worst effect if this runs twice?
• how do I stop an execution that is drifting off track?
• is there a preview, simulation, or approval before the effect?
• what exactly comes back with rollback, and what does not?
• what evidence must remain before undoing anything?

The piece on automation cleanup explores the same logic from disposal: calling something old is not enough; you need to know whether it is protected, who consumes it, and how to recover what matters.

Reversibility is not an excuse to act carelessly. It is room to experiment without turning every change into an irreversible bet.

Workflow comes before the beautiful future

There is an understandable temptation to draw the perfect operation first: an agent receives everything, understands everything, decides everything, and spends the day solving problems while the team drinks coffee looking at an immaculate dashboard.

Perhaps one day the presentation will look like that. Today, if nobody can explain the current route, automating the future only accelerates yesterday’s confusion.

Start with what already happens. Where does the request arrive? Where does it stall? Which decision stays human because it must, and which stays human merely because nobody has designed it properly yet? Which failure is acceptable? Who owns an exception? What proof would you need if the result were challenged?

At i-9.ai, this kind of discovery comes before a promise of autonomy. The goal is not to make a machine look busy. It is to turn scattered work into capacity that is clearer, governable, and verifiable.

Workflow is not a prison for operations.

It is what lets us improve the route without pretending the route does not exist.

A starter prompt to map before idealizing

If you already use an agent, chatbot, or automation tool, try starting here — without asking for a solution yet:

A prompt is the set of instructions given to the system. Here it starts the discovery; it does not replace it.

Act as a process analyst. Do not propose automation or AI before mapping the current workflow. Ask short questions and register, in a table: 1) trigger and requester; 2) minimum input information; 3) triage; 4) decisions and owners; 5) actions and systems involved; 6) transition criteria; 7) exceptions, deadlines, and escalation; 8) delivery validation; 9) evidence that must remain; 10) reversal or mitigation when something goes wrong. Distinguish observed facts, existing rules, hypotheses, and gaps. Do not invent steps. At the end, show the current flow first, then the risks, and only then proportional options for rules, automation, or AI, showing what needs a human decision.

The prompt does not discover the process alone. Nothing does. But it forces the conversation to start in the right place.

Before automation.

Before the agent.

Before hope with steps.

Further reading

• NIST AI Risk Management Framework: an official reference for AI risk management; it is not a universal workflow taxonomy or a security certificate.
• OpenAI — Building agents: engineering documentation about agents, tools, and oversight; it describes a product approach and does not replace local process design.
• Wikipedia — Workflow: an encyclopedic path into the general notion of workflows.
• Wikipedia — Idempotence: context for the property of repeating an operation without accumulating a new effect.
• Wikipedia — Rollback: context for the controlled return of a data or software change.

References and limits of use

• The NIST AI Risk Management Framework supports the point that AI risk management involves governance, context, and measurement across the lifecycle. It is voluntary and high-level; it does not prove that a particular workflow is adequate.
• OpenAI’s agent documentation supports the need for limits and oversight when building tool-using systems. It does not establish a universal definition of agent, workflow, or harness.
• The working definitions and the “hope with steps” thesis are this article’s editorial synthesis, not a classification attributed to the sources.