Agentic Workflow

Where Workflows Should Stay Deterministic

A workflow is an agreement about what happens next. It names the steps, the transitions, the data passed between them, the retries, the timeouts, and the conditions under which work stops or escalates.

An agent is useful when the next step cannot be known in advance. It can interpret a request, choose a tool, make a plan, inspect the result, and adapt. Its flexibility comes from not having every path written down ahead of time.

Those descriptions are often treated as opposites. In production, they are usually parts of the same system.

An agentic workflow puts model-mediated decisions inside an explicit orchestration boundary. The workflow remains responsible for identity, state, side effects, retries, budgets, authorization, observability, and release. The model handles a bounded part of the work where language, ambiguity, or open-ended decomposition makes a fixed path expensive or brittle.

The important design question is not whether a system is a workflow or an agent. It is which decisions are allowed to remain probabilistic, and which decisions must stay deterministic because they carry authority or irreversible consequences.

This is Post 12 in The Abstraction Shift: How Software Keeps Moving Up.

Why This Exists

Traditional workflows work best when the path is known:

• receive an event;
• validate its schema;
• call a service;
• wait for a callback;
• update a record;
• notify an owner;
• stop or retry.

The path may be long, distributed, and failure-prone, but it is still expressible as states and transitions. A workflow engine can persist progress, retry activities, wait for time, fan out work, join results, and expose an execution history.

Real work also contains steps that resist a fixed contract:

• classify an email written in an unfamiliar way;
• extract fields from documents with different layouts;
• decide which of several investigations is relevant;
• identify which missing information would unblock a case;
• break an underspecified request into a small set of useful subtasks;
• draft a response that a person can review.

Before models, teams handled this gap with rules, decision tables, queues for manual review, and increasingly large collections of exception paths. Those mechanisms remain valuable. They become expensive when the variation is semantic rather than structural.

The model is a candidate interpreter for that semantic variation. It is not automatically a replacement for the process that surrounds it.

The practical reason to combine them is simple: workflows provide control and recoverability, while models provide flexible interpretation and bounded search.

What We Did Before

Batch jobs and schedulers

The earliest business automation was often a scheduled sequence: run at a particular time, read inputs, transform them, write outputs, and report a status.

Schedulers made time explicit. They also made the boundaries of responsibility clear. A job either ran or did not run. A later job could depend on an earlier artifact. Failure handling was often coarse, but the path was understandable.

Agentic workflows inherit the need for trigger identity, execution history, reruns, and operational ownership. The model does not remove the question of which run owns which output.

State machines and workflow engines

A state machine represents a process as named states and transitions. Workflow engines extend the idea across durable execution, external services, timers, retries, callbacks, parallel branches, and human tasks.

The representation may be code, JSON, a visual graph, or a process notation. The common promise is that the path is explicit enough to execute, inspect, and recover.

This lineage matters because “agentic” systems are still stateful systems. A model suggestion is not a substitute for an execution state. If a workflow cannot say whether a side effect happened, whether a retry is safe, or what information is authoritative, adding a model usually increases the ambiguity.

Business process management

Business process management made organizational work visible as a process that could be modeled, assigned, monitored, and improved. BPMN gave business and technical stakeholders a shared notation for process diagrams and execution-oriented semantics.

The notation is not the point. The point is that a workflow is also an organizational contract. It encodes who owns a step, which handoff is allowed, which exception needs attention, and what evidence lets the process continue.

Agentic workflows add a new kind of participant. A model may interpret an artifact or propose a route, but it should not silently become the owner of a business decision.

Queues, workers, and event-driven systems

Queues separated producers from consumers. Worker pools separated the request to do work from the process that eventually did it. Events made state changes visible to other parts of a system.

These patterns already dealt with delayed execution, duplicate delivery, backpressure, concurrency, and partial failure. Agentic workflows add variable latency and variable work selection, which makes budgets, cancellation, and observability even more important.

Rules and decision tables

Rule engines made decisions explicit as conditions and outcomes. Decision tables allowed domain experts to inspect combinations of facts and expected actions.

Models can cover cases that are difficult to enumerate, but their decisions are harder to inspect as a complete table. A useful hybrid often uses the model to normalize or classify messy input, then applies deterministic rules to the normalized result.

