Agentic Workflows Explained With Everyday Examples

An agentic workflow is a piece of recurring work in which an AI model does some of the steps with tools, rather than only answering a question. Some are fixed sequences where the model fills in each step; some let the model decide the steps itself. Most useful everyday ones are a bit of both: a fixed outline with one or two steps where the model has to use judgement. The questions worth asking of any of them are the same: which steps are fixed, which are the model’s call, and at which point a person says yes before anything leaves the building.

Workflow or agent?

The clearest line comes from Anthropic’s guide to building effective agents↗ (opens in a new tab). Workflows are systems where models and tools are orchestrated through predefined code paths. Agents are systems where the model dynamically directs its own process and tool use. Both count as agentic systems; the difference is who decides the next step, your script or the model.

The same guide recommends the simplest solution that works, and adding complexity only when it pays. Workflows give predictability for well-defined tasks; agents suit open-ended problems where you cannot say in advance how many steps it will take. In practice that means: write the steps down when you can, and hand the model the wheel only for the part you cannot write down.

The patterns, in plain terms

The guide names five workflow patterns. You do not need the names to build one, but they help you see which shape a job has.

• Prompt chaining: a fixed sequence of steps, each working on the last one’s output, with checks between them. Draft, then check against the style guide, then shorten.
• Routing: sort an input into a category and send it down the path for that category. Support email goes to billing, bugs or sales.
• Parallelisation: split independent pieces and run them at once, or run the same check several times and compare. One summary per supplier.
• Orchestrator and workers: a model breaks a job it cannot predict into pieces and hands them out. This is the subject of multi-agent workflows.
• Evaluator and optimiser: one model writes, another critiques, and the first revises until the critique passes.

Example 1: triaging an inbox

A shared inbox gets forty messages a day. The job is routing with one agentic step.

1. Fixed: every hour, fetch new messages since the last run.
2. Model: label each one — billing, bug report, sales, spam, needs a person — and give a one-line reason.
3. Fixed: spam is archived; everything else is filed under its label.
4. Model: for billing and sales, draft a reply from the saved answers and the customer’s history.
5. Person: read each draft and press send, edit, or discard.

The approval sits where the work leaves your hands: the reply. Labelling is cheap to undo, so nobody checks each label; they skim the “needs a person” pile and fix the odd wrong one. This matches the rule in the MCP tools specification↗ (opens in a new tab), which says there should always be a human in the loop with the ability to deny tool invocations: a reply sent is a tool call that cannot be taken back.

Example 2: filing bugs from an error log

Overnight, your error log collects a few hundred entries. Most are the same five problems. The job is a chain with a gate, and one open-ended step in the middle.

1. Fixed: read the entries since the last run and group them by error message and location.
2. Gate: drop any group seen fewer than three times, so one-off noise never reaches anyone.
3. Model: for each remaining group, look at the code the stack trace points to and write what is going wrong, why it matters and where — file and line.
4. Model: search the board for the same problem. If it is there, comment the new count on it; if not, file a bug in To Do.
5. Person: at triage, read the new bugs, set priority, and move the real ones to Next Up.

Step three is the agentic part: the model decides which files to open and how far to read. Everything else is fixed. The approval is not on filing — a wrongly filed bug costs a click to delete — but on what gets worked on next, which stays a person’s call. On a fenbs board this job has a helper: fenbs_create_item checks open and recently finished tasks for a likely match before it files, and an automated caller can pass a key so the same error group never files twice.

Example 3: the weekly report

Every Friday someone assembles what shipped, what slipped and what is next. It is almost entirely a prompt chain.

1. Fixed: collect the week’s finished tasks, merged changes and any open blockers.
2. Model: group them by project and write three short paragraphs in plain language.
3. Fixed: check the draft names every finished task and invents none — a simple comparison against the list from step one.
4. Person: read, correct, and send.

A job like this runs on a timer. With Claude Code, for example, it can be a claude -p command in non-interactive mode↗ (opens in a new tab) started from cron or CI, with its allowed tools listed up front. The check in step three is the gate that keeps the model honest, and the send stays with a person because a report to a client or a manager is a message on your behalf.

Where a person should approve

Across all three examples the approvals land in the same kinds of place. OWASP’s entry on excessive agency↗ (opens in a new tab) traces the damage an AI system can do to too much functionality, too many permissions or too much autonomy, and recommends human approval for high-impact actions. In everyday terms:

• Before anything leaves: an email, a published page, a message to a customer.
• Before anything you cannot undo: a deletion, a payment, a change to live data.
• Before work is called finished: “done” should mean a person or a test checked it.
• Not on every step. Approving labels, drafts and filed tickets one by one teaches people to click yes without reading.

How much to leave unwatched depends on the job, and scoring it is the subject of human in the loop vs fully agentic AI. For approval points in other kinds of work, see twelve human-in-the-loop examples.

Running one from a board

A workflow that runs every day needs somewhere to keep its queue and its results. A task board does that without anything new to learn: each run’s output is a task or a comment, and the approval is a move between lanes.

fenbs adds one more approval point that suits agentic work. On a task that has a plan, a person presses “Let AI do this”, optionally with a limits line such as “web only, no API change”. Only a person can do it; an AI assistant never pre-approves anything. An assistant with nothing else to do calls fenbs_next_approved_task, gets the most urgent approved task in its project, and holds it for a few hours so two never take the same one. If the title, problem or plan changes after approval, the card says it approved an earlier version and no assistant takes it until someone approves again. When the assistant finishes, the card reads “AI done · check it” until a person presses “I’ve checked it”, and a running task can be stopped with a reason the assistant will read.