AI workflow patterns: the shapes that recur

Automations look varied and are structurally repetitive. Most working ones are an instance of a small number of shapes, and recognising which shape you are building tells you in advance what will go wrong with it.

This is a catalogue of those structures rather than a list of use cases. The value is in the failure mode attached to each, because that is the part nobody discovers until the automation has been running for a month.

What we'll cover

• Why patterns rather than examples
• Trigger and act
• Enrich and route
• Building it with CodeWords
• Poll and diff
• Fan out and gather
• Draft and approve
• Watch and escalate
• Assemble and publish
• Two shapes worth avoiding
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why patterns rather than examples

Use cases do not transfer. Somebody else's invoice workflow tells you little about yours.

Structures do transfer, along with their characteristic problems.

Each shape has a known failure mode, which is the useful thing to know before building rather than after.

Recognising the shape tells you what to test, since the tests differ by structure rather than by subject.

Most complexity is combination. A real automation is usually two or three of these joined.

If yours is not one of these, it is worth asking whether it should be, because the unusual shapes are where the maintenance lives.

Trigger and act

Something happens; something else happens. The simplest shape and the most common.

Good for: notifications, record creation, simple state changes.

Failure mode: at-least-once delivery. Triggers fire twice, so the action must be idempotent or you get duplicates.

Second failure mode: the trigger stops firing and nothing notices, since absence produces no error.

Test by firing the trigger twice and confirming one effect, then by disabling the trigger and confirming something alerts.

Alert on absence, always, which is the single most neglected part of this shape.

Enrich and route

Take an input, add context, send it somewhere based on what it says.

Good for: inbound requests, leads, tickets, alerts.

Failure mode: the enrichment fails and the routing proceeds on missing data, silently choosing a default.

Second failure mode: classification is confident and wrong, and nothing downstream questions it.

Test by removing each enrichment source in turn and confirming the behaviour is sensible rather than silently degraded.

Always have an unrouteable destination that a person watches, since forcing everything into a category is how items disappear.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the shape, the steps, and what happens when a step fails.
3. Authorize the connections the workflow needs.
4. Describe the exceptions: a duplicate trigger, a missing enrichment, a low-confidence classification, an unavailable system.
5. Run it against real historical inputs and check the output against what actually happened.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Poll and diff

Check something periodically, act on what changed. Used where no trigger exists.

Good for: systems without webhooks, external sources, scheduled reconciliation.

Failure mode: the first run. Without a baseline it treats everything as new and floods whatever is downstream.

Second failure mode: a missed poll means a missed change, permanently, unless the diff is based on state rather than on time.

Test by running it against a system with known changes and confirming it finds exactly those.

Store the state, not the timestamp, which is what makes a missed run recoverable rather than a gap.

Fan out and gather

Split work into parts, process in parallel, collect the results.

Good for: bulk operations, multi-source checks, anything with independent items.

Failure mode: partial completion. Some branches succeed and some fail, and the gather step has to decide what that means.

Second failure mode: rate limits, since fanning out is the fastest way to exhaust an API quota.

Test by forcing a branch to fail and confirming the outcome is what you intended rather than whatever happened.

Decide the partial-result policy explicitly — proceed, fail, or wait — because the default is usually wrong.

Draft and approve

Generate something; a person reviews before it takes effect.

Good for: anything with consequences — messages, documents, changes to records.

Failure mode: rubber-stamping. An approval step that always says yes is theatre, and it happens whenever the volume outpaces attention.

Second failure mode: the queue grows unwatched and the automation quietly stops producing anything.

Test by measuring the edit rate — if approvers never change anything, either the drafts are perfect or nobody is reading them.

Show the approver what is unusual, not the whole item, which is what keeps approval meaningful at volume.

Watch and escalate

Monitor a condition; raise it to a person when it persists or worsens.

Good for: ageing items, stalled processes, thresholds.

Failure mode: alert fatigue, where the escalation fires often enough that people stop reading it.

Second failure mode: escalating to a channel rather than a person, so everybody assumes somebody else is handling it.

Test by counting how many escalations produced an action last month, which is the only measure that matters.

Escalate to an individual with a deadline, and escalate further if nothing happens.

Assemble and publish

Gather from several sources, compose an output, send it.

