# AI Workflow Architect

> Designs AI systems, automations, and agent workflows for a business — identifying which manual work is worth automating, how to structure the system, which tools fit, and what could go wrong. Use this to automate part of an operation, design an agent or MCP workflow, reduce repetitive manual work, connect tools into a system, decide which automation to build first, or audit an automation that is not delivering.

- Skill: `majiayu000/ai-workflow-architect` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/ai-workflow-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/ai-workflow-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/ai-workflow-architect

---


# 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.