PTENES
TRACK 5

🟦 Hands-On Projects (End-to-End)

Here, everything becomes a build. Three complete projects, from the opening prompt to the final verification: a RAG email support agent, two hosted agents (scheduled by cron and triggered by webhook) and a full-stack app (Lead Qualifier) with authentication, security, and payment — plus a frontend for an n8n workflow. Each step includes the actual prompt for you to copy, run, and verify.

3
Modules
24
Topics
~4h
Duration
Practical
Level
Learning path progress 0% · 0 of 24
Projects track banner: an idea flowing through teal stages until it becomes a live app
Module 5.1 · runs locally Email support agent + RAG PDF → classify → draft Module 5.2 · in the cloud Hosted agents cron (schedule) + webhook (event) Module 5.3 · in production Full-stack app (Lead Qualifier) frontend · auth · security · payment

The path of track 5: from an agent that runs on your machine to agents that live in the cloud, all the way to a complete product that other people use and pay for.

Learning path map

Detailed content

Illustration for module 5.1
5.1 ~75 min · 8 topics

📧 Project: Email Support Agent with RAG

An agent that reads company policies (PDFs) into a knowledge base, classifies each incoming email, and drafts a response supported by the documents — refusing to make things up when the topic is out of scope. You build two workflows (indexer + agent), connect credentials, test real cases, and apply the 6 enhancements.

Module progress 0% · 0 of 8
What it is:

An agent that turns policy documents (returns, warranties, timelines) into a knowledge base and uses it to answer support emails with evidence.

Why learn:

It’s the “hello world” of useful agents: it combines RAG, classification, and text generation in a real business case.

Key concepts:

Clear scope; draft (no automatic sending); human in the loop for approval.

What it is:

Separate who "learns" (the indexer, which reads PDFs and populates the vector store) from who "answers" (the agent, triggered by a new email).

Why learn:

Separating indexing from querying makes each part simple to test and inexpensive to run.

Key concepts:

Indexer (manual) vs. agent (trigger); shared vector store; embeddings.

What it is:

A single prompt in Plan Mode that describes the complete outcome (trigger, knowledge base, classification, draft, fallback) and lets the AI propose the plan.

Why learn:

A good opening prompt saves hours — the AI asks what’s missing before building.

Key concepts:

Plan Mode first; describe the result; answer the clarifying questions.

What it is:

AI builds the indexer (document loader → text splitter → embeddings → vector store) and the agent (Gmail trigger → classifier → retrieval → draft).

Why learn:

Watching the nodes get created teaches you the anatomy of a real RAG pipeline.

Key concepts:

Run the indexer once; the agent reads from the vector store; test step by step.

What it is:

Connect the email account (OAuth) and the AI key—something YOU do yourself, because the AI doesn't have (and shouldn't have) access to your secrets.

Why learn:

It's the clear boundary between the AI's work and yours; secrets never go in the chat.

Key concepts:

OAuth = authorize without giving your password; API key; the credential stays in the tool.

What it is:

Send test emails for each scenario: one about a return, one about a warranty, and one out of scope (which the agent should refuse, not make up).

Why learn:

Green ≠ correct: only testing with real cases reveals whether the RAG is grounding the answers.

Key concepts:

Edge cases; refuse to make things up; check numbers against the policy.

What it is:

Six incremental improvements in natural language: confidence fallback, time filter, ignore automated emails, adjust the tone, sign with your name, and use a confidence score.

Why learn:

Shows layered iteration in practice — one improvement at a time, testing each one.

Key concepts:

Iterate; request changes in PT; one layer at a time; confidence score.

What it is:

An objective checklist: does it index? classify correctly? cite the document? refuse out-of-scope requests? sign? honor the time filter?

Why learn:

Defining "done" prevents the infinite loop of "one more improvement."

Key concepts:

Definition of done; backup (JSON export); human approves the draft.

Illustration for module 5.2
5.2 ~75 min · 8 topics

⏰ Project: Hosted Agents (Scheduled + Webhook)

Move the agent off your machine and into the cloud, where it runs on its own. You build two: one scheduled (cron → web search with Firecrawl → synthesis → Google Sheets) and a event-based (webhook receives a payload → generates a .docx → saves it to Drive). Along the way: OAuth refresh token, a bug that only shows up in production, Bearer auth, a no-code form, and automatic deploy via GitHub.

Module progress 0% · 0 of 8
What it is:

An agent that wakes up on a schedule (cron), fetches web content (Firecrawl), summarizes it, and writes each row to a spreadsheet — without you present.

Why learn:

It’s the first agent that “lives on its own”—it closes the agentic gap between local and production.

Key concepts:

Cron (5 fields); scraping; synthesis; structured output in Sheets.

