The six clusters follow the path of “taking it off your machine and putting it out in the world”: first, the language of what agentic, then how the AI responds with your data (RAG), where the code lives (version control), how it runs on its own (hosted execution), how it becomes a website (app/frontend), and how it protects itself and charges (security & payment).

Illustrative diagram — Part 2 of the glossary, from the agentic concept to protecting and charging. Each box is a topic below.

What it is

A agent is a system that receives a goal and reasons, adapts, and self-corrects to reach it—instead of following fixed steps. Agentic is the adjective: it describes this “choosing the path” behavior. To build agents in an organized way, there’s the WAT (Workflows / Agent / Tools): W are the markdown instructions (the "manual"), A is the coordinating agent (the “brain”), T are the tools/scripts that do the work.

What makes the agent powerful is the self-improvement loop: it runs, hits an error, diagnoses it, fixes the tool, and updates the manual so the error doesn’t happen again. But there’s a catch: the agentic gap ("agentic gap") — when the agent runs on its own in the cloud, no one is watching to heal it, so reliability becomes your responsibility.

Illustrative diagram — W feeds A (cyan), which triggers T; the dashed line is the self-improvement loop that closes the cycle.

Why learn

These words explain the difference between "it ran in front of me" and "it runs safely on its own." The self-improvement loop is what makes the agent better with use; the agentic gap is why you have to think about reliability from the very first prompt when you're going to host it.

Key concepts

What it is

RAG (Retrieval-Augmented Generation, "retrieval-augmented generation") is the technique of making AI search the right information in your documents before answering — instead of guessing from memory. The documents form the knowledge base ("knowledge base"). The act of searching for and retrieving the relevant passage is called retrieval ("retrieval").

So the agent knows how much it can trust what it found, it can emit a confidence score ("confidence score"): high, medium, or low, depending on how well the knowledge base matches the question. If confidence is low (or nothing is found), the agent refuses to make things up and falls back to a polite plan B ("I'll look it up and get back to you")—the opposite of hallucinating.

Why learn

RAG is what turns a generic chatbot into an agent that answers questions about the your business with verifiable facts. And the confidence score is the safety feature: it makes the agent say “I don’t know” instead of confidently making things up — exactly the behavior you verify with “trust but verify.”

Key concepts

What it is

GitHub is a cloud code repository: the place where code lives, accessible from any machine, with a complete history you can use to roll back. Each project lives in a repo (repository) — the project folder in GitHub. You save changes in commits (snapshots of the project with a description) and sends those commits to the cloud with a push.

To let the assistant operate GitHub through the terminal, use the gh CLI ("GitHub command-line interface"): the tool that connects your machine to your account. And remember the golden rule: the .env (with the keys) never goes into a commit — the .gitignore ensures that.

Why learn

GitHub is the foundation for everything that runs hosted: the code needs to be in the cloud so a runtime service can pull it and run it. The commit history is also your safety net — if something breaks, you can go back to a version that worked. And understanding commit/push/repo lets you follow what the assistant is doing instead of just approving blindly.

Key concepts

What it is

Trigger.dev is a cloud execution engine: it runs your tasks reliably, without timeouts, with retries and logs — like an assistant that gets the work done at the right time. It triggers tasks through cron (a scheduling clock — a 5-field pattern like 0 7 * * * = "7 a.m. every day") or with webhook (a “digital doorbell”: a URL that wakes up the task when it receives data).

The data that arrives through the webhook is the payload ("load"). You build and test in a dev (development) before promoting to prod (production), the live view. Each run leaves a trace (step-by-step trail); failures can trigger retries (retries) and alerts (email/Slack notifications).

Why learn

This is the vocabulary that closes the agentic gap. Without anyone watching, these are the traces that show you what happened, the retries that resolve temporary failures and the alerts that alert you before the user does. Be careful: retries fix temporary errors (network/timeouts), not logic bugs — knowing the difference keeps you from retrying forever.

Key concepts

What it is

O frontend is everything the user sees and interacts with: buttons, forms, text, layout — it runs in the person’s browser. The backend is what runs on the server: the logic, API calls, database — invisible to the user. The two communicate in a request/response ("request/response"): the user clicks → a request goes to the server → it processes it → the response comes back → the screen updates.

To publish a frontend on the internet, use the Vercel: a website hosting service—you push to GitHub and it puts the site online, accessible from anywhere. And the app’s secrets (such as the key that connects the frontend to the backend) stay in env vars (environment variables): values injected at runtime, outside the code.

Illustrative diagram — the frontend (emerald) makes a request, the backend (cyan) processes it and responds. This back-and-forth is the request/response cycle.

Why learn

The frontend/backend separation is the mental model that unlocks understanding any app. It's also what connects your workflow to the world: replace the form trigger with a webhook, and anyone with the URL can use your automation through a polished website—the frontend on Vercel talking to the backend.

Key concepts

What it is

When the app has users, you need to protect data and charge. The Supabase is a database + login (authentication) service. Inside it, the RLS (Row-Level Security, "row-level security") are rules that live in the database itself so one user never sees another user’s data—an extra layer, even if there’s a bug in the frontend. Changes to the database structure are migrations (scripts that create/modify tables).

To receive payments, there’s Stripe. The user pays on a checkout ("checkout"); each plan has a price ID (the price ID). Stripe notifies your app about events (subscribed, canceled) via webhook, validated with a webhook secret (the password that confirms the notification really came from Stripe). A common model is the freemium: a limited free tier + an unlimited paid tier.

Why learn

These terms complete the cycle from "idea → app that safely makes money." Without authentication and RLS, anyone with the URL can use your app (and spend money); without RLS, a bug can leak one user's data to another. And freemium with Stripe is what turns a workflow into a product that pays for itself.

Key concepts