Every time you get a process to automate, run it through this. Ten sections. One complete build spec.
Don't skip ahead. The workflow map has to come before agent specs. Agent specs have to come before skills. Each section builds on the last.
Name it, define the goal, map inputs and outputs, identify how it starts.
Define the shape, every node, every connection, where agents sit. Do this before touching agents.
I/O, tools, confirmation rules, and a full skill set per agent. One agent at a time.
Data sources, connectors, human gates, error cases. Don't skip these — they're where automations break.
Run the checklist before you hand off to a builder or open Gumloop. Catch the gaps now.
Click any section to expand it. Each one covers what to capture and why it matters.
Three fields. Simple but essential — every other section references back to this. If you can't write a clear goal in two sentences, the process isn't ready to automate yet.
Map all five dimensions for both the input and the output. Matching them forces you to fully spec what comes in and what leaves — which is exactly where most automations break. If the output isn't defined, the automation has nowhere to go.
| Dimension | Input — What to Define | Output — What to Define |
|---|---|---|
| Location | Where does the data come from? | Where does it land when done? |
| Method | How does it arrive? (email, webhook, form, API) | How does it get delivered? (API write, Slack message, email) |
| Timing | When does it arrive? (real-time, scheduled, triggered) | When is it expected? (immediately, after approval, daily) |
| Content | What information is in it? | What information comes out? |
| Format | What structure? (JSON, CSV, plain text, form fields) | What structure? (JSON, Slack message, .csv, record update) |
Select all that apply. Then for each one, add the specifics. "Webhook" is not enough — you need to know which system, what event, and what the payload looks like.
Map the workflow before you spec any agents. You need to see the shape of the process, where every node sits, and where agents are placed before you can write a meaningful agent spec. Skipping this creates agents that don't know what they're receiving or passing on.
Steps run one after another. Every node feeds the next. No branches.
Decision points split the path. Different conditions lead to different next steps.
Multiple tracks run at the same time, then reconverge. Faster than sequential.
Steps repeat until a condition is met. Common in polling or retry patterns.
| Agent | Position | Receives from | Passes to |
|---|---|---|---|
| Deal Validator | trigger | HubSpot webhook | Quote Builder (on PASS) |
| Quote Builder | middle | Deal Validator output | Approval Gate |
| Quote Sender | final | Human approval signal | Gmail + HubSpot |
Each agent has its own input and output — not just the process-level ones. An agent in the middle of a workflow receives data from the previous agent, not from the original trigger. Define both sides with the same five dimensions.
| Dimension | Agent Input | Agent Output |
|---|---|---|
| Location | Where does this agent receive data from? | Where does it send results? |
| Method | How does data arrive? (prior agent output, webhook, poll) | How does it deliver? (write to Sheet, call next agent, Slack message) |
| Timing | When is it triggered? (immediately, on event, on schedule) | When does it complete? (synchronous, async, within N seconds) |
| Content | What specific fields does it receive? | What fields does it produce? |
| Format | JSON object? CSV row? Webhook payload? | Structured JSON? Record update? Plain text? |
List every integration with specific actions — not just tool names. Explicitly disable actions the agent doesn't need. Fewer available actions = more predictable, safer behaviour.
Skills are how an agent knows how to do something specific. One skill = one job. Instructions live inside the skill. Data lives externally. The agent sees skill names and descriptions first — only loads the full skill when it decides it's relevant. Vague descriptions = the skill never gets found.
| Field | What to Define |
|---|---|
| Tool | e.g. Notion, Airtable, Google Drive, HubSpot |
| Location | e.g. Notion: /Sales/ICP Criteria, Airtable: Leads table, Drive: /Templates/Quotes/ |
| Variable / ID | e.g. {{notion_page_id}}, {{airtable_base_id}} — how the agent accesses it at runtime |
| Update method | e.g. Edit Notion page directly — agent reads live on every run. No code required. |
Data lives here, not inside agents. Skills contain pointers to this section. Every time an agent needs information, it should come from a named, external data source that a human can update without touching the agent.
Global tools used across the workflow — distinct from per-agent tools in Section 05. For each integration, specify which actions are enabled and which are explicitly disabled. Agents that can do too many things are unpredictable agents.
These are intentional pauses in the workflow where a human must act before anything continues. They exist by design — not because something went wrong. Define each one specifically, including what happens if the human doesn't respond.
Think through what breaks before you build. For every failure scenario: what the agent does first, what it does if that fails, and when a human takes over. Agents without error handling create silent failures — the worst kind.
Run this before you hand off to a builder or open Gumloop. Every unchecked box is a gap that will cost you time mid-build.
Looking to offer automation to your clients?
Take the 2-min quiz →