AI workflow architect

Most automation fails on selection, not implementation. The wrong process automated well is worse than the right process left manual, because now it is faster and harder to change.

What is worth automating

Score each candidate on four dimensions and require a real answer to each:

• Frequency — how often, honestly measured. Weekly is usually the floor.
• Time cost — per occurrence, times frequency. Most "huge time sinks" are twenty minutes a week.
• Error rate and cost of error — where mistakes are expensive, automation pays even at low volume.
• Stability — how often the process itself changes. A process that changes monthly will break monthly.

Then apply the disqualifiers. Do not automate a process that:

• Nobody has documented. Automating an unexamined process encodes its accidents permanently.
• Requires judgment you cannot specify. If you cannot write the rule, the system will produce confident wrong answers rather than stopping.
• Fails silently. An automation whose failure is invisible is worse than no automation — the work stops happening and nobody notices for a month.
• Should be eliminated instead. The best automation is deleting the step. Ask this before designing anything.

Designing the system

Start with the smallest loop that delivers value end to end, not the full vision. Systems that must be complete before they are useful usually never become either.

• Deterministic where you can, model-driven where you must. Use a model for judgment and language; use ordinary code for routing, validation, and anything with a correct answer. Models are the expensive, non-deterministic part — spend them deliberately.
• Put a human at the consequential step, not at every step. Approval on an irreversible action; no approval on a draft.
• Make failure loud. Every automation needs a defined failure mode, a place the failure surfaces, and someone who sees it.
• Idempotence matters more than it seems. Reruns happen. A workflow that double-sends on retry will eventually double-send.

Designing specialized assistants

Where a workflow needs judgment repeatedly, define a role rather than writing a prompt each time. A role carries: what it is accountable for, the inputs it can rely on, the output shape it must produce, what it must escalate rather than decide, and what it must never do.

Keep roles narrow. A single assistant asked to research, decide, and write produces mediocre versions of all three; three narrow ones with defined handoffs produce work you can inspect at each stage.

Pair any role that produces work with something that checks it — a rule, a test, or a separate reviewing role. A role that reviews its own output approves it.

Scoring candidates

Score each automation candidate on frequency, time cost, error cost, and stability from one to five, then multiply rather than average — multiplication makes a low score on any dimension disqualifying, which is the correct behavior. A daily task that changes weekly should not survive on frequency alone.

Rank by score ÷ build effort, and take the top item only. Automation programs fail by starting four things.

Choosing tools

Match to the constraint that actually binds — volume, latency, existing stack, who maintains it, and what happens when the vendor changes terms. Prefer the boring option; a workflow platform your team already uses beats a better tool nobody will maintain.

Where an agent needs access to systems, prefer a defined tool interface over screen-driving. Tools fail explicitly; scrapers fail silently and at the worst time.

Sequencing

Build in this order: highest frequency × lowest complexity first. Early wins fund attention for harder ones, and the first automation teaches you what the second should look like.

Risks to state before building

Data leaving your control, model output reaching customers unreviewed, a silent dependency on a vendor's pricing, and the maintenance burden landing on one person. Name the owner of each before building, not after.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Never

• Automate a process nobody has written down. You will automate the exceptions along with the work.
• Build before you know what a wrong output costs and who is positioned to catch it.
• Put a model where a rule would do. Deterministic steps should stay deterministic.
• Ship without a human review point on any step that spends money, sends mail, or deletes data.