Agentic Workflow: Stages, Patterns & Examples

An agentic workflow is a goal-directed process in which one or more LLM agents plan a course of action, take steps through tools, observe what happened, and iterate until the goal is met. The defining trait is the loop: the agent is not executing a script someone wrote in advance, it is choosing its next action from what it just observed. A human sets the goal and approves at checkpoints; the agent works out the how.

Two properties separate this from everything that came before it. First, tool use: an agentic workflow acts on the world, it edits a file, runs a test, queries a database, opens a pull request, rather than only producing text. Second, iteration on feedback: it reads the result of an action and decides the next one, so a failed test becomes a fix attempt rather than a dead end. Take away the tools and you have a chatbot; take away the loop and you have a one-shot generator. An agentic workflow needs both.

The clearest way to pin the definition is by contrast. An agentic workflow is not the same as traditional automation, and it is not the same as a single prompt-and-reply, and it fails differently from both.

RPA replays recorded steps and shatters the moment a button moves; a single chatbot reply reasons but cannot act or self-correct. An agentic workflow reasons and acts and loops, which is why it handles novelty the other two cannot, and also why it can fail in ways they cannot: an unbounded loop, a confidently wrong action taken and never checked. Flexibility is bought with the need for guardrails. The rest of this guide is about spending that flexibility well.

Abstractly, every agentic workflow cycles plan → act → observe. For building software, that abstract loop takes a concrete, repeatable shape. Seven stages, with human gates at the two points where a wrong turn is most expensive:

1. 1

   Intake: capture the goal

   A human states what they want in one or two sentences, 'add rate-limiting to the public API', not a step-by-step recipe. The goal, not the procedure, is the input; supplying the procedure would make this automation, not an agentic workflow.
2. 2

   Context gathering

   The agent reads what it needs to reason well: the relevant files, project conventions, schemas, docs. What it can see decides the quality of everything downstream, which is why this stage is a discipline of its own, context engineering.
3. 3

   Plan / spec, approved (gate 1)

   The agent proposes a plan: scope, files it will touch, acceptance criteria, exclusions. A human approves it before any code is written. This is the cheapest place to catch a misunderstanding, and it is the core of spec-driven AI development.
4. 4

   Execute via tools

   Now the loop runs: the agent edits files, runs commands, and uses git, choosing each action from the last result. This is where tool use and iteration earn their keep, and where the agent needs a bounded, well-defined workspace to act in.
5. 5

   Observe / verify

   The agent runs the tests and checks against the acceptance criteria from the plan. Verification is what turns 'it emitted code' into 'the code does what we asked', and it only works because the plan stage defined something verifiable to check against.
6. 6

   Review (gate 2)

   The finished change lands as a pull request, described and reviewable, and a human reads it against the approved plan. Review, not keystroke-watching, is the unit of human judgment. Automating the mechanics of this stage is AI PR automation.
7. 7

   Ship

   On approval, the change merges and deploys. The loop closes, and the workflow is ready for the next goal, ideally from a fresh, clean context rather than a session that has accumulated the whole history.

Inside the execute stage, agents combine a small set of building blocks. Anthropic's widely-cited Building effective agents guide names five composable patterns. Represented plainly:

Abstractions land better on a concrete task. Take a real, bounded story, “add rate-limiting to the public API”, and follow it through the stages.

1. 1

   Intake

   You write the card: 'Rate-limit the public API, 100 requests/min per API key, return 429 with a Retry-After header.' A goal with a concrete done-condition, not a procedure.
2. 2

   Context gathering

   The agent reads the routing layer, finds where public routes are mounted, checks whether a middleware pattern already exists, and notes the auth code that identifies the API key. It now knows where the limiter belongs and what it can key on.
3. 3

   Plan / spec (you approve)

   It proposes: add a token-bucket middleware, back the counter with the existing Redis client, apply it at the public-router boundary, return 429 + Retry-After, and add unit tests for the limit and the reset window. Files: middleware/rate-limit.ts, the router, a test file. Exclusions: internal routes untouched. You approve, or tighten the numbers first.
4. 4

   Execute

   In its own worktree, the agent writes the middleware, wires it into the public router, and adds the tests, running the suite as it goes and fixing what fails. The loop, act, observe the red test, adjust, is the workflow's engine.
5. 5

   Verify

   It runs the tests against the acceptance criteria: 101st request in a minute returns 429, the Retry-After header is present, the window resets. Green means the stated goal is met, not merely that code exists.
6. 6

   Review & ship

   It opens a PR titled for the story, with the approved spec as the description, so you review the diff against a written intention. You read it, confirm internal routes are untouched, and merge. The endpoint is rate-limited; the loop is closed.

Notice what each stage bought you: intake kept you stating goals, not typing code; the plan gate let you correct scope for the price of a sentence; execution and verification ran without you babysitting; review kept the final judgment human. That is a single-agent agentic workflow end to end. Run several of these at once and you are into a multi-agent coding workflow, same stages, parallelized, with story slicing and a review budget as the new constraints.

The same flexibility that lets an agentic workflow handle novelty lets it fail in novel ways. A fixed script fails by breaking; an agentic workflow fails by confidently doing the wrong thing, repeatedly. Four failure modes account for most of it, and each has a specific bound:

You can run every stage above by hand, and it is worth doing once to feel where the friction is. AIDEN's contribution is to make each stage explicit and enforced on a kanban board, rather than something you hold in your head. AIDEN is a cockpit over your local Claude Code and Codex CLIs: it does not replace the agents, it structures the workflow around them, and you bring your own inference (your existing Claude or Codex subscription or API key).

It is free for one project and $19/mo for solo use, so the cheapest way to understand an agentic workflow is to run one real story, an actual small feature, through the loop and review the PR it produces.