
Kurt FischmanFounder, Marshal
Kurt is the CEO of Marshal, a Managed AI Ops service built for small businesses. That means AI agents doing the work, leads coming from answer engines, and a team that keeps your business running at full speed.

Designing an agentic workflow means specifying five stages in order: intake (the trigger and the inputs), reasoning (the decision and its limits), action (what the agent may write and where), approval (which actions need a human first), and monitoring (how you know it still works). The popular design patterns all live inside the reasoning stage. Approval and monitoring are where most designs fail.
Designing an agentic workflow starts with five stages in order, intake, reasoning, action, approval, and monitoring, not with a choice of design pattern. The field tells you the opposite. We ran the probe ourselves, on the exact query, on June 8, 2026, and the design guidance was almost entirely a catalog of engineer-facing patterns and architectures: Vellum maps three levels of agentic architecture, output decisions, router decisions, and autonomous agents, while Weaviate frames the design around components and recurring patterns, LLM, tools, and memory. All of it is sound engineering and none of it tells an operator how to design the thing.
The patterns everyone designs around, router, reflection, orchestrator-worker, all live inside one of the five stages. Design the five stages and the pattern question shrinks to a footnote. This guide assumes you already know what an agentic workflow is; if you do not, start with what an agentic workflow is and come back. What follows is the design method: five stages, each with one question to answer, in an order that builds the workflow from the trigger that starts it to the monitoring that keeps it honest.
An agentic workflow design specifies five stages, intake, reasoning, action, approval, and monitoring, each answering one question and failing in one specific way if it is skipped. The table is the spine of the whole method; the rest of this guide is the two halves of it explained.
The five stages of an agentic workflow design, in order. Each stage answers one design question, and skipping any one of them leaves a predictable hole.
| Stage | The design question | What you decide | What breaks if skipped |
|---|---|---|---|
| Intake | What starts it and what does it see | The trigger and the inputs the agent reads | The agent acts on missing context |
| Reasoning | What does it decide and within what limits | The decision policy and its guardrails | The agent makes unbounded choices |
| Action | What may it write and to which systems | The tools and the permission scope | A wrong action hits the system of record |
| Approval | Which actions wait for a human | The confidence threshold and sign-off rule | High-stakes writes commit unchecked |
| Monitoring | How do you know it still works | The metrics, alerts, and exception queue | The workflow degrades silently for weeks |
Specify all five, in order. A design that names only intake, reasoning, and action is a demo; approval and monitoring are what make it a system.
Intake design fixes the trigger and the inputs the agent sees, and reasoning design fixes the decision it makes and the limits on that decision. Intake is the least glamorous stage and the one that quietly determines everything downstream, because an agent reasoning over the wrong inputs will reason confidently to the wrong answer. The design questions are concrete: what event starts this workflow, what data does the agent need to read to act well, and what is deliberately kept out of its view. Get intake wrong and no amount of clever reasoning recovers it.
Reasoning is the stage the rest of the internet calls "the design," and it is where the patterns belong. A router pattern decides which sub-task to run; reflection has the agent grade its own output; orchestrator-worker splits a job across specialists. Pick whichever the decision actually needs, but recognize that you are choosing the internals of one stage, not designing the workflow. The harder reasoning question is the guardrail: what is the agent explicitly not allowed to conclude, and what does it do when it is unsure. A reasoning design with no defined uncertainty behavior is a design that will improvise in production, which is the last place you want improvisation.
Action design fixes what the agent may write and where, approval design fixes which writes wait for a human, and monitoring design fixes how anyone knows the workflow still works. These three stages are where business workflows live or die, and they are exactly the stages the pattern catalogs wave at on the way to the next architecture diagram. Most design guides spend ten pages on the reasoning architecture and one sentence on who catches the workflow when it confidently does the wrong thing at scale.
Action design is permission scoping: the agent should be able to write exactly the records the job requires and nothing else, so a bug is a contained error rather than a company-wide one. Approval design is one decision per action: does writing this to the system of record need a human to click yes first, or is a confidence threshold and an audit log enough. Marshal runs that split through approval gates and exception queues, and designing it well is what lets a founder trust an agent with real systems. Monitoring design is the stage almost everyone forgets: an agent can drift, an integration can change, a model can regress, and none of it shows up unless the design included the metrics, the alerts, and the queue that surface a problem before a customer does.
Designing a lead-qualification workflow runs through the same five stages: intake the new lead, reason about fit, act by routing and writing back, approve the edge cases, and monitor the routing quality. Intake is the form submission plus the enrichment data the agent needs to judge fit. Reasoning is the qualification decision against a defined framework, with a clear rule for the ambiguous middle. Action is assigning the lead to the right rep and writing the score and reason back to the CRM. The design only gets serious at the last two stages.
Approval design here is deciding which leads route automatically and which land in an exception queue for a human, usually the partial-fit cases that a confidence threshold flags as uncertain. Monitoring design is tracking whether the agent's routing holds up, whether reps are overriding it, and whether the qualification quality drifts as the lead mix changes. The rep override rate is the single most useful monitoring signal here: when reps start re-routing a rising share of the agent's assignments by hand, the design has drifted and the reasoning stage needs attention before trust erodes further. Marshal builds exactly this as an agent for lead qualification and routing, and the part that makes it trustworthy is not the reasoning model. It is that the approval and monitoring stages were designed in from the start, not bolted on after the demo impressed someone.
Most agentic workflow designs fail by over-designing the reasoning stage and under-designing approval and monitoring, the two stages that decide whether anyone can trust the result. The failure looks the same every time: a workflow that demos beautifully, ships without a real approval rule or a monitoring plan, and then either acts wrongly with confidence or quietly stops working while everyone assumes it is fine. The reasoning was never the risk; the unwatched action was.
The fix is to design the five stages in order and refuse to skip the boring two. Every business will run on AI. Most will run on it badly, because they will design the clever part and neglect the parts that make it safe, then call the resulting incident a failure of the technology. The operators who win design approval and monitoring with the same care as reasoning, and they start with one workflow from the Marshal Agent Factory rather than trying to design the whole back office at once. A workflow designed across all five stages is one a business can actually hand the keys to.
Agentic workflows are complete business jobs that an AI agent owns from trigger to finished outcome, deciding the next step rather than following a fixed rule. Agentic workflows are the unit a business assigns, with the agent as the engine that completes the job. Designing one means specifying how that job runs across five stages: intake, reasoning, action, approval, and monitoring.
You design an agentic workflow by specifying five stages in order: intake, the trigger and inputs; reasoning, the decision and its limits; action, what the agent may write; approval, which actions need a human; and monitoring, how you know it still works. The design starts by naming the job, the trigger, and the done-state, then works through each stage in sequence. The popular design patterns are choices inside the reasoning stage, not the design itself.
The four stages of agentic AI usually named are perceive, reason, act, and learn, which map closely to an agentic workflow's intake, reasoning, action, and monitoring stages. The design framework in this guide adds a fifth, approval, because business workflows need an explicit human sign-off stage that a purely technical four-stage loop leaves out. For an operator, the approval stage is not optional, which is why the design uses five stages rather than four.
The components of an agentic workflow design are its five stages: intake defines the trigger and inputs, reasoning defines the decision and guardrails, action defines the permitted writes, approval defines the human sign-off, and monitoring defines the feedback loop. Underneath the reasoning stage sit the technical components other guides emphasize, the model, the tools, and the memory. The five stages are the design; the model and tools are how the reasoning stage is built.
The difference between agentic and non agentic workflows is that an agentic workflow reasons about what to do when the input varies, while a non agentic workflow follows a path fixed in advance. Designing an agentic workflow therefore requires the approval and monitoring stages, because a system that decides can decide wrongly, where a fixed automation only needs its rule checked once. The reasoning and approval stages are exactly what a non agentic design does not have.
ChatGPT on its own is not an agentic workflow; it is a language model that answers a prompt and stops, with no intake trigger, no action permissions, and no monitoring. ChatGPT becomes part of an agentic workflow only when it is placed inside the five stages, given a trigger, tools to act with, an approval rule, and a way to be monitored. The model is one component of the reasoning stage, not the workflow itself.
The most common mistake in designing agentic workflows is over-investing in the reasoning stage while treating approval and monitoring as afterthoughts. Other frequent design errors include skipping intake so the agent reasons over incomplete context, and scoping action permissions too broadly so a single bug can damage the system of record. A sound design specifies all five stages in order and gives the boring two, approval and monitoring, the same attention as the clever one.
Drive more awareness in answer engines. Transfer more work to machines. Build the operating structure that will keep you ahead of whatever comes next.