The old systems were not primitive versions of agents. They solved a different problem: making decision authority explicit. That responsibility remains.

The shift is not from workflow to no workflow. It is from a fully specified path to a deterministic shell with selected model-mediated decisions.

What Counts as an Agentic Workflow?

The label is useful only if it distinguishes architecture. A model call in a pipeline is not automatically an agentic workflow. Neither is a prompt with the word “agent” in it.

An agentic workflow usually has these properties:

• a durable task or execution identity;
• a workflow-defined outer boundary;
• one or more model-mediated decisions;
• a declared set of tools, routes, or outputs the model may choose from;
• validation before a proposal changes authoritative state;
• feedback from the environment or from a verifier;
• stopping conditions, budgets, and escalation;
• a trace that separates model proposal from runtime action.

The main forms include:

Routing

A model classifies an input and selects one of several known paths. The workflow owns the paths; the model supplies the classification.

This is a good fit when categories are distinct and the cost of a wrong route is manageable or reviewable. It is a poor fit when a classification silently grants authority.

Bounded planning

A model turns a goal into a plan from a constrained vocabulary. The runtime checks the plan for allowed steps, maximum length, required fields, and dependencies before execution.

This is more flexible than a fixed chain, but it is not an invitation to invent new capabilities. The plan is an untrusted proposal until it passes validation.

Evaluator and optimizer

One model step produces an artifact and another evaluates it against explicit criteria. The workflow decides whether to accept, revise, escalate, or stop.

The value comes from making improvement observable. Without a measurable evaluation boundary, the loop can spend more time restating the same weakness.

Orchestrator and workers

A model decomposes a task into subtasks and the runtime dispatches them to workers. This can help when the number or shape of subtasks depends on the input.

The boundary must remain explicit: worker identity, concurrency, maximum fan-out, aggregation rules, failure handling, and the authority of the final result.

Open-ended agent loop

The model chooses the next tool or action over multiple turns, using observations to continue. This is the most flexible shape and the hardest to bound.

It belongs inside a workflow whenever the work has a meaningful start, checkpoint, budget, owner, or release decision. Calling the loop an agent does not remove those requirements.

The Deterministic Core

The deterministic core is not the part that never changes. It is the part whose behavior must be explicit enough to operate, test, authorize, and recover.

Trigger and identity

Every execution needs a task identity, a caller or owner, a scope, and a source event. The model should not have to infer which customer, account, environment, or workflow run it is acting for.

Durable state

The runtime needs an authoritative record of what has happened:

• which inputs were accepted;
• which model proposals were made;
• which proposals passed validation;
• which activities started and finished;
• which side effects were committed;
• which human decisions were recorded;
• which state is safe to resume from.

Conversation history and model context may help the next inference. They are not automatically the source of truth.

Side-effect boundaries

Reading, proposing, validating, and changing the world are different operations. The workflow should make the transition visible.

A model may propose “refund order 1842.” A policy layer should check identity, eligibility, amount, and approval requirements. A deterministic activity should perform the refund with an idempotency key. The workflow should record the result from the payment system.

Retry, timeout, and cancellation

Models introduce variable latency and may produce different proposals on retries. That does not change the need for ordinary execution semantics.

The runtime needs to decide what can retry, how many times, with what backoff, under which timeout, and what happens when a user cancels the task. A retry of a read is not the same as a retry of a payment or a notification.

Approval and escalation

Some work should pause when a proposal crosses a risk boundary. The workflow should represent the pause as state, not as an instruction hidden inside a prompt.

An approval step should show the decision owner the relevant facts, the proposed action, the scope of authority, and the evidence needed to approve. “Human in the loop” is meaningful only when the human can understand and change the outcome.

Observability and replay

The trace needs at least two layers:

• what the model saw and proposed;
• what the runtime allowed, executed, observed, and recorded.

Those layers answer different debugging questions. A model may have proposed the wrong route. The policy may have rejected a correct route. The activity may have failed after approval. The verifier may have missed a false success.

The model can propose a route or a plan. The workflow runtime still owns what may execute, what state changes, and what result is released.

Where the Model Belongs

The model belongs where the input is semantically variable and the output can be constrained, checked, or reviewed.

Classification

