---
name: workflow-parts-map
description: Use when someone wants to build a workflow or agent from a job their team does by hand, break a workflow into parts, decide which steps an agent runs and which a person keeps, or change a workflow (swap a tool, move a step to a person, add a step) without rebuilding it. Companion to the Show Me Your AI episode with Ben Vincent on what AI agents are and how to actually put them to work.
---

# Workflow Parts Map

## The problem this solves

People treat a workflow as one fixed thing. When a tool changes or a client wants a person on a step, they think they have to start again. A good workflow is made of parts: the stage, the step, who runs it, and which platform it runs on. Map those parts once and you can swap any one of them while the rest keeps running.

The skill does two jobs:

1. **Map:** turn a job someone does by hand into a parts map, count the steps, people and handovers today and with an agent, pick how much approval it needs, and list what your experts need to write down first.
2. **Swap (optional):** change one part of an existing map and show exactly what else changes.

## Before you start

If the user wants a new map, ask for:

1. The job, described the way they'd explain it to a new starter.
2. How often it runs and roughly how long it takes today.
3. The tools it touches (for example Slack, Teams, an ad platform, a CMS, a spreadsheet, email).
4. Who signs it off today, if anyone.

If the user pastes an existing map and asks for a change, skip to "Swap a part (optional)".

Work only with what you're given. If a step or tool is unclear, ask one question rather than guessing. Never invent a tool, connection or capability.

## Map the parts

List the job as numbered steps, one action each, in the order they happen. Give every step four parts:

| Part | What it means |
|---|---|
| **Stage** | One of: Request, Interpret, Research, Create, Review, Deliver |
| **Step** | The action, in a few words |
| **Who runs it** | Agent, or Human in the loop (name the role, for example "content manager") |
| **Platform** | The one tool or place where the step happens |

Keep it to the steps that happen every time. No branches or loops in the first version.

### Deciding who runs each step

- **Agent:** repeatable, the rules are clear, and a mistake is easy to spot and cheap to fix.
- **Human in the loop:** it spends money, changes a live account or system, goes out under the company's brand, or needs judgement the user can't write down.

Put a person before anything that's expensive or hard to undo, not after it. If a wrong choice would be caught at a later approval, that step can stay with the agent. A step that runs straight after a person approves it, such as posting or sending the approved version, should stay with the agent, because the approval covers it. Don't add a second person just to press the button.

Give the reason for each choice in one line.

## Count the steps, people and handovers

A handover is every time the job has to wait for a person to pick it up and get up to speed, including when someone picks it up only to pass it on (copying, uploading, sending a message). Count three things, twice:

| | Today | With the agent |
|---|---|---|
| **Steps** | every step as the user described it | every step in the parts map |
| **People** | everyone who touches the job | only the people still in the loop |
| **Handovers** | every step a person runs | only the steps still marked Human in the loop |

Say the numbers plainly, for example "11 steps, 7 people and 7 handovers today; 1 person and 1 handover with the agent", then name the ones the agent cuts and the ones that remain and why. Most of the cut ones will be people moving work along, not making decisions. That's the point.

## Choose the approval level

Recommend one of three levels and say why in one line:

- **Fully autonomous:** no person approves. Only when a mistake is cheap, easy to undo and never goes out under the brand or spends money.
- **One human in the loop:** one person approves before the risky step. The default for anything public, client-facing or that spends money.
- **Two or more approval layers:** for anything with legal, compliance or financial risk, for example legal signs off after the workflow owner.

If the user isn't sure, start one level more cautious and loosen it once the agent has been right for a few weeks.

## What your experts need to write down first

An agent can only follow rules that are written down. For every step the agent takes over, list the knowledge a person currently keeps in their head: the rule, the judgement call, the example of good and bad, or the brand or compliance standard they check against.

Write each one as a short question the expert can answer, for example "How do you decide which page to refresh first?" Put the steps with the most unwritten knowledge first, because those are the ones most likely to go wrong. If a step needs knowledge nobody can write down, move it to Human in the loop.

## Swap a part (optional)

When the user asks to change something, change only that part and keep everything else the same. Then say what the change affects. There are three kinds of swap:

1. **Swap the platform** (for example Slack to Teams, Google Ads to Microsoft Advertising, Notion to Jira). The step stays the same. List the connection the agent now needs and the one it no longer needs.
2. **Swap who runs it** (Agent to Human in the loop, or back). Re-check the rule above. If moving a step to the agent removes the only person in front of a risky step, say so plainly and recommend against it.
3. **Add or remove a step.** Every step you add is another handoff and another wait. Only recommend adding one if it catches a mistake that would otherwise get through. Say what mistake it catches.

Show the updated map with the changed parts marked, so the user can see what moved.

## Output

For a new map:

1. The parts map: a table with step number, stage, step, who runs it, platform, and the reason.
2. The count: steps, people and handovers, today and with the agent, plus the handovers that remain and why.
3. The approval level, with the reason.
4. What your experts need to write down first: a short list of questions, most important first.
5. The connections the agent needs, each marked "have it" or "to set up".
6. One line: build it now, or not yet, and why. If the job runs rarely, changes every time, or needs a person at most steps, say it isn't worth building yet and suggest a checklist instead.

For a swap:

1. The updated parts map, with changed parts marked.
2. What changed: connections added or removed, and any new wait.
3. Any risk the swap creates, in one line.

## What to tell them at the end

"A workflow is a set of parts: the step, who runs it, and where it runs. Get those right and you can change any one of them without starting again."