This week's video

A lot of agent demos start from the same pattern: give the model a broad objective and let it figure out the steps. Sometimes that is exactly the right shape. Broad agent workflows can work when the system needs to respond to messy context, changing goals, or paths you do not know in advance. But when you already know the sequence of steps, it is usually better to encode that sequence as a workflow, especially when the output touches a relationship, a deal, or a reply someone else will read.

This week I build that more structured version with Mastra Workflows. I split sponsor inbox triage into explicit steps: normalize the email, classify it with a small bounded model call, route it, branch into a nested sponsor workflow, pull outside research for corroboration, score the fit, apply deterministic guardrails, then draft a reply and a structured internal brief. The architecture lesson holds no matter which framework you reach for.

Watch the video

The boundary I keep coming back to

The real question underneath this build is where an agent loop should end and a workflow should begin.

Agent loops are great when the task is actually open-ended. Exploration, synthesis, messy problems where you do not know the path in advance. But a lot of the work we hand to agents is more repeatable than that. The model still has useful judgment to contribute, but it does not need to invent the order of operations every time.

The way I think about it is a simple split. Use agents when the task requires judgment. Use workflows when you need reliability. Workflows are not a downgrade from agents, they are the right tool when the problem has a known shape. The heuristic I keep coming back to: do not use an LLM to orchestrate steps whose order is already known. That usually shows up as extra tokens, extra latency, and less predictable behavior.

This is not an anti-agent take. Anthropic makes the same point in their guide on building effective agents: find the simplest solution possible, and only add complexity when it earns its place. Agentic systems trade latency and cost for flexibility, so workflows win when the task is well-defined and agents win when you genuinely need model-driven decisions at scale. The sponsor inbox sits firmly on the workflow side. The steps repeat, the output goes to a real person, and I want the same behavior every time.

Routing is the unglamorous backbone

The first real decision in the build is classification, and that turns out to be most of the game.

Routing is one of the oldest workflow patterns there is. Classify an input, then send it to a specialized follow-up. In Anthropic's guide on building effective agents, routing is the workflow pattern for cases where distinct categories are better handled separately. Their customer support example splits general questions, refund requests, and technical support into separate downstream processes, prompts, and tools. Sponsor inbox triage is the same move. Classify the email, then branch into a workflow that knows how to handle that specific kind of message.

The payoff is separation of concerns. A prompt tuned to evaluate sponsorships does not also have to be good at everything else that lands in the inbox. And because the classify step has one narrow job, it is a perfect place for a small, cheap, fast model. You do not need your most expensive model to decide "is this a sponsorship or not." Save the heavier reasoning for the step where editorial judgment actually matters.

Guardrails belong outside the prompt

The sponsor workflow does not leave the final decision entirely inside the model call.

The model helps score whether a sponsorship is a fit, but it does not get the final say. If external corroboration is weak, the workflow simply cannot return "pursue," no matter how confident the model sounds. That decision lives in deterministic code, not in a prompt.

I treat guardrails as layered defense. No single check is enough, but a few specialized ones together make the system hard to fool. Anthropic's guide has a nice supporting detail here: having a separate model instance screen the output tends to work better than asking one call to produce the answer and police itself at the same time. And for anything irreversible, sending an external reply, moving money, making a commitment, the workflow should stop and escalate to a human rather than trust the model's confidence.

That is the difference between a clever demo and something you would let near a real inbox. The model proposes, the workflow disposes, and because every step is typed and traced, when something goes wrong you can see exactly which step did it.

The same shape shows up well beyond email: product research, sales intake, support triage. Messy input, bounded judgment, typed handoffs, deterministic output.

If you want to go deeper

• Building effective agents (Anthropic). The clearest short read on workflows versus agents, and the source of the five workflow patterns I lean on most, including routing.
• A practical guide to building agents (OpenAI). Good on starting with a single agent and only splitting into specialists when the logic or the tools get unwieldy.
• Mastra Workflows docs, plus scorers and tracing, if you want to build the version from the video.

The demo repo and chapter links are in the video description.

If you are building something like this, where do you draw the line between an agent loop and a workflow? Reply and tell me. The boundary cases are where this gets interesting.

That conversation is also a good fit for Practical AI, the small Slack community I run for builders putting AI into real work. This issue's question, where agents should own the loop and where workflows should take over, is exactly the kind of thing we work through there. If that sounds useful, request an invite.

And if you want help designing the architecture around a production agent, book an intro call.

Damian