Workflows before agents

Clients ask for agents. What most of them need is a workflow: a sequence of steps you designed, in which a model handles the parts that need reading or judgment and ordinary code handles the rest. Workflows are cheaper and faster, and when something goes wrong you can point to the exact step.

Workflow or agent?#

Anthropic's engineering note on building effective agents puts the line in a useful place. In a workflow, you decide the steps and the model works within them. In an agent, the model decides what to do next, choosing tools as it goes. The note's advice, which matches field experience, is to start with the simplest thing that works and add autonomy only when it clearly pays.

One question settles most cases. Ask the client's most experienced person to talk you through how they handle a typical case. If they describe a procedure, with a few branches, you are looking at a workflow. If they say it depends entirely on what they find, an agent might earn its keep, and probably only for that part.

Five patterns that cover most requests#

The same note names a handful of patterns that turn up repeatedly. They are worth knowing by name, because naming the pattern in a client meeting turns a vague "AI solution" into a design people can discuss.

Real systems combine them. An insurer's inbox might route each email by type, chain a few steps for claims, and fan out to check several policy conditions at once, all without the model ever choosing what happens next.

Code, model, person: three lanes#

Inside any pattern, give each piece of work to whoever does it best. Models are good at reading messy language and making judgment calls about meaning. They are poor at arithmetic, dates and following a rule exactly every time, which is precisely what code is good at. People are best at the cases that are rare, ambiguous or high-stakes.

• Give the model closed questions. "Which of these five categories?" is far more reliable than "what should we do?". Validate the answer against the list in code and reject anything else.
• Keep the rule in code, the reading in the model. The model extracts the delivery date from a letter. Code decides whether it is within the 30-day window.
• Record why. Store each model judgment with its explanation and how sure it was, so a person can audit a decision without rerunning anything.
• Keep randomness low for sorting and extraction. Two identical cases should get the same answer.

Design the exits before the happy path#

Before drawing the normal route through a workflow, ask where cases leave it for a person. Start with the client's own rules. Most organisations already restrict certain decisions to certain people: refunds over a threshold, anything involving a child, a regulator or a complaint about staff. Those restrictions carry straight over. Then add your own: cases where the model isn't confident, where two facts contradict each other, or where the input doesn't match any category you planned for.

Make "send it to a person" the default when nothing else matches. A workflow that guesses on unfamiliar input will eventually guess badly in front of a customer. One that hands over looks cautious, and that is the point. If the client can't say which decisions are reserved for people, help them write it down before you build. It is often the most valuable document of the engagement.

Agree with the client what the system will never decide on its own, and build that first.

Case study: the Fieldwork feed#

This site uses a workflow like this. Fieldwork scrapes hundreds of LinkedIn and X posts about forward deployed and GTM engineering. Most are recruiter posts, course promotions and job announcements. Keyword rules could not reliably tell a hiring post from a thoughtful post about hiring. Here is how the pipeline works.

1. 1

   A gate in code

   Posts must actually mention the field, be in a readable language, and not be one of many near-identical copies. Rejected posts cost nothing.
2. 2

   Three narrow questions in one request

   Using Jev, a typed-judgment API from TypeSafe: what kind of post is this (with each option defined, and what it is not), is it substantively about the field (a probability), and how much usable substance does it contain (a four-level rubric).
3. 3

   Raw judgments are stored

   Probabilities and scores go into a file keyed by field and URL, with a hash of the text. A post is judged again only if its text changes, so daily refreshes cost almost nothing.
4. 4

   Policy lives in code

   Keep insight posts that are at least 50% likely to be about the field and score at least 0.3 on substance. Below 0.3 confidence on the kind question, ignore the judgment and use the older rule-based classifier.
5. 5

   Every outcome has a home

   Insights go to the feed, hiring posts become job leads, and authors are ranked by what they post. Promotions and off-topic posts are dropped.

Of 471 posts judged, 231 were classed as insight. 28 were dropped as only mentioning the field, and 17 for having little substance, leaving 186 for the feed. The 147 hiring posts were not wasted either: 129 of them became job leads. Three lessons transfer directly to client work.

• Ask narrow questions. Three small typed questions were far more stable than one "is this post good?" prompt.
• Say what each option is not. Most errors were near-misses between neighbouring categories. Writing the "not for" case fixed them.
• Separate judgment from policy. Thresholds change weekly. Asking the model again should not have to.

Testing a workflow step by step#

Because a workflow is made of steps, you can test each step on its own, which is much easier than judging the whole.

1. 1

   Label a few dozen cases per model step

   Ask the client's experts for the right answer to each, using their own policy. Measure every model step against its own small set.
2. 2

   Test the code steps like any code

   Unit tests for the rules, the thresholds and the date logic, with the boundary values.
3. 3

   Run the whole thing end to end

   On a larger sample, and note for each wrong outcome which step it started in.
4. 4

   Check the exits separately

   Feed it cases that must reach a person and confirm every one does. Count any that slip through as serious, however small the number.
5. 5

   Replay after every change

   Stored judgments make this cheap. Fieldwork re-applies a changed threshold to every past post without asking the model anything.

When a client complains that too much is going to people, resist loosening the exits in general. Find the specific kind of case that is being sent unnecessarily and fix that, leaving the client's reserved decisions alone.