Workshop

Hands-On n8n Workshop: Build Your First Agentic AI Workflow

By Syed Hussnain Sherazi | May 18, 2026 | n8n | Agentic AI | Workflow Automation | RAG

A hands-on n8n workshop for building an AI agent with chat, memory, calendar tools, RAG document retrieval, and an image generation sub-workflow.

AI agents become easier to understand when you stop treating them as abstract intelligence and start wiring one together. n8n is a useful place to learn that because every part of the agent is visible: the trigger, the model, the memory, the tools, the credentials, the execution log, and the failure points.

This workshop is based on Session 20 of the Applied Generative AI Bootcamp. The aim is not to build a production platform in one sitting. The aim is to build the working pattern behind many production AI systems: a conversation enters the workflow, an agent reasons over the request, tools perform the real actions, and the execution log shows what happened.

By the end, the agent can schedule meetings without obvious calendar conflicts, answer questions from uploaded documents using retrieval augmented generation, and generate images through a separate workflow. The final result is simple enough to understand and complete enough to reuse.

What You Build

The workshop has five stages:

1. Set up n8n locally and learn the workflow canvas.
2. Build a basic AI agent with a chat trigger, OpenAI chat model, memory, and a calculator tool.
3. Replace the calculator with Google Calendar tools so the agent can search availability and create events.
4. Add RAG so the agent can answer questions from files stored in Google Drive and indexed in Pinecone.
5. Add a sub-workflow that turns an image request into a Flux image generation call.

The finished system looks like this:

flowchart LR
  USER["User chat message"] --> CHAT["n8n chat trigger"]
  CHAT --> AGENT["AI Agent node"]
  AGENT --> MODEL["OpenAI chat model"]
  AGENT --> MEMORY["Window buffer memory"]
  AGENT --> CAL["Calendar tools"]
  AGENT --> RAG["Document retrieval tool"]
  AGENT --> IMG["Image generator sub-workflow"]

  CAL --> GCAL["Google Calendar"]
  RAG --> DRIVE["Google Drive"]
  RAG --> PINE["Pinecone vector store"]
  IMG --> PARSER["Prompt parser"]
  PARSER --> FLUX["Flux image API"]

  GCAL --> AGENT
  PINE --> AGENT
  FLUX --> AGENT
  AGENT --> REPLY["Chat response"]

Before You Start

You need a computer running macOS, Windows, or Linux. n8n runs wherever Node.js runs. You also need:

• Node.js, used to install and run n8n locally.
• A Google account for Calendar and Drive.
• An OpenAI account for the chat model and embeddings.
• A Pinecone account for vector search.
• A Black Forest Labs account if you want to complete the image generation module with Flux.

For learning, the local self-hosted n8n setup is enough. You do not need n8n cloud unless you want workflows to run continuously while your laptop is off.

The Core Concepts

The important terms are easier to learn once they are attached to a workflow:

Module 1: Set Up n8n Locally

Start by installing n8n on your machine through npm. After installation, run `n8n` from the terminal. The terminal prints a localhost URL, and n8n opens in your browser.

The first practical goal is simple: create a new workflow, save it, rename it, add a sticky note, and find the Executions tab. This sounds basic, but it is important. The Executions tab is how you debug agent systems. When the agent behaves unexpectedly, do not guess. Open the execution and inspect each step.

The local version is useful for learning because it gives you full visibility and no monthly platform fee. The trade-off is that workflows only run while n8n is running on your machine. Once a workflow becomes operationally important, move it to n8n cloud or a small VPS.

Module 2: Build Your First AI Agent

The first agent uses four pieces:

• Chat Message trigger
• AI Agent node
• OpenAI Chat Model
• Window Buffer Memory
• Calculator tool

The calculator is intentionally simple. It proves that the agent can decide when to call a tool instead of answering directly.

flowchart LR
  CHAT["Chat message trigger"] --> AGENT["AI Agent"]
  AGENT --> MODEL["OpenAI chat model"]
  AGENT --> MEMORY["Window buffer memory"]
  AGENT --> TOOL["Calculator tool"]
  TOOL --> AGENT
  AGENT --> ANSWER["Answer in chat"]

Inside the AI Agent node, leave the prompt source connected to the chat trigger. Attach the OpenAI chat model under the Chat Model slot, then add Window Buffer Memory under the Memory slot. A context window of five turns is enough for this exercise.

After that, attach the Calculator under the Tool slot. Save the workflow and test it with two prompts:

1. Ask a normal question such as `what is your favourite colour?`
2. Ask a maths question such as `what is 2 + 2?`

The first prompt should be answered directly by the model. The second should cause the agent to call the Calculator tool. Open the execution log and check the sequence. The important learning is not the answer `4`; it is seeing the agent choose a tool, pass data into it, receive output, and use that output in the final response.

Module 3: Turn It Into a Calendar Agent

The calendar agent replaces the calculator with useful tools. A scheduling assistant needs at least two capabilities:

• Read availability from the calendar.
• Create an event when a suitable time is found.

One tool is not enough. If the agent can only create events, it may book over existing commitments. If it can only search, it cannot complete the task. Reliable agents usually need both read and write tools.

