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.

In One Sentence

An agentic workflow is a deterministic workflow shell with selected model-mediated decision points, where the runtime constrains, validates, executes, observes, and records what the model proposes.

The term covers more than one implementation. A model may classify an input and route it into a declared path. It may produce a bounded plan whose steps are validated against an allowed action set. It may choose which evidence to inspect next. It may draft a response for a human or a later deterministic step.

What makes the system an agentic workflow is not the presence of a model call. It is the placement of model choice inside a control loop that still has explicit boundaries.

The model can decide among possibilities. The workflow decides what possibilities exist, what state is authoritative, what may cause a side effect, and what evidence is required before the process advances.

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.

The Abstraction Shift: How Software Keeps Moving Up

A conventional workflow can be pictured as:

trigger → validate → state transition → activity → result → next state

The workflow definition determines the next state. If the process changes, an engineer or process owner changes the definition.

An agentic workflow inserts a bounded decision:

trigger → normalize → model proposal → policy and schema validation → allowed activity → verified result

The model can influence the next step, but only through a declared interface. It may choose a route, select a tool, produce a plan, or identify a missing field. The runtime translates that proposal into a controlled transition.

This is not a relaxation of orchestration into free-form autonomy. It is a relocation of flexibility. The workflow stops specifying every semantic interpretation, while continuing to specify the parts where ambiguity is operationally dangerous.

The resulting architecture has two kinds of logic:

• control logic: state, transitions, retries, timeouts, permissions, side effects, escalation, and release;
• interpretation logic: classification, extraction, ranking, planning, summarization, and selection among allowed options.

The model is strongest in the second category. The runtime must retain ownership of the first.

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

The model selects a plausible but incorrect workflow. Keep a fallback route, log the input and category, and measure route accuracy against downstream resolution rather than only label agreement.

Plan outside the action set

The model proposes an action that is not declared or combines allowed actions in an unsafe way. Reject the plan before execution and expose the reason in the trace.

Missing prerequisite

The model assumes that a record, approval, or field exists. Validate preconditions before the side effect and return the workflow to a recoverable state.

False success

The activity returns a successful HTTP response, but the intended business state did not change. Verify against the source of truth and record the evidence.

Duplicate side effect

The workflow retries after an uncertain timeout and performs the same write twice. Use idempotency keys, deduplication, and explicit reconciliation.

Unbounded fan-out

A planner creates too many subtasks or workers. Enforce maximum branches, depth, tokens, calls, elapsed time, and cost.

Context drift

The model receives a summary that no longer matches authoritative state. Rebuild context from durable records and include version or timestamp information where freshness matters.

Policy bypass

A model-generated route reaches a powerful tool because policy was checked only at the start. Enforce authorization at the side-effect boundary and on every privilege-changing transition.

Human approval fatigue

Too many low-value approvals train operators to click through. Reserve approval for meaningful risk boundaries and automate safe, reversible steps with evidence.

Workflow dead end

A model response cannot be parsed, a tool is unavailable, or the result is ambiguous. Every model step needs a retry, fallback, escalation, or stop state.

Replay divergence

Replaying a workflow invokes a model again and produces a different proposal. Record model outputs and version information when replay, audit, or debugging depends on the original decision.

Silent expansion

A workflow begins with a narrow goal and gradually acquires unrelated subtasks. Keep scope in durable state and require explicit reauthorization when the goal or resource boundary changes.

Autonomy mismatch

A low-consequence task receives a heavy agent loop, or a high-consequence task receives unreviewed autonomy. Choose the control loop by uncertainty and consequence, then revisit the choice with outcome data.

What Changes Because of It?

Architecture

The architecture gains a visible seam between orchestration and interpretation. Workflow engines become hosts for model steps, not just dispatchers for deterministic activities.

This seam should be explicit in diagrams, APIs, traces, and ownership. A model proposal should not look like an ordinary trusted function call.

Engineering

Engineers now design both the workflow and the model step:

• the state machine and the prompt;
• the activity contract and the output schema;
• the retry policy and the inference policy;
• the domain rules and the evaluator;
• the side effect and the verification query.

The right abstraction is often a small, testable model step inside a larger deterministic path. It is rarely a prompt that owns the whole process.

Product and UX

Products need to show uncertainty without exposing raw internal noise. Users should be able to see what the system inferred, what it plans to do, what it needs, and where they can intervene.

An approval surface is part of workflow design. So are progress, pause, resume, cancellation, and explanation of a blocked step.

Security and governance

The attack surface now includes model instructions, retrieved content, tool descriptions, workflow context, and intermediate artifacts. Policy needs to apply at the transition into a capability, not only at the outer request.

Auditors need to distinguish user intent, model proposal, policy decision, runtime execution, external result, and human approval.

Operations

Operations teams need traces that join workflow state with inference metadata. Useful dimensions include model version, prompt or policy version, input class, proposal, validation result, tool call, latency, token or call budget, retry count, and final outcome.

