Understand the Process
Name it, define the goal, map inputs and outputs, identify how it starts.
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.
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.
Name it. Define the goal. Set the context. 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.
What is this called? e.g. "Lead Qualification Pipeline", "AP Invoice Processing", "Employee Onboarding"
What does this process achieve when it works perfectly? One or two sentences. Be specific, "save time" is not a goal.
Constraints, existing tools in use, team involved, edge cases you already know about, anything that shapes how this gets built.
Five dimensions. Both sides. Full handoff spec. Map all five 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.
| 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) |
How does the process start? Be specific. 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.
Shape → nodes → connections → agent placement. Map the workflow before you spec any agents. You need to see the shape, where every node sits, and where agents are placed before you can write a meaningful spec.
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.
// List every node. Link agent nodes to a named agent.
Node 1: [trigger] , HubSpot stage change: "Ready to Quote"
Node 2: [agent] , Deal Validator → Agent: Deal Validator
Node 3: [decision], Validation passed?
Node 4: [agent] , Quote Builder → Agent: Quote Builder
Node 5: [human] , Approval Gate → Gate: Manager Approval
Node 6: [agent] , Quote Sender → Agent: Quote Sender
Node 7: [end] , Quote sent, HubSpot updated Node 1 → Node 2 Node 2 → Node 3 Node 3 → Node 4 (if PASS) Node 3 → Node 7 (if FAIL, alert rep, stop) Node 4 → Node 5 Node 5 → Node 6 (if approved) Node 5 → Node 7 (if rejected) Node 6 → Node 7
| 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 |
One block per agent. Repeat for every agent in the workflow. Each agent has four areas to spec, Overview, I/O, Tools, Skills. Never combine two jobs into one agent.
Kebab-style is fine: lead-enrichment-agent, quote-builder, approval-router. The name tells you exactly what it does.
Single sentence. What does this agent do and why does it exist? If you can't write this in one sentence, the scope is too broad, split it into two agents.
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.
EXAMPLE, QUOTE BUILDER AGENTEvent-driven (called by prior agent) / Scheduled (cron time) / Manual / Agent handoff. Specify exactly when this agent activates.
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.
SKILL STRUCTURE, 3 BLOCKS// Step-by-step process 1. Check if lead has company email domain 2. Search enrichment tool for company data 3. Score lead 1–10 based on ICP criteria (read from Notion) 4. IF score ≥ 7 → mark as qualified, continue to routing 5. IF score < 7 → log to nurture list, stop flow // Decision logic IF company email missing → stop, flag for human IF company size > 500 → add "enterprise" tag IF score is ambiguous → default to human review // Rules & constraints ⚠ Never fabricate missing company data ⚠ Always log score reasoning alongside the score ⚠ Stop immediately if required field is nullBLOCK 2, EXTERNAL REFS FORMAT
| 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. |
// Examples, sample input → output pairs Input: { name: "Jane Smith", email: "jane@acme.com", company: "Acme Corp" } Output: { score: 8, qualified: true, tags: ["mid-market"], reason: "200 employees, ICP match" } Input: { name: "Bob", email: "bob@gmail.com", company: "" } Output: { score: 0, qualified: false, flag: "missing_company" } // Resources - ICP criteria doc → Notion: /Sales/ICP Definition - Scoring rubric → Airtable: Lead Scoring table - Email templates → Drive: /Templates/Outreach/ // Scripts, reusable logic const score = (companySize > 200 ? 4 : 2) + (hasWorkEmail ? 2 : 0) + (industryMatch ? 3 : 0) + (budgetSignal ? 1 : 0)
Map every source the workflow reads from or writes to. 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 source a human can update.
Global integrations. Enable only what's needed. 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.
Intentional approval checkpoints. Not error handlers. These are designed pauses where a human must act before anything continues. Define each one, including what happens if the human doesn't respond.
Quote Builder Agent has generated and saved a PDF. Approval Router sends a Slack interactive card to the deal owner's manager.
Review the PDF via Drive link → click Approve or Reject in Slack. On Reject: add a reason, the thread is opened to the rep.
No response in 4 hrs → reminder sent. No response in 8 hrs → escalate to RevOps manager. Reject without reason → Slack prompts for one before logging.
Map failure scenarios before they happen. For every failure: 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.
Route on form data only. Flag "Enrichment unavailable" in Slack card. Rep verifies manually, flow not blocked.
⚠ NO ESCALATION, GRACEFUL DEGRADATIONHard stop. Never guess pricing. Alert RevOps with deal ID and error details. Wait for manual intervention.
⚠ ESCALATE IMMEDIATELY TO REVOPSStop flow. Write error to tracker. Slack alert to workflow owner with field name and record ID. Do not continue with defaults.
⚠ ESCALATE, HUMAN MUST RESOLVEHard stop. Alert AP manager with both records. Do not process either until human confirms which is valid. Log both to Duplicates tab.
⚠ ESCALATE IMMEDIATELYRun this before you hand off to a builder or open Gumloop. Every unchecked box is a gap that will cost you time mid-build.
30 minutes. We listen, we map your bottleneck, we tell you straight whether we can help and what it'd cost. No deck. No pressure. Either you walk away with a plan or you walk away with clarity.