flowchart LR
  USER["Meeting request"] --> AGENT["AI Agent"]
  AGENT --> SEARCH["Search availability tool"]
  SEARCH --> CAL["Google Calendar"]
  CAL --> SEARCH
  SEARCH --> AGENT
  AGENT --> CREATE["Create event tool"]
  CREATE --> CAL
  CAL --> AGENT
  AGENT --> CONFIRM["Confirmation to user"]

The longest part of this module is Google OAuth setup. You create a Google Cloud project, enable the Calendar API, configure the OAuth consent screen, and paste the redirect URI from n8n into Google Cloud exactly. Most connection issues come from a mismatch in that redirect URI.

Once the credential is working, configure two Google Calendar nodes as tools:

• A tool for checking availability.
• A tool for creating calendar events.

Then write a system prompt that tells the agent how to behave. The prompt should define the agent as a calendar assistant, tell it to check availability before booking, ask for missing information, and confirm the event details after creating an event.

One small detail matters: the model does not automatically know today's date in the way your workflow needs it. Add date awareness to the prompt with an n8n expression so the agent can interpret requests like `tomorrow afternoon` correctly.

Module 4: Add RAG So the Agent Can Use Documents

RAG keeps document knowledge outside the prompt. Instead of pasting whole PDFs into the model context, you split documents into chunks, embed those chunks, store them in a vector database, and retrieve relevant chunks when the user asks a question.

This workshop uses Google Drive as the file source and Pinecone as the vector store.

flowchart LR
  DRIVE["Google Drive file"] --> DOWNLOAD["Download file"]
  DOWNLOAD --> CHUNK["Split into chunks"]
  CHUNK --> EMBED["Create embeddings"]
  EMBED --> PINE["Store vectors in Pinecone"]

  QUESTION["User document question"] --> AGENT["AI Agent"]
  AGENT --> RETRIEVE["Retrieve relevant chunks"]
  RETRIEVE --> PINE
  PINE --> RETRIEVE
  RETRIEVE --> AGENT
  AGENT --> ANSWER["Grounded answer"]

There are two workflows in this pattern:

1. An ingestion workflow that reads files, chunks them, creates embeddings, and stores them in Pinecone.
2. A retrieval path in the main agent that searches Pinecone when the user asks about documents.

The embedding model must match on both sides. If you use `text-embedding-3-small` during ingestion, use the same model during retrieval. Embedding mismatch is one of the easiest ways to get a silent failure where retrieval technically runs but returns poor or empty results.

The system prompt should also be explicit. For questions about uploaded documents, tell the agent to use the retrieval tool first. Without that instruction, the agent may answer from general knowledge, which defeats the purpose of RAG.

Module 5: Add an Image Generator Sub-Workflow

The image generator is a good place to use a sub-workflow. Image generation has its own complexity: prompt cleaning, HTTP requests, asynchronous waiting, and result polling. Keeping that inside the main agent workflow would make the canvas harder to understand.

The main agent only needs one tool: call the image generator workflow with the user's image request.

flowchart LR
  USER["Generate an image request"] --> MAIN["Main agent workflow"]
  MAIN --> CALL["Call n8n workflow tool"]
  CALL --> SUB["Image generator sub-workflow"]
  SUB --> PARSE["OpenAI structured parser"]
  PARSE --> POST["POST prompt to Flux"]
  POST --> WAIT["Wait"]
  WAIT --> GET["GET generated result"]
  GET --> SUB
  SUB --> MAIN
  MAIN --> URL["Return image URL"]

Flux follows an asynchronous API pattern:

1. Send a POST request with the image prompt.
2. Wait for the model to finish.
3. Send a GET request to retrieve the generated result.

During development, pinning mock data in n8n is useful because it lets you test the sub-workflow without repeatedly calling the main agent. Before going live, unpin the mock data. If every image request returns the same result, pinned test data is usually the reason.

Common Failure Points

Most errors in this workshop are not mysterious. They usually come from one of these places:

What This Workshop Teaches

The finished system is small, but the patterns are serious:

• The agent is not the whole system. It is the orchestrator.
• Tools need clear descriptions because the model uses those descriptions to decide what to call.
• Memory is useful, but it is not a database.
• RAG is a retrieval pattern, not a magic knowledge upload.
• Sub-workflows keep complex tool actions understandable.
• Execution logs are the main debugging surface.

These are the same patterns used in larger AI products. Production systems add stronger authentication, error handling, monitoring, audit logs, rate limits, and deployment infrastructure. The underlying shape is still recognisable: trigger, agent, model, tools, retrieval, action, response.

Practical Starting Points

After completing the workshop, rebuild the system from memory once. Do not copy every step. Notice where you hesitate. Those pauses show which concepts still need practice.

Then swap one service:

• Replace Google Calendar with Notion or Airtable.
• Replace Pinecone with Qdrant or Supabase pgvector.
• Replace Flux with another image API.
• Replace the chat trigger with a scheduled trigger or webhook.

That is where the learning becomes transferable. Vendor details change, but the agent pattern stays the same.

The best next version is not a bigger demo. It is a small workflow that solves one real problem you face every week. Build that, inspect the executions, fix the weak points, and only then think about hosting it permanently.