The goal is not to log every thought. It is to preserve the evidence needed to explain and recover an execution.

Business and economics

Agentic workflows can reduce manual interpretation, but model cost is now part of process economics. A route that saves one queue action but adds several long inference calls may not be an improvement.

Measure completed outcomes, human minutes, rework, escalations, latency, cost, and failure severity. Optimize the workflow, not just the model score.

Human organization

Ownership becomes more important, not less. Someone owns the workflow definition. Someone owns the model step. Someone owns the domain policy. Someone owns the source of truth. Someone can stop the process.

If those roles are unclear, autonomy hides an organizational gap behind an interface.

KNOW / UNDERSTAND / BUILD

KNOW

• A workflow is an explicit set of states, transitions, activities, and stopping behavior.
• An agent chooses or adapts its next step using model-mediated interpretation and environmental feedback.
• An agentic workflow combines both: deterministic orchestration around bounded model decisions.
• A model proposal is not a trusted state transition.
• Context is not authoritative state.
• The least autonomous control loop that handles the uncertainty is usually the best starting point.

UNDERSTAND

• Which inputs are structurally variable and which are semantically variable.
• Which decisions can be wrong without side effects and which decisions cross authority boundaries.
• Where schema validation ends and domain correctness begins.
• How retries, idempotency, compensation, and replay behave when model proposals vary.
• What evidence lets a human or system verify the outcome.
• How to choose among routing, bounded planning, evaluator and optimizer, orchestrator and workers, and open-ended agent loops.

BUILD

• A durable execution record with explicit task identity and state.
• A model step with a narrow input, declared output schema, bounded tools, and clear failure behavior.
• Policy and domain validation between proposal and side effect.
• Idempotent activities with timeouts, retries, cancellation, and compensation.
• Post-action verification against the source of truth.
• A meaningful approval or escalation state for consequential decisions.
• Traces that separate proposal, policy, execution, verification, and outcome.
• Evaluations that measure task completion, not only model output similarity.

Build It Once

When adding a model to a process, start with the deterministic shell:

1. Name the trigger, owner, scope, source of truth, and terminal outcomes.
2. Draw the states, transitions, side effects, retries, timeouts, and escalation paths.
3. Mark the steps where semantic variation creates the most manual work.
4. Insert one model step with one narrow responsibility.
5. Give it a constrained action or output vocabulary.
6. Validate its result independently before the workflow advances.
7. Run the model step in shadow mode or with reversible work first.
8. Add measurement for route quality, completion, rework, cost, latency, and human overrides.
9. Expand autonomy only when the evidence shows that the added flexibility improves the process.

This approach also makes replacement easier. A model can improve, a prompt can change, or a deterministic classifier can take over without rebuilding the workflow’s state and authority model.

The best agentic workflow is not the one with the most model decisions. It is the one that makes the right decisions flexible and the important consequences explicit.

Will This Term Survive?

Terminology durability: Exact phrase: MEDIUM. Underlying pattern: HIGH.

Agentic workflow is likely to remain useful because it names a real combination: workflow orchestration plus model-mediated choice. It may coexist with terms such as agentic process automation, intelligent automation, AI workflow, orchestration agent, and human-agent workflow.

The durable distinction is not the label. It is the boundary between a system that follows a declared path and a system that chooses parts of its path at runtime.

That boundary will move as models become more reliable and tools become more semantic. It should not disappear. Even a very capable model still needs an owner for state, authority, side effects, recovery, and release.

Where It Fits in the Map

Agentic workflow connects the series’ agent, tool, state, reasoning, and execution threads.

• Post 02, Agent and Agent Design Patterns: provides the control-loop vocabulary. Agentic workflow is the pattern where those loops are embedded inside explicit orchestration.
• Post 04, Tool Calling: supplies the proposal boundary. The model chooses among capabilities, but the runtime still validates and executes the call.
• Post 06, Context Engineering: explains how workflow state, task scope, tool descriptions, and observations become model context without replacing the source of truth.
• Post 08, Agent Memory: clarifies why durable workflow state and model memory have different lifetimes and authority.
• Post 09, Reasoning and Inference-Time Compute: supplies budgets, verification, and stopping rules for model steps that may think longer.
• Post 10, Deep Research: is an agentic workflow for investigation, with evidence state and synthesis as explicit process responsibilities.
• Post 11, Computer Use: demonstrates a high-variance execution adapter that benefits from the same policy, verification, checkpoint, and recovery shell.
• Future Post 13, Multi-Agent Systems: will ask when a workflow should delegate to multiple agents and when one agent with tools is simpler.
• Future Evals and Guardrails: will deepen the measurement and validation needed when a workflow contains probabilistic decisions.

The abstraction shift is not from workflows to agents. It is from workflows that encode every decision in advance to workflows that can delegate selected interpretations to a model while keeping execution semantics visible.

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.