Update to Headcount: Technology

{
  "description": "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.",
  "included_files": [
    {
      "relative_path": "references/sources.md",
      "size_in_bytes": 873
    }
  ],
  "name": "ai-workflow-architect",
  "skill_md_contents": "---\nname: ai-workflow-architect\ndescription: 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.\n---\n\n# AI workflow architect\n\nMost automation fails on selection, not implementation. The wrong process automated well is worse\nthan the right process left manual, because now it is faster and harder to change.\n\n## What is worth automating\n\nScore each candidate on four dimensions and require a real answer to each:\n\n- **Frequency** — how often, honestly measured. Weekly is usually the floor.\n- **Time cost** — per occurrence, times frequency. Most \"huge time sinks\" are twenty minutes a week.\n- **Error rate and cost of error** — where mistakes are expensive, automation pays even at low\n  volume.\n- **Stability** — how often the process itself changes. A process that changes monthly will break\n  monthly.\n\nThen apply the disqualifiers. Do not automate a process that:\n\n- **Nobody has documented.** Automating an unexamined process encodes its accidents permanently.\n- **Requires judgment you cannot specify.** If you cannot write the rule, the system will produce\n  confident wrong answers rather than stopping.\n- **Fails silently.** An automation whose failure is invisible is worse than no automation — the\n  work stops happening and nobody notices for a month.\n- **Should be eliminated instead.** The best automation is deleting the step. Ask this before\n  designing anything.\n\n## Designing the system\n\nStart with the smallest loop that delivers value end to end, not the full vision. Systems that must\nbe complete before they are useful usually never become either.\n\n- **Deterministic where you can, model-driven where you must.** Use a model for judgment and\n  language; use ordinary code for routing, validation, and anything with a correct answer. Models\n  are the expensive, non-deterministic part — spend them deliberately.\n- **Put a human at the consequential step**, not at every step. Approval on an irreversible action;\n  no approval on a draft.\n- **Make failure loud.** Every automation needs a defined failure mode, a place the failure surfaces,\n  and someone who sees it.\n- **Idempotence matters more than it seems.** Reruns happen. A workflow that double-sends on retry\n  will eventually double-send.\n\n## Designing specialized assistants\n\nWhere a workflow needs judgment repeatedly, define a role rather than writing a prompt each time.\nA role carries: what it is accountable for, the inputs it can rely on, the output shape it must\nproduce, what it must escalate rather than decide, and what it must never do.\n\nKeep roles narrow. A single assistant asked to research, decide, and write produces mediocre\nversions of all three; three narrow ones with defined handoffs produce work you can inspect at each\nstage.\n\nPair any role that produces work with something that checks it — a rule, a test, or a separate\nreviewing role. A role that reviews its own output approves it.\n\n## Scoring candidates\n\nScore each automation candidate on frequency, time cost, error cost, and stability from one to five,\nthen multiply rather than average — multiplication makes a low score on any dimension disqualifying,\nwhich is the correct behavior. A daily task that changes weekly should not survive on frequency\nalone.\n\nRank by score ÷ build effort, and take the top item only. Automation programs fail by starting\nfour things.\n\n## Choosing tools\n\nMatch to the constraint that actually binds — volume, latency, existing stack, who maintains it, and\nwhat happens when the vendor changes terms. Prefer the boring option; a workflow platform your team\nalready uses beats a better tool nobody will maintain.\n\nWhere an agent needs access to systems, prefer a defined tool interface over screen-driving. Tools\nfail explicitly; scrapers fail silently and at the worst time.\n\n## Sequencing\n\nBuild in this order: highest frequency × lowest complexity first. Early wins fund attention for\nharder ones, and the first automation teaches you what the second should look like.\n\n## Risks to state before building\n\nData leaving your control, model output reaching customers unreviewed, a silent dependency on a\nvendor's pricing, and the maintenance burden landing on one person. Name the owner of each before\nbuilding, not after.\n\n## Sources\n\n`references/sources.md` in this skill lists the outside authorities that settle the questions\nhere — what each one is authoritative for, and what you may do with it. Check them before\nanswering on anything they cover, and cite what you used. Most are free to read and not free\nto reproduce; the use note on each is binding.\n\n## Never\n\n- Automate a process nobody has written down. You will automate the exceptions along with the work.\n- Build before you know what a wrong output costs and who is positioned to catch it.\n- Put a model where a rule would do. Deterministic steps should stay deterministic.\n- Ship without a human review point on any step that spends money, sends mail, or deletes data.\n"
}