Anatomy of an AI workflow

A prompt and a set of tools are not yet a business workflow.

A dependable workflow also defines how work begins, which information can be trusted, what the AI may change, where a person decides, what completion means, and what happens when something fails.

This article introduces eight practical concerns: trigger, context, tools, state, policy, approval, outcome, and history. The names are less important than the questions they answer.

Trigger: what created the responsibility?

A trigger may be a form submission, email, uploaded document, deadline, scheduled review, or direct request.

Its job is not merely to wake up software. It should create or identify one unit of work. An uploaded leave form, for example, might open one Form request connected to a patient and an employer.

Repeated triggers need a rule. A retried webhook should not create five copies of the same request. A new message might update an open case rather than open another one.

Business question: How will the team know whether this is new work, a repeat, or an update to work already in progress?

Context: what does the workflow need to know?

Context is the relevant, permitted information needed for the responsibility. It is not every piece of data the company owns.

Useful context can include:

• the target customer, case, or document;
• related records and recent activity;
• company policy;
• source documents;
• prior attempts;
• the actor’s role;
• and the actions currently available.

Source quality matters. A signed contract, a database record, an AI summary, and an unverified web page do not have equal authority. The workflow should preserve provenance so a reviewer can tell where an important answer came from.

Business question: Which facts are authoritative, and which information is only a suggestion or external reference?

Tools: what may the AI do?

A tool is a defined capability the agent can request. It may retrieve records, create a draft, update internal state, or act in another system.

A service agent may need to read one case, search approved knowledge, create a draft, and request approval. It does not need billing administration simply because billing tools exist elsewhere in the company.

Business question: What is the smallest set of capabilities that lets the agent complete its responsibility?

State: where is the work now?

State is the durable answer to “what has happened and what remains?”

A workflow might be:

• waiting for information;
• ready for AI review;
• holding a proposal;
• awaiting approval;
• executing an action;
• waiting for external confirmation;
• complete;
• or in an exception state.

State should survive a closed browser, a model timeout, or a three-day wait. It prevents the workflow from drafting the same document twice or repeating an external action after a retry.

Business question: If the process stops right now, can another person or system tell what to do next?

Policy: which rules must always hold?

Some decisions should not depend on how an AI interprets a prompt.

Amount limits, required roles, valid status changes, mandatory fields, data access, and prohibitions on external sending are good candidates for deterministic policy.

AI can contribute to routing decisions—such as suggesting that a case appears urgent—but uncertainty and consequence should determine whether the proposal can proceed automatically.

Business question: Which rules would you expect the system to enforce even if the AI misunderstood the instruction?

Approval: where must a person decide?

Approval should be a visible workflow state, not an informal message or a sentence buried in a prompt.

The reviewer needs the target, proposed effect, supporting evidence, uncertainty, and reason for review. Available decisions might include approve, reject, edit, request more information, or delegate.

If the proposal changes materially after approval, the earlier decision should no longer apply.

Business question: What information does a reviewer need to make a good decision quickly?

Outcome: what does complete mean?

Completion should describe a business result.

For a medical-form workflow, completion might mean that:

• supported fields were filled from the medical record;
• unsupported fields remain blank and flagged;
• clinical questions received the required review;
• and the final draft PDF is attached to the request.

The workflow also needs honest partial outcomes: waiting for a record, rejected by the reviewer, no qualifying match, or delivery failed.

Business question: What observable condition proves that the responsibility was completed?

History: can the work be explained?

The history should answer:

• what created the work;
• which sources were used;
• what the AI proposed;
• which tools ran;
• who reviewed or changed the result;
• which errors occurred;
• and whether the intended outcome was achieved.

This history helps with everyday operations, quality improvement, incident review, and recovery. It turns opinions about AI performance into evidence.

Business question: Could the team explain this result to a customer, manager, auditor, or future operator?

See the parts working together

Consider a new customer inquiry:

message received
      ↓
identity and duplicate rules check the source
      ↓
AI extracts the request and proposes a category
      ↓
runtime validates fields and selects an allowed path
      ↓
agent gathers permitted context and drafts a next step
      ↓
policy decides whether a person must approve
      ↓
approved action runs and records the external result
      ↓
workflow completes or opens an exception

Only the interpretive parts require AI. Identity matching, permission, approval, delivery confirmation, and history remain software responsibilities.

Design failure before increasing autonomy

Models can return unsupported output. APIs can time out. External actions can partially succeed. Reviewers can miss deadlines.

A production workflow should define retry limits, timeouts, duplicate protection, escalation, manual recovery, and what to do when the outcome is unknown.

Quietly stopping after an error leaves the business responsibility unresolved. A visible exception with an owner is far more useful than a hidden failure.