Good for: reports, digests, summaries, scheduled communications.

Failure mode: a missing source producing a report that looks complete and is not.

Second failure mode: publishing on a schedule regardless of whether there is anything to say, which trains recipients to ignore it.

Test by removing a source and confirming the output says so rather than silently omitting a section.

Skip rather than pad when there is nothing, which is what keeps it read.

Two shapes worth avoiding

Some structures recur and should not. They are usually arrived at by accretion rather than chosen.

The chain of chains. An automation triggering another which triggers a third, none of which knows about the others. Debugging requires holding all of them in your head, and a change to the first has effects nobody predicted.

The bidirectional sync. Two systems each updating the other, which has no natural conflict resolution, forms loops easily, and diverges on exactly the records where matching failed.

Both are reachable by small reasonable steps, which is why they are common — nobody decides to build either.

The fix for the first is one orchestrator that owns the sequence, so there is a single place where the flow is visible.

The fix for the second is deciding which system is authoritative per field and making everything else read rather than store.

Notice them early, because both become considerably harder to unpick once other things depend on them.

Making it survive

Idempotency applies to every shape, since every trigger and every retry can duplicate.

Alert on absence, since most of these fail by stopping rather than by erroring.

Persist before processing, so a downstream failure delays rather than discards.

Make partial states recoverable, which means designing the rerun rather than hoping.

Report the outcome from every automation, because an automation that reports nothing is one nobody will notice has died.

Limits worth knowing about

Combining shapes multiplies failure modes, so a three-shape workflow has all three sets.

Rate limits constrain fan-out more than anything else.

Polling has an inherent lag, which is a design consequence rather than a bug.

Approval steps are a human dependency and inherit human availability.

No pattern fixes an unclear process. If nobody can say what should happen, no shape will decide it for you.

What to build first

Whichever shape your workflow actually is, with its known failure mode handled first. If it is trigger-and-act, make it idempotent and alert on absence before anything else. That ordering is what separates an automation that runs for a year from one that breaks in month two and is discovered in month four.

Two habits make the difference. Alert on absence for every shape, since these systems overwhelmingly fail by going quiet rather than by erroring. And measure the edit rate on any draft-and-approve step, because an approval nobody is really performing is worse than no approval at all — it provides assurance that does not exist.

Frequently asked questions

Why learn patterns rather than examples?

Because use cases do not transfer and structures do, along with their characteristic failure modes. Recognising the shape tells you what will break before you build it.

What is the most common automation shape?

Trigger and act. Its failure modes are duplicate execution from at-least-once delivery, and the trigger silently ceasing to fire — which produces no error anywhere.

What goes wrong with enrich and route?

The enrichment fails and routing proceeds on missing data, choosing a default silently. Always have an unrouteable destination somebody watches rather than forcing every item into a category.

What is the trap in a polling workflow?

The first run, which without a baseline treats everything as new. Store state rather than a timestamp, so a missed poll is recoverable rather than a permanent gap.

Why do approval steps fail?

Rubber-stamping, once volume outpaces attention. Measure the edit rate — if approvers never change anything, either the drafts are perfect or nobody is reading them.

What is the main risk in fan-out?

Partial completion, where some branches succeed and some fail and the gather step has no defined policy. Rate limits are the second, since fanning out is the fastest way to exhaust a quota.

How do these automations usually die?

By going quiet. They stop being triggered, or a source stops responding, and nothing errors. Alerting on absence is the single most neglected safeguard across every shape.

What if my workflow is not one of these shapes?

Worth asking whether it should be. Unusual structures are where the maintenance concentrates, and most real complexity is two or three standard shapes joined rather than something genuinely new.

Which automation shapes should be avoided?

Chains of automations triggering one another, where no single place shows the flow, and bidirectional syncs, which have no natural conflict resolution and diverge on exactly the records where matching failed. Both are reached by small reasonable steps rather than decided.

How do I fix a chain of chained automations?

One orchestrator that owns the sequence, so the flow is visible in a single place. Doing it early matters, since the chain becomes much harder to unpick once other things depend on its intermediate steps.

Related reading

• AI workflow automation: when the model is needed
• AI automation examples, including what went wrong
• AI workflow tools and what each layer does