Use the model to map messy language into a declared set of categories. Keep the categories, fallbacks, and consequences outside the model.

For a support workflow, the model may classify a request as billing, access, technical issue, or unclear. The workflow can route each class to a known process. An unclear result can go to a human instead of being forced into the nearest category.

Extraction

Use the model to extract fields from documents, messages, or screens when the presentation varies. Validate types, required fields, cross-field constraints, and source spans before the fields become authoritative.

Extraction is often a particularly useful hybrid because the model handles language and the runtime handles the data contract.

Bounded planning

Use the model to select a small sequence from a known set of actions. Set limits on step count, tool scope, nesting, cost, and elapsed time. Reject plans that contain unknown actions, missing arguments, impossible dependencies, or disallowed combinations.

Tool and evidence selection

Use the model to choose which declared tool, document, or investigation branch is most relevant. The runtime should still enforce access, budgets, retention, and the maximum search or execution surface.

Drafting and transformation

Use the model to produce a draft, explanation, or normalized representation that a later deterministic step can validate or a human can review.

The model is often best treated as a compiler from ambiguous input to a structured proposal. The runtime is the interpreter that decides whether the proposal is legal and what it means operationally.

What Should Stay Deterministic?

The answer depends on consequence, not on whether a model could technically do the task.

Keep these responsibilities deterministic whenever they matter to correctness or authority:

• authentication and identity binding;
• authorization and policy evaluation;
• schema validation and type checking;
• state transitions and source-of-truth updates;
• financial, legal, or safety-critical side effects;
• idempotency keys and duplicate handling;
• retries, timeouts, cancellation, and compensation;
• concurrency limits and resource budgets;
• evidence retention and audit records;
• release, publication, and external notification;
• escalation and human decision ownership.

This does not mean every rule must be hand-coded forever. A model can help propose a rule, explain an exception, or identify a candidate policy. The enforcement point should remain inspectable and independently testable.

Choosing the Control Loop

There is a natural temptation to make every workflow more autonomous. More autonomy is not automatically more useful. It often means more latency, cost, variance, and failure surface.

Start with the task’s uncertainty and consequence:

• If the path is known and the inputs are structured, use a fixed workflow.
• If the path is known but inputs are messy, use a workflow with model-assisted normalization or classification.
• If the goal is clear but the number of subtasks varies, use bounded planning or orchestrator and workers.
• If the task is open-ended and the environment provides useful feedback, use an agent loop inside an explicit budget and checkpoint structure.
• If the consequence is high and correctness is hard to verify, keep the model advisory and require human ownership.

The question is not “Can the model do this?” It is “What is the least autonomous control loop that handles the uncertainty while preserving the required evidence and authority?”

Choose the least autonomous control loop that can handle the uncertainty. Open-ended autonomy is a last resort, not the default.

Where the Analogy Breaks

Agentic workflows resemble old workflow systems, but several differences matter.

A model proposal is not a transition

A transition changes the execution state. A model output describes what might happen next. It becomes a transition only after parsing, validation, authorization, and execution.

Treating proposal as state creates false history. The log says the system “decided” to send an email, while no email was sent or the wrong email was sent.

A plan is not a contract

A workflow definition is intended to be executable. A model-generated plan is an interpretation of a goal. It may omit a prerequisite, invent a dependency, or use an action in an unsafe order.

The plan needs a contract before it enters the execution path.

Retries can change meaning

Traditional retries are already difficult, but models add another source of variation. A replay may produce a different classification or plan. Re-running the same proposal may also produce a duplicate side effect.

Separate deterministic workflow replay from model inference. Cache, pin, or record the model result when reproducibility matters. Give side effects idempotency and explicit compensation.

Validation may only check shape

Valid JSON is not a valid business decision. A plan with the right fields can still select the wrong account, rely on stale evidence, or cross a policy boundary.

Use layered validation: schema, authorization, domain rules, environmental preconditions, and post-action verification.

A human checkpoint can become theatre

If the person sees only “Approve suggested action?” with no context, the workflow has moved responsibility without enabling judgement. If the system proceeds automatically after a timeout, the approval may be ceremonial.

The checkpoint needs a clear owner, a meaningful representation of the proposed change, and a defined behavior for approve, reject, defer, and timeout.