What it is:

In the cloud, there’s no login window: the agent uses a refresh token to renew access on its own — and when the interface fails, you retrieve it through the terminal.

Why learn:

It’s the classic hosting friction; knowing the fallback gets your deploy unstuck.

Key concepts:

Access vs. refresh token; automatic renewal; terminal fallback.

What it is:

Errors that don't happen locally (timeout, missing env var, date format) and how to find them by reading the trace and returning the error with context to the AI.

Why learn:

Production has its own reality; the human debug loop is the core skill.

Key concepts:

Trace = step by step; return the error; redeploy; meaningful logs.

What it is:

The second agent: receives a payload via webhook, creates a formatted .docx document and saves it to Google Drive, then returns the link.

Why learn:

Teaches event-based triggering—the agent responds to an external request, not a clock.

Key concepts:

Payload = request data; generate a file; save it and return a link.

What it is:

A webhook is a URL that starts the agent when it’s “touched.” Since it’s public, you protect it with a Bearer token in the header.

Why learn:

Without auth, anyone can ring the doorbell; Bearer is the basic lock.

Key concepts:

Trigger URL; Authorization: Bearer header; reject requests without a token.

What it is:

A simple form (no-code) that, when submitted, sends the request to the webhook with the payload — giving the agent a human-facing interface.

Why learn:

Connects a real person to the agent without you having to write a frontend yet.

Key concepts:

Form → POST; map the fields in the payload; pass the token.

What it is:

Connect the GitHub repository to the hosting platform so every push deploys automatically.

Why learn:

Remove manual deployment from the process; the code in the repo is the source of truth.

Key concepts:

commit/push; deploy on push; .gitignore protects .env.

What it is:

Read the dashboard: each run, its trace (step by step), the active schedule, and the separation between dev and prod.

Why learn:

When you're not there, the dashboard is how you know the agent is healthy.

Key concepts:

Runs; traces; schedules; dev vs. prod; failure alerts.

Illustration for module 5.3
5.3 ~90 min · 8 topics

🚀 Project: Full-Stack App (Lead Qualifier) + Frontend for n8n

The most ambitious project: an app that other people use. A backend that qualifies leads (Trigger.dev) + a frontend (Vercel), connected by env vars. Then you add authentication (Supabase + RLS), run a security audit, charge with Stripe (freemium), and even build a frontend for an n8n workflow (form → webhook). All through incremental iteration: design → auth → payment.

Module progress 0% · 0 of 8
What it is:

The two-endpoint model: the frontend (what the user sees, on Vercel) calls the backend (the agent’s logic, on Trigger.dev), which does the heavy lifting.

Why learn:

Understanding the front/back-end split is what unlocks building products, not just automations.

Key concepts:

Frontend vs. backend; request/response; two separate deploys.

What it is:

An app that receives lead data, scores/qualifies it with AI, and returns the classification — built from a comprehensive opening prompt.

Why learn:

Repeats the “describe the complete result” pattern, now in a full-stack context.

Key concepts:

Fixed inputs; structured output; qualification logic.

What it is:

The frontend discovers where the backend is (and the access key) through environment variables — never through a value written in the code.

Why learn:

It's the seam that lets both ends communicate securely.

Key concepts:

Env var; backend URL; key at runtime, not in the code.

What it is:

Add login (Supabase) and Row Level Security (RLS), which ensures in the database itself that each user sees only their own data.

Why learn:

Without RLS, a valid login can still read someone else’s data; RLS is defense at the data level.

Key concepts:

Auth; RLS; migration; each row belongs to a user.

What it is:

Ask the AI to scan for unprotected routes, exposed keys, env vars leaking to the client, and missing RLS.

Why learn:

An open app = risk: someone could spend your tokens or read someone else's data.

Key concepts:

Attack surface; key on the server; no secrets in the client.

What it is:

Add Stripe Checkout and a freemium model: free use up to a limit, then a paid plan unlocked by webhook.

Why learn:

Turns an app into a product — real revenue with a testable flow.

Key concepts:

Checkout; price ID; webhook secret; freemium; usage limit.

What it is:

Give an n8n workflow a friendly interface: a page with a form that sends data to the flow's webhook and displays the result.

Why learn:

Brings together both sides of the course—n8n automation with an app interface.

Key concepts:

Form → POST webhook; CORS; display the response; webhook URL in env var.

What it is:

The sequence that works: first, an ugly but functional app; then design; then auth; then payment—one layer at a time.

Why learn:

Iterating in layers keeps each step testable and reversible.

Key concepts:

MVP first; one layer at a time; back up before changing anything; test at every step.

← Track 4: Skills & Agents Track 6: Production →