Agentic workflows examples: seven reusable control shapes

Key takeaways

• Start with a simple prompt and evaluation. Add a multi-step agent only when that approach falls short.
• Compare orchestration approaches by complexity, risk tolerance, scale, and runtime ownership.
• Inspect the control shape: who decides, who owns state, where review happens, and what stops execution.

What does an agentic workflow mean in practice?

An agentic workflow is a system in which an agent can perform work on a user's behalf with a high degree of independence. That independence comes from a loop, not from a single model response. An agent loop gathers context, takes an action, and updates its understanding. It continues until it reaches a goal or a stopping condition.

Consider the smallest useful loop:

1. The agent gathers the context available for the current step.
2. It takes an action within the tools and authority it has been given.
3. The result changes what the agent knows about the task.
4. The agent either continues toward the goal or reaches a stopping condition.

That mechanism is the practical meaning of an agentic workflow. The model may choose what to do inside the loop, while the surrounding system defines what it can see, what it can change, and when it must stop.

The control problem grows when several agents participate. AI agent orchestration coordinates multiple agents so they can work safely and predictably at scale. The orchestration layer adds shared context, governance, and execution control across those agents. It is therefore more than a way to pass messages. It determines how work moves, which state persists, and which execution rules apply.

The different types of agentic workflows sit on a continuum from deterministic chains to single-agent systems and multi-agent architectures. The right place on that continuum depends first on whether autonomy solves a real problem.

This continuum separates three kinds of control. A deterministic chain fixes the route. A single-agent system gives one agent room to gather context, act, and update its understanding. A multi-agent architecture adds coordination across agents. These are architectural choices, not labels for how impressive a system sounds.

The stopping condition belongs in the definition because the loop otherwise has no stated end. A goal can close the loop when the work is complete. A stopping condition can close it at a system boundary. In both cases, the harness needs to recognize that state and end the run.

How should you choose an agentic workflow framework?

The best agentic workflow framework depends on the workload. Begin with simple prompts and comprehensive evaluation, and add a multi-step agentic system only when that simpler approach falls short. If it does fall short, compare orchestration approaches with the three gates below.

Use this workflow-to-agent escalation test before comparing frameworks:

Agentic workflows examples by control shape

Useful agentic workflows examples expose the decisions beneath the task label. A "research agent" description says little about planning, state, review, or stopping. These seven Execution Cards show what each pattern controls and what remains implementation-defined.

Execution Card 1: deterministic development rollout

• Trigger and context: A long-running rollout needs an audit trail and traceable progress.
• Decision freedom and owner: Codex MCP owns the deterministic path. Specialized agents may work in parallel.
• Tools and state: Codex MCP provides execution, with rollout progress kept traceable.
• Verification checkpoint and human boundary: Gating logic validates artifacts produced by specialized agents. Any human approval point is implementation-defined.
• Failure mode and recovery path: Artifact validation is the boundary. Failure handling and recovery are implementation-defined.

Execution Card 2: internal-agent summarization

• Trigger and context: The executor needs a summary and supplies summarization instructions.
• Decision freedom and owner: A SummarizerExecutor creates an internal Agent to follow those instructions.
• Tools and state: The tool set and persistent state are implementation-defined.
• Verification checkpoint and human boundary: Both are implementation-defined.
• Failure mode and recovery path: Summary rejection and resumption controls are implementation-defined.

Execution Card 3: plan-first delegation

• Trigger and context: The orchestrator describes available agents and their capabilities to an LLM.
• Decision freedom and owner: The LLM produces a roadmap, then the orchestrator delegates the work.
• Tools and state: Agent capabilities are the planning context. The pattern does not prescribe a tool set or persistent state.
• Verification checkpoint and human boundary: Both are implementation-defined.
• Failure mode and recovery path: Roadmap failure detection and repair are implementation-defined.

Execution Card 4: routing

• Trigger and context: The agent receives input that needs a processing path.
• Decision freedom and owner: The routing agent decides how to process the information, how to respond, and whether to use a tool or sub-agent.
• Tools and state: Tools and sub-agents are destinations. Persistent route state is implementation-defined.
• Verification checkpoint and human boundary: Both are implementation-defined.
• Failure mode and recovery path: Destination failure handling and recovery are implementation-defined.

