Why Small, Single Purpose AI Agents Are Easier to Run

Alex runs customer operations at Pinecrest Apparel, a fictional decorator, and is very proud of a workflow called Order Helper. Order Helper reads incoming POs, checks them against the price list, creates orders in the ERP, and replies to customers. It does everything. For about six weeks, this was the best thing about it.

Then a customer writes in to ask why their order shows 500 polos when they ordered 50. Alex opens the run history and finds one long, confident record of Order Helper doing everything. Did it misread the PDF? Did the price check change the quantity? Did the ERP write go wrong? Did the reply just describe the order badly? Order Helper's answer, essentially, is "yes." Alex spends the afternoon reading it the way you'd read a transcript of a phone call where both people talked at once.

Split an AI process where its stages need different permissions, decision rules, owners, or tests. Keep simple work together when an extra handoff adds cost without adding control. A good small job has a defined input, a checkable output, and a clear reason to stop or hand off.

For a promo order, intake, validation, record creation, and notification are useful places to look for boundaries. They aren't a rule that says you need four separate models or products. The goal is that when something goes wrong, you can point at the stage where it happened.

One workflow doing everything, versus a few clear jobs

The jobs themselves are ordinary. An intake job identifies a new PO and gathers its attachments. A validation job checks the proposed order against approved customer and product records. An action job creates the order once validation or a person has approved it. A notification job records what happened, or tells the right person what's missing.

Some of those jobs might be plain software rules rather than AI. That's fine. The point is to give each stage one job and a result someone can check.

Anthropic's guidance on building effective agents describes composable patterns such as chaining one step into the next and routing work to different paths. Its practical advice applies here too: add complexity only where it helps the work get done or controlled.

Start from where responsibility changes hands

Sketch the current process from the moment an order arrives to the moment it's finished. Mark every point where responsibility moves to a different person or where a decision needs confirming. Those are your candidate boundaries.

In most order desks, a person reads the email, a different person (or the same person wearing a different hat) checks pricing, and someone with ERP access creates the order. Those hand changes already exist for a reason. They usually line up with different permissions, different expertise, or a different consequence if it goes wrong.

Write the handoff contract

This is the part most teams skip, and it's the part that makes small jobs work. For each stage, write down what it accepts, what it must produce, and what it must never do. Here's the contract Alex writes after the 500 polos afternoon.

Notice that validation has two possible outputs, and they should look nothing alike. A checked proposal and a list of questions must be impossible to confuse, so the action stage can't mistake one for the other.

Also notice that the action stage carries the revision number. If the customer sends a revised PO between approval and the ERP write, the action stage stops and sends the order back for validation. Applying an approval to a version nobody approved is one of the more expensive ways for a split workflow to fail.

Hand off records, not memories

If two stages need the same order information, put it in a durable record with a stable ID. Don't count on the next stage remembering what the previous one discussed. A shared conversation is not a reliable handoff by itself. The next stage needs a current, structured record it can check.

The record should carry the source, the current revision, the validation result, and any approvals. When someone corrects a quantity, the downstream stage should receive the corrected version, not a summary copied an hour earlier.

Decide who owns each field. If two stages can change the same value, write down the coordination rule before launch. A good handoff also helps people. Someone resuming interrupted work should be able to see which order was in progress and whether an ERP record already exists, without reconstructing a long run.

Give each job only the access it needs

The stage that reads an invoice may not need permission to post it. The stage that drafts a customer reply may not need authority to send it. Separate stages can make those permission boundaries easier to enforce and test.

Narrow access limits what a wrong instruction or an odd input can do, though it doesn't remove all risk. If the person running the workflow can't explain why a stage has access to a system, that's worth pausing on. This matters most when you copy a working workflow for another team, since a template can carry permission assumptions that don't fit the new setup.

Fix the stage that broke, then test the whole path

Say a supplier changes its PDF layout. With extraction in its own intake stage, you know where to start the repair. You don't have to wonder whether the price logic or the reply template is involved.

Then run the full workflow end to end to confirm the changed output still works downstream. Splitting makes testing more focused. It doesn't remove the need to check the complete path.

Keep a few stable examples for each stage, including failures and safe stops, and track which version of each stage's instructions produced a result. Avoid changing several stages at once unless the change really requires it. Otherwise a new error leaves you guessing which adjustment caused it.

When to keep it as one workflow

Splitting a simple task adds overhead. If a workflow reads one approved record and writes one internal summary, three separate jobs would just add handoffs and delay.

Before splitting, ask whether the stages need different permissions, owners, tests, or reuse. If none of those apply, one clearly structured workflow is probably easier to maintain. More stages can also mean more model calls, more stored data, and more places to monitor, so look at the whole process rather than assuming smaller is always cheaper.

The opposite failure is real too. If stages pass each other vague summaries instead of structured records, each one still has to reconstruct the task, and you've built Order Helper with extra steps. The handoff contract is what makes the split worth it, whether you end up with one workflow or four.

Splitting checklist

• Boundaries follow points where permissions, owners, decision rules, or tests change.
• Each stage has a written input, a required output, and a list of things it must not do.
• Validation produces either a checked proposal or named questions, never something in between.
• The action stage carries the revision it was approved against and stops if that changes.
• Stages share a durable record with a stable ID, not a conversation.
• Every shared field has an owner and a coordination rule.
• Each stage has only the access its job requires.
• A fix to one stage is followed by an end to end test.
• Simple, low risk work stays in one workflow.

Frequently asked questions

1Do single purpose AI agents need separate AI models?

No. A stage is defined by its job and its handoff, not by its model. Some stages may be ordinary software rules, and several stages can use the same model with different instructions.

2What should a handoff between two AI workflow stages contain?

At minimum: a stable record ID, the source it came from, the current revision, the result of the previous stage, and any approvals. The receiving stage should be able to act on that record without access to the earlier stage's reasoning.

3How do I know if I've split a workflow into too many pieces?

If stages don't differ in permissions, owners, tests, or reuse, the split probably isn't earning its overhead. Another sign is handoffs that carry vague summaries, which force the next stage to redo the work.

4Does splitting a workflow make it more secure?

It makes narrower permissions possible, which can limit the damage from a bad input. It doesn't make a workflow secure by itself. Permissions, shared records, and end to end tests still need to be designed and checked.

5What happens if the order changes between stages?

The record should carry a revision number, and any stage that acts on an approval should confirm the revision hasn't changed. If it has, the order goes back to validation instead of applying an approval to a version nobody saw.

The next 500 polos

Three weeks later, Pinecrest gets another order that comes out wrong: 144 hoodies where the customer wanted 14. Alex opens the intake record for that order. The PDF shows "14 4" with a large gap, the intake stage read it as 144, and the record says so plainly. Validation flagged the quantity as unusual for that customer, and the order is sitting in review rather than in the ERP.

Alex fixes the intake rule for that supplier's layout and runs the full set of examples. It takes twenty minutes, most of which is waiting for coffee. Order Helper still exists as a name on the team's whiteboard, but now it has four boxes underneath it, and each box has an owner.