An "agent" in a slide deck browses the web, books travel, and closes the quarter. An agent you can maintain is a short chain with a human brake.
This lesson is one path in n8n (or a close sibling: Make, a tiny script). The brand on the node does not matter. The shape does.
What we will not claim: that this replaces your team, that it "learns your business," or that it is safe to auto-send customer mail on day one.
The only shape you are allowed to ship first
- Trigger — a form, a labeled mailbox, a button, a schedule
- Fetch — get the record from a system you already trust (helpdesk, sheet, Drive file)
- Prepare — redact / cut to minimum INPUT in the workflow or in a prior human step
- Model — one prompt packet, one job, structured output
- Gate — a human must click approve (n8n wait, email approve, Slack button, or a ticket stays in "needs send")
- Send or write back — only after approve
- Log — input id, output, who approved, timestamp
If your diagram has a loop that talks to four tools until "the goal is met," you are not on lesson one. You are writing a research project.
Pick a job that already passed the earlier lessons
Good first chains:
- New form row → draft a first-line reply from the library → human approves in Slack → send
- A labeled Gmail → extract fields into a sheet → human confirms → create the helpdesk ticket
- Friday 8:00 → pull five support threads → draft the weekly miss list → human edits → post to the ops doc
Bad first chains:
- Inbox → model → send (no fetch of the real status, no gate)
- "Research the account and personalize outreach" (unbounded browse, invented facts)
- Anything that pays, deletes, or grants access
If the job fails when-not-to-use-ai, do not put it in n8n to make it look official.
n8n, concretely (no vapor)
You will need: an n8n instance you control or a plan your company already pays for, credentials for one source system, a model API or a chat node you are allowed to use, and a place for the gate.
Build in this order. Do not skip ahead to "AI Agent" nodes with a toolbox of twenty integrations.
1. Trigger to a dead end
Make the trigger write the raw payload to a test spreadsheet or a Slack message you see. Run it three times. If this is flaky, the model will not save you.
2. Fetch the record
Use the id from the trigger to get the canonical record. The model must not "remember" order status. The helpdesk must say the status.
3. Prepare INPUT
Map fields into the packet. Strip signatures, prior unrelated tickets, and credentials. If you cannot do this in n8n, do a human prep step: the trigger is "operator drops a cleaned file." That still counts.
4. Model node with a boring prompt
One packet. Ask for JSON or a tight markdown shape you can fail closed:
- draft
- eval_self (the model's own checklist — ignore for shipping)
- need_list
- refuse (true if the packet says stop)
If parse fails, do not send. Route to the gate with "parse failed."
5. Gate
Use a wait node, an approval email, or a Slack approve/deny. The deny path writes FAIL into your log. The approve path is the only path that sends.
Do not set a timeout that auto-approves.
6. Send
One channel. The send node uses the approved text, not a second model pass "to polish." Polishing after approval is how invented sentences leak.
7. Log
Append-only. You will need this in week three when someone asks why a customer got a reply.
Copy-paste: packet for the model node
Role: You draft; you do not send; you do not browse; you do not call tools.
Use only INPUT. If a send-blocking fact is missing, set refuse true and fill need_list.
Output exactly these headings:
DRAFT:
NEED:
REFUSE: yes or no
REASON:
Hard constraints: no promises beyond LIBRARY; no invented tracking or dates; no greeting to the wrong name.
>
LIBRARY:
[cards]
>
INPUT:
[mapped fields]
Decision rules
- No gate, no customer send. Internal logs can be ungated if they cannot leave the system.
- One model call per run on version one. Chains of models multiply fluent error.
- Credentials live in n8n credentials, not in the prompt and not in a Google Doc named "temp keys."
- If you need memory, use the system of record, not chat history.
- If the vendor's "AI Agent" node wants a goal and a pile of tools, do not use it for this lesson.
What will still break
- The helpdesk API will rate-limit. Have a retry that does not double-send.
- People will reply on the thread and the next trigger will fire. Filter on label or "only unread in this folder."
- The model will return extra prose around your JSON. Fail closed.
- Someone will clone the workflow and remove the wait node "just for a test" on the live credential. Use a separate test inbox.
Failure modes (the vapor list)
- Goal-seeking agent: "resolve the customer issue" with tools. It will hallucinate a resolution.
- Browse as source: web search inside the chain used as policy.
- Silent retry send: error handler re-posts the email.
- Prompt in the graph, packet in nobody's head: the live prompt is only inside the node. Copy the packet into the same doc as your weekly ops log.
- Autonomy as a feature: marketing copy said "autonomous." Your job is a brake.
You are not behind
A gated five-node workflow that sends ten approved replies a week beats a multi-agent demo that has never touched production data. Ship the boring path. Write what it will not do at the top of the workflow notes.
Download
Build checklist: /downloads/n8n-first-agent-checklist.md
You are done when
A second person can tell, from the log, what was fetched, what the model drafted, who approved, and what was sent — and the deny path has been used on purpose once.