Execution Card 5: evaluator-reviser loop

• Trigger and context: The loop takes behavioral traces, human judgment, evaluations, ranked harness changes, and implementation as inputs.
• Decision freedom and owner: Agents review, critique, and revise outputs. The improvement loop owns the repeated pass.
• Tools and state: Traces and evaluation results carry information between passes. Tools are implementation-defined.
• Verification checkpoint and human boundary: Evaluations provide a checkpoint, and human judgment can enter the improvement loop.
• Failure mode and recovery path: An execution cap prevents an infinite feedback loop. Post-cap recovery is implementation-defined.

Execution Card 6: Amazon Bedrock human checkpoint

• Trigger and context: The checkpoint occurs before a specific action runs, with its parameters and any added context.
• Decision freedom and owner: With user confirmation, the user can approve or reject the action. With return of control, the user can modify parameters or provide more context before execution.
• Tools and state: Amazon Bedrock Agents carries the pending action and returned inputs.
• Verification checkpoint and human boundary: The user decision is the checkpoint, placed before execution.
• Failure mode and recovery path: Rejection prevents that action from executing. Return of control provides the recovery path for changed parameters or additional context.

Execution Card 7: multi-agent handoff

• Trigger and context: A goal is decomposed into role-specific tasks, coordinated through messages, shared state, or events.
• Decision freedom and owner: Specialized agents execute their assigned work. The orchestrator owns planning, dependencies, state, retries, review, and audit.
• Tools and state: In a multi-agent research workflow, triage, clarification, instruction, and research agents can use web search and MCP. Interaction may be sequential, parallel, or iterative.
• Verification checkpoint and human boundary: Results are reconciled, and unresolved conflicts go to review. A specifically human review point is implementation-defined.
• Failure mode and recovery path: Conflicting results are the named failure. Reconciliation handles resolvable differences, while unresolved conflicts move to review.

Diagram states and specify the checkpoint contract

An agentic workflow diagram should show both the visible route and the state required to resume it. LangGraph's graph structure offers an explicit visual model of states and transitions for workflows with routing logic.

The diagram makes routing legible, but a resumable system also needs a checkpoint contract. To replace event replay fully, the checkpoint must carry or recover:

• each completed node's output;
• the run ID;
• the active branch; and
• a version marker that lets a paused run resume through a compatible code path after code changes.

Checkpoint payloads can remain portable across persistence backends when their data is JSON-serializable. Node objects can then be rebound from the in-memory graph definition. The resumability architecture joins those requirements: recoverable node output, run identity, branch position, version compatibility, portable payloads, and node rebinding.

This is the difference between a diagram that explains the happy path and one that helps define recovery. The state labels show where work can move. The checkpoint contract says what must survive when that movement is interrupted.

Versioning and portability answer different recovery questions. The version marker directs a paused run through a compatible code path after the code changes. JSON-serializable data and node rebinding let the checkpoint payload remain portable across persistence backends. A useful diagram places the pause point beside the state transition, while the contract records the data needed to continue.

Resume is a data problem

A run ID identifies the run being resumed. Completed-node outputs preserve work that has already finished, and the saved branch identifies the route that was active. Together, those fields let a checkpoint carry or recover the state required to replace event replay fully.

Code changes add another condition. The checkpoint's version marker must direct the paused run through a compatible code path. Storage changes ask a different question: whether the payload can move across persistence backends. JSON-serializable data supports that portability, while node objects are rebound from the graph definition held in memory.

How should agentic workflow tools and context be designed?

Treat the agent-computer interface as an engineered surface. It needs thorough tool documentation and testing, because the agent acts through the definitions and responses that interface provides.

Context needs equal restraint. Context engineering should seek the smallest set of high-signal tokens that maximizes the likelihood of the desired outcome. More connected systems can create more context without making it more useful.

MCP shows the tradeoff clearly. When too many MCP servers are connected, their tool definitions and results can consume excessive tokens and reduce agent efficiency. Code execution gives the agent familiar programming constructs for interacting with MCP servers more efficiently. The choice is not merely how many tools are available. It is how their definitions, results, and interaction method shape the context the agent must process.

