So far the agent has lived in isolation: a question, a tool, a permission, a record. Real agents rarely live alone. They sit inside a wider automation that moves information between inboxes, forms, CRMs, databases, calendars, social accounts, and notification channels. The model supplies judgement or language at one step. Workflow tools move everything else.

This lesson introduces the two workflow systems you will see most often — Make and n8n — and teaches you to read and design the glue safely.

Make vs n8n, honestly

Make is a hosted automation product. You build visual scenarios in its cloud: a trigger fires, modules transform data, connectors call services, results land elsewhere. You operate no servers. You accept its pricing, connector catalog, execution limits, and data boundaries. Check current plans and connectors when you build — they change.

n8n is a visual workflow system you can run hosted by its provider *or* self-host on your own infrastructure. The self-hosted path reuses your Part VII knowledge directly: a Docker package onto a VPS or dedicated Mac mini, a domain with HTTPS, secrets in environment configuration, a database for executions and credentials, plus backups, logs, updates, and monitoring. Self-hosting gives you ownership of code, data, schedules, and credentials — and the full operations burden of any production service.

Either way, keep the layers separate. The workflow tool is not the model, and it is not automatically the agent. It is the visible orchestration layer that can call an agent or model at the exact step where judgement is useful.

Anatomy of an n8n workflow

Every n8n workflow is built from the same parts. Learn the vocabulary before you click:

• Trigger nodes start the run: webhook, schedule, inbox poll, form submission, file arrival.
• Action nodes do things in other systems: create a CRM record, send a message, write a database row, call an API.
• AI / model nodes invoke a model step: classify a message, draft a reply, extract fields, summarize a thread.
• Data-mapping steps reshape fields between nodes — email.subject becomes ticket.title. Most real failures live here, in a misnamed field.
• Conditions branch the flow: high urgency goes to a human now, low urgency joins the queue.
• Error branches define what happens when a node fails: retry, log, notify, stop cleanly.
• Credentials authorize each connection: which account, which scope, stored as secrets — never pasted into node text.
• Execution history records every run: inputs, node outputs, errors, timing. This is your Lesson 31.4 audit trail at workflow scale.

A coding LLM can now create much of this for you — generating the workflow, explaining every node, mapping fields, writing a custom code step, configuring a webhook receiver, diagnosing a failed execution. That is a genuine advantage. But generated nodes are still production automation. You remain the operator, and operation requires understanding six things no LLM can understand for you: what starts the workflow, what data crosses each connection, which credential authorizes it, what the model is asked to decide, where output is written, and what can send or publish automatically — plus how you verify or stop it.

The safe design sequence

Never begin by connecting a live inbox and allowing automatic sends. Build in this order:

manual trigger + test data
  → inspect mapped fields at every node
  → read-only actions first
  → add approval branch
  → log each run
  → only then enable the real trigger

Start manual so runs happen when you press the button, with data you invented. Inspect every mapping — click into each node and confirm the field that arrives is the field the next node reads. Use read-only actions while the logic settles. Add the approval branch before any send, publish, or CRM write. Confirm logging works. Only then attach the webhook, schedule, or inbox trigger. Each step earns the next.

The standard flow and the honest connection paths

Most inbox-to-outcome automations share one shape:

New inbox message / form / calendar event
  → webhook or connector trigger
  → Make or n8n workflow
  → agent classifies, retrieves context, and drafts
  → CRM / help desk / database update
  → approval gate or narrowly allowed send
  → log, status, and follow-up task

Data crosses those arrows over five possible paths, in preference order:

1. Official API or native connector. Preferred when available. Structured data, clear permissions, versioned behavior. 2. Webhook. The source announces the event — new form, payment, message, deployment. Ideal when supported. 3. Email. A shared inbox or forwarding rule turns incoming mail into an event. The agent drafts or replies only within policy. 4. File drop / export. CSV, spreadsheet, cloud-folder upload, or scheduled export ingested when no live API exists. 5. Browser automation. Last resort for a permitted, necessary human-facing workflow. Fragile — layouts and logins change — so it needs stricter testing and supervision.

And the correction that prevents magical thinking: Make and n8n do not grant lawful or reliable access to a service that offers no permitted connection. They coordinate the connections you already have. If a service offers no API, webhook, email, export, or approved browser path, no workflow tool invents one.

Three operating examples

Support inbox. New message → trigger → agent classifies intent and urgency → workflow retrieves account and help-center context → creates a ticket plus a draft reply → human handles exceptions and approves sends. Auto-send only for narrow low-risk replies with logging and an owner.

Marketing pipeline. Approved brief → agent drafts copy and creative direction → editor approval gate → scheduler posts to the authenticated social account → performance data returns to a review dashboard. The agent never invents claims or spends on ads without boundaries.

Sales lead workflow. Form or webhook → enrichment step → CRM record created → agent prepares a personalized draft → salesperson approves or edits → follow-up status recorded. Speed comes from drafting; trust comes from the salesperson's review.

Check your understanding

1. What is the difference between Make, n8n hosted, and n8n self-hosted? 2. Name the eight parts of an n8n workflow. 3. Why does the safe sequence start with a manual trigger and read-only actions? 4. List the five connection paths in preference order and say when browser automation is acceptable.

Exercise: create AGENT-AUTOMATION-MAP.md

Map one real workflow you might run — support inbox, content pipeline, or lead follow-up.

# AGENT-AUTOMATION-MAP.md — [workflow name]

## Trigger
- Source event:
- Trigger type (webhook / schedule / inbox poll / form / file):

## Connectors (each arrow)
| From → to | Path (API / webhook / email / file / DB / browser) | Credential + scope |
| --- | --- | --- |

## Data fields (crossing each connection)
- Fields in:
- Fields mapped / renamed:
- Fields out:

## Model / agent step
- What the model is asked to decide or draft:
- Context it may read:
- What it may NOT do:

## Write destination
- Where results are written (CRM / DB / ticket / scheduler):
- Test vs production target:

## Approval gate
- What pauses for human review:
- Approver + what they see + reject behavior:

## Error path
- On node failure (retry / log / notify / stop):
- Duplicate / retry handling:

## Audit log
- Execution history location:
- Run record / handoff location:
- Owner:

Finish line: one completed AGENT-AUTOMATION-MAP.md where every arrow names its path and credential, the model step states its limits, and no consequential send or write bypasses the gate.

Verification: point at each arrow and ask "what connection is this, and whose credential authorizes it?" If any arrow is unlabeled or any credential is broader than the step needs, fix it. Run once with test data and confirm the execution history matches the map.

Next, Lesson 31.6 rings the doorbell: webhooks start agent work — and the receiver, validation, queueing, and event contract decide whether that work stays bounded.