More decomposition is not always better

A model can split a small task into many subtasks, increasing coordination and cost without improving the result. Every worker adds state, communication, retries, and aggregation.

The workflow should have a maximum fan-out and a reason for each additional branch.

Context is not state

The model may receive a summary of prior steps, but summaries can omit a failure, blur authority, or preserve a stale assumption. Keep authoritative state outside the context window and reconstruct the model’s working context from it.

Flexible paths are harder to evaluate

A fixed workflow has a relatively clear set of paths. An agentic workflow can produce many valid and invalid trajectories. Testing therefore needs scenario coverage, property checks, policy tests, traces, and outcome evaluation rather than only snapshot comparisons.

Under the Hood

A production agentic workflow can be described as eight stages:

1. Intake

Accept the trigger, authenticate the caller, assign an execution identity, and record the initial scope.

2. Normalize

Convert the request into a stable task representation. This can include structured fields, retrieved context, relevant history, and explicit exclusions.

3. Select a model step

The workflow decides whether model interpretation is needed. It selects the prompt, tools, model class, budget, and output schema for that step.

4. Propose

The model returns a classification, extraction, route, plan, draft, or next action. The result is untrusted until the next stages complete.

5. Validate and authorize

The runtime parses the result, checks schema and domain constraints, evaluates policy, and decides whether human approval is required.

6. Execute

Deterministic activities perform the allowed work. Side effects receive identity, idempotency, timeout, and tracing information from the workflow.

7. Verify

The system checks the result against the environment or source of truth. A successful tool response is evidence of a call, not always evidence that the intended business outcome occurred.

8. Record and continue

Persist the proposal, decision, activity result, verification evidence, and next state. Continue, retry, compensate, escalate, or complete.

The model sits in stage 4. The system around it carries most of the operational responsibility.

A Concrete Example

Consider an insurance claim intake process.

The deterministic shell can:

• receive the claim and bind it to a policyholder;
• store the original documents;
• check for duplicate claim identifiers;
• look up policy and coverage records;
• create a claim case;
• require approval for settlement;
• send a notice;
• record every state transition.

The model can:

• extract incident date, location, parties, and described damage;
• classify the claim into a declared intake category;
• identify missing documents;
• suggest which specialist queue should review the case;
• draft a request for additional information.

The model should not silently:

• decide that coverage exists;
• change the policy record;
• authorize a payment;
• close a claim as fraudulent;
• notify a regulator;
• treat an unverified extraction as a source-of-truth field.

Those outcomes may use model-produced evidence, but they need deterministic checks and the appropriate decision owner.

The workflow can become more useful without becoming less accountable. It removes repetitive interpretation from the human queue while keeping the authority boundary legible.

Failure Modes

Wrong route or incomplete prerequisite

The model selects a path that looks plausible but lacks required state. Validate prerequisites before execution.

Plan outside the action set

A proposed plan assumes capabilities the workflow does not expose. Constrain planning to explicit tools, state, and authority.

False success or duplicate side effect

The workflow reports completion without verified state or repeats an operation after uncertainty. Use idempotency and source-of-truth checks.

Unbounded fan-out and context drift

Flexible decomposition creates uncontrolled work or loses the original contract. Bound parallelism, context, time, and cost.

Approval fatigue and policy bypass

Too many low-value approvals train reviewers to accept blindly, while alternate paths bypass policy. Put approval at the consequential boundary and test all paths.

Replay divergence and dead ends

A retry or resume follows a different path without a clear recovery rule. Record durable state, decisions, and stop reasons.

Sources

• Building effective agents, Anthropic: distinguishes predefined workflows from agents that dynamically direct their own processes, and describes routing, bounded composition, evaluator loops, orchestrator and workers, and agent control loops.
• Learn about state machines in Step Functions, AWS: documents workflows as state machines with explicit states, transitions, input and output, service integrations, execution history, and terminal behavior.
• Business Process Model and Notation, Object Management Group: describes BPMN as a shared graphical notation for specifying business processes across business, implementation, and management stakeholders.
• Temporal Platform Documentation: documents durable workflow execution and resumption across crashes, failures, and long-running process boundaries.
• AWS Step Functions Documentation: provides the broader workflow orchestration and state-machine context for distributed applications.