For an agentic workflow tools review, inspect the interface as part of the harness:

• Is each tool documented for agent use?
• Has the interface been tested?
• Does the context contain a small, high-signal token set?
• Are connected MCP definitions and results consuming excessive tokens?
• Would code execution make interaction with those servers more efficient?

The code execution with MCP pattern does not remove the need to design context. It changes how the agent interacts with connected servers. Tool definitions and returned results still belong in the system's context and evaluation decisions.

Separate tool availability from context load

An MCP connection contributes tool definitions and results to the context the agent processes. When many servers are connected, that material can consume excessive tokens and reduce efficiency. Code execution changes the interaction surface by letting the agent use familiar programming constructs with those servers. It does not change the aim of context engineering: retain the smallest high-signal token set that improves the likelihood of the desired result.

Tool authority needs role boundaries and evaluations

Tool quality directly affects agent effectiveness, so tools should be developed alongside evaluations. The evaluation work tests the same interface through which the agent sees options and takes action.

Authority is a separate control. Agents can choose tools to complete tasks, while restricting tool access by role improves safety and reliability. A generator, validator, and orchestrator do not need identical action surfaces simply because they participate in the same workflow. Role-based access can limit each agent to the tools assigned to that role.

Put the two controls together. Role boundaries limit the actions available to an agent. Evaluations test the quality of the tools the role can use. This pairing keeps tool choice inside an explicit permission surface instead of treating every connected tool as universally available.

The boundary matters because agent workflows carry prompt-injection and data-leakage risks. Tool access, context, and evaluation are all parts of the system around the model.

Tool selection and tool authority should remain visible as separate fields. The agent can choose a tool for the task from the set available to its role. The role restriction determines which tools enter that set. Evaluations then develop alongside those tools, so the interface and its assessment remain connected during development.

This design can be written without a broad job title. Name the role, list its available tools, and attach the relevant evaluations to that toolset. When another role requires a different action surface, give it a different access set. Role-based restrictions improve safety and reliability while preserving agent choice inside the assigned boundary.

How do you write an agentic workflow?

Write the control system before polishing the prompt. An agentic workflow tutorial starts by making the agent's planning steps explicit. Then define how work is decomposed, who owns each role, and what stops execution.

Use this specification as the first draft of the harness:

1. Expose planning. Record the planning steps the agent uses so the design does not hide its roadmap.
2. Choose a decomposition mode. Break the problem into manageable tasks statically, dynamically, or through a mixture of both.
3. Assign roles where they help. Common specialized roles include generators, validators, and orchestrators, tailored to the domain.
4. Set an execution cap. Define the limit on how much execution the workflow can perform.
5. Set retry limits. Bound repeated attempts instead of leaving retries open-ended.
6. Monitor token usage. Track the tokens consumed during production execution.
7. Configure a cost threshold. Alert a human when cost exceeds that threshold.

Those controls form a concrete workflow specification: visible planning steps, a decomposition mode, assigned roles, an execution cap, retry limits, token monitoring, and a configurable cost alert. Production orchestrators should carry those limits and alerts into execution.

The decomposition choice can remain explicit without being fixed forever. A static plan defines manageable tasks before execution. Dynamic decomposition lets tasks be formed during the work. A mixed design can use both. The workflow specification should name which mode applies so the visible planning steps match the intended form of decomposition.

Roles should be just as legible. Generators, validators, and orchestrators are common role types, and each role can be tailored to the domain. Once roles are named, their tool access can be restricted by role instead of exposing the same action surface to every agent.

An evaluator-reviser loop needs the same discipline. Feedback loops let agents review, critique, and iteratively improve outputs, but the loop requires a cap to prevent infinite execution. Human judgment and evaluations can also feed an improvement loop that connects behavioral traces, ranked harness changes, and implementation.

Keep security in the design as well. Agent workflows carry prompt-injection and data-leakage risks. Role-based tool access limits available actions, while caps and retry limits bound execution. Neither control replaces tool evaluation or clear planning.

Apply the workflow-to-agent escalation test to one task before adding another agent. If the task clears that gate, use our guide to building agentic workflows to work through stop, resume, and recovery mechanics.