How to Build Your First Production AI Agent with n8n

The shape of a real n8n agent

Most tutorials show an agent as one node: trigger goes in, magic AI node does everything, result comes out. Production systems don’t look like that. They look like five distinct pieces:

• Trigger - a webhook, form submission, schedule, or inbound email.
• Retrieval (optional) - pull the context the model needs: a CRM record, a support ticket history, a row from Google Sheets.
• Reasoning step - the LLM call that decides what to do, given the trigger and retrieved context.
• Tool call(s) - the action the agent decided on: send a Slack message, update a CRM field, create a calendar event.
• Human-in-the-loop checkpoint - a pause before anything that can’t be undone (sending an email to a customer, charging a card, deleting a record).

Skip step 5 and you don’t have an agent, you have an unsupervised script with an LLM inside it. The Resilience Engineering playbook in our Agent Dev hub covers what happens when that script hits a rate limit or a malformed response at 2am with nobody watching - worth reading before you flip a workflow from “test” to “active.”

Walking through a real example

Take a lead-qualification agent: a form submission comes in (trigger), the workflow looks up the company domain against a firmographic API (retrieval), an LLM node reads the form answers plus firmographic data and decides whether this is a qualified lead and what tier (reasoning), then either creates a CRM record and Slack-notifies the sales rep (tool call) or - if the model’s confidence is low - routes to a human for manual review instead of auto-qualifying (the checkpoint). That’s the same five-piece shape as the n8n + HubSpot lead-response recipe in the cookbook , just described in agent terms instead of “automation” terms.

Where teams get this wrong

No retrieval step at all. Feeding the LLM only the trigger payload and asking it to “decide” produces plausible-sounding but ungrounded output - the model doesn’t know your CRM’s actual lead-scoring rules unless you put them in front of it.

No confidence threshold. Treating every LLM output as final means every hallucination reaches a customer or a system of record. Add an explicit low-confidence branch, even a crude one (a keyword check, a second cheaper model call, a simple score threshold), before the model’s decision becomes an irreversible action.

One giant prompt instead of a workflow. If your “agent” is a single prompt trying to retrieve, decide, and act all at once, you’ve hidden the five-piece shape inside prose instead of making it inspectable as separate nodes. That’s harder to debug when it breaks, and it will break.

FAQ

Q: Do I need a vector database for this, or is Google Sheets retrieval enough?

A: Depends on what you’re retrieving. Structured lookups (a CRM record, a spreadsheet row) don’t need a vector database at all - a plain API call or Sheets read is faster and easier to debug. Save vector search for genuinely unstructured content like support tickets or documentation.

Q: What counts as “irreversible” for the human-in-the-loop checkpoint?

A: Anything that leaves your system once it runs: outbound emails, payments, record deletions, and any action a customer directly sees. Internal draft creation or CRM tagging is usually safe to automate without a checkpoint.

Q: Can this same five-piece shape work outside n8n?

A: Yes - it’s the same shape LangGraph or CrewAI would give you, just expressed as code instead of a visual workflow. See our framework comparison for when code-first is worth the extra setup.

Originally published on Automations Cookbook.