← All sessionsHomeSearch
Outskill GenAI Learning Portal·Learning Topics·

Learning Topics: Sessions 1–5 — Foundations to AI Director

Outskill (portal authors) Written portal content from the weekend GenAI event — no individual trainer credited; the text is the course's own didactic voice

Session map

FOUNDATIONSASSISTANTS & APPSAUTOMATION & MEDIAAI hierarchy + 5 stagestokens → variationMagic Promptfive layers of contextModel selectionjob to be done12-job toolkitorchestration over productsVerify & classifyhuman owns the decisionBot → project → employeeautonomy is earnedXML promptsdiagnosable by tagStyle DNAvoice with evidenceApp anatomyfront · back · dataBuilder laddersimplest surface firstPlan before buildbrief → loop → done-listTrigger→transform→decide→actrule · LLM · agent · humanAI Directoringredients · motion · credits
FoundationsAssistants & appsAutomation & media
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — foundations flow into assistants & apps, then into automation & media. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. The portal's written spine: five sessions carrying 88 learning sections, ~11,300 words of already-didactic text — foundations of LLMs and prompting, building assistants, vibe coding, n8n automation, and AI image/video direction.
  2. Session 1's twin frameworks: the five-stage LLM mental model (tokenization → embeddings → attention → prediction → variation) and the five-layer 'Magic Prompt' (Identity · World · Task · Examples · Constraints) — context engineering as onboarding a new employee.
  3. Session 2's ladder: simple bot → specialized project (XML-structured system prompt + Style DNA + knowledge) → AI employee with tools, schedule and delegation boundaries. Autonomy is earned through tested runs, never assumed.
  4. Sessions 3–4 are the Catalyst overlap: app anatomy (front end / back end / database), the builder ladder, plan-before-build, and n8n's trigger → transform → decide → act — with the rule-vs-LLM-vs-agent-vs-human decision discipline stated more cleanly than anywhere in the recorded sessions.
  5. Session 5 reframes generation as direction: the eight-ingredient image-prompt framework, motion-sentence video prompts, credit discipline (test cheap, finish premium), continuity management, and non-negotiable consent/rights.

The concepts

01

The AI hierarchy and the five-stage LLM mental model

Place LLMs inside deep learning, deep learning inside machine learning, machine learning inside AI — then open the LLM up into five stages.

The portal's foundation is two nested pictures. First the hierarchy: artificial intelligence is the broad family; machine learning learns patterns from data; deep learning stacks layered networks for perception; large language models are deep-learning models trained on language; generative AI is the application layer that creates rather than classifies. The portal is explicit that it teaches *using* generative models, not training networks.

Second, how an answer actually gets made — five stages: tokenization (input cut into tokens, 'like a chef cutting a vegetable'), embeddings (tokens as numbers where similar concepts sit near each other, like map locations), attention (weighing what matters — 'a torch on the correct row in a dark cinema'), prediction (estimating the next token), and variation (repeated sampling produces a full answer, differently worded each run). Variation is expected, not an error — but important claims still require verification.

Worked example · from the session

The portal's suggested exercise: 'Explain LLMs like I'm five', then 'explain the same to a CFO' — watching what the audience layer changes is the fastest way to feel context at work.

Why it matters

This is the same ground Catalyst's Basecamp 1 and 5 covered by video, here in a quotable written form — the KB's most re-usable plain-language explanation of what a model is doing.

People get this wrong

An LLM retrieves the memorized answer to your question.

It repeatedly predicts a likely next token in context — a 'smart parrot' with autocomplete mechanics, which is why grounding and verification matter.

Go deeper

In one line: Hierarchy: AI ⊃ machine learning ⊃ deep learning ⊃ LLMs, with generative AI as the creation-focused application layer. LLM answer production in five stages: tokenization, embeddings, attention, prediction, variation — probabilistic sampling means same prompt, differently-worded answers, which is expected behavior, not failure.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Recite the five stages and one analogy for each.

Tokenization (chef cutting vegetables), embeddings (nearby places on a map), attention (torch on the right cinema row), prediction (next-token estimate), variation (re-sampled wording each run).

Two runs of the same prompt disagree in wording. Broken?

No — sampling is probabilistic, so variation is expected. What it does mean: verify material claims rather than trusting fluency.

02

The Magic Prompt: five layers of context engineering

Prompt engineering is a better instruction; context engineering is everything a capable new employee would need before doing the task.

The portal's central analogy: 'prepare a report' is an instruction, but a new employee still needs the company, audience, decision, data, standard, and constraints. AI is the same — intelligence without context produces generic work. The Magic Prompt structures that context in five layers: Identity (who the model acts as), World (situation, business, audience, background), Task (the exact outcome), Examples (what strong looks like), Constraints (length, tone, boundaries, exclusions, format).

The template ends with a power move: 'Before answering, identify any missing context that would materially change the result.' And iteration is doctrine: the first output is a draft — compare against intent, name ONE gap precisely, request ONE targeted revision. Never 'make it better'; instead 'reduce to 150 words, keep the two calculations, remove jargon, end with one decision question.'

Worked example · from the session

The worked example: 'write about renting vs buying' is useless until it gains the Indian first-home audience, the ₹10–30 lakh income band, 200 words, low jargon, balanced pros/cons, and a personal-finance-column style — then it's an assignment a professional could execute.

Why it matters

This is the portal's single most reusable asset — the template transfers to every model and every task, and it's the written counterpart of Basecamp 1's context-engineering session.

People get this wrong

Better prompting means finding magic words.

It means supplying the context a competent new hire would need. The layers are onboarding, not incantation.

For your projects

The KB's own extraction prompts already follow this shape implicitly; the five-layer template is the checklist to audit them against.

Go deeper

In one line: Context engineering via five layers — Identity / World / Task / Examples / Constraints — plus a missing-context check, and an iteration loop of one named gap → one targeted revision per cycle. Instruction without context produces generic work.

Try it now

Take the last prompt that disappointed you and rewrite it through the five layers. The delta in output quality is the lesson.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Name the five layers and the closing instruction the template adds.

Identity, World, Task, Examples, Constraints — closing with 'identify any missing context that would materially change the result.'

What's wrong with 'make it better' as a follow-up?

It names no gap. The loop is: compare with intent, name one precise gap, request one targeted revision — repeatable and diagnosable.

03

Job-to-be-done model selection and reasoning models

Pick models by the job, not the brand — and reserve 'thinking' models for questions a human would need to work through.

The selection principle: fast general models for direct low-risk tasks; reasoning models when trade-offs, calculations or ambiguity need working through; source-grounded tools when the answer must come only from known documents; multi-model comparison when quality is subjective or consequential; and a primary-plus-backup pair for important work categories. Leaderboards change — the durable habit is comparing outputs yourself.

For decisions, the portal's prompt pattern insists the human stays the decision-maker: show assumptions and calculations, give two contrasting strategies with the conditions under which each wins, name the risks and open questions — 'Do not make the decision for me.' That closing line is the discipline.

Worked example · from the session

The rehearsal task: the same treasury-yields question run in two to four models, scored 1–5 on clarity, factual caution, depth, speed, citations, instruction-following, usefulness — teaching personal evaluation over ranking-trust.

Why it matters

Model names in this content are the KB's most perishable material; the job-to-be-done frame and the don't-decide-for-me pattern are the durable residue.

People get this wrong

There is a best model, and using it for everything is optimal.

There are jobs. Matching model class to job — and comparing when it matters — beats brand loyalty every time the landscape shifts.

Go deeper

In one line: Selection by job: fast general (low-risk direct), reasoning (trade-offs/calculation/ambiguity), source-grounded (must answer from supplied documents), multi-model comparison (consequential/subjective), primary+backup per category. Decision prompts end 'Do not make the decision for me' and demand assumptions, contrasting strategies, and risks.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

When does a task earn a reasoning model?

When a human would need to work through trade-offs, calculations, or ambiguity — investing vs prepaying, business trade-offs, complex analysis. Low-risk direct tasks stay on fast general models.

What does the decision-prompt pattern refuse to delegate?

The decision itself. The model surfaces assumptions, scenarios, swing factors and uncertainty; the human owns the final call.

04

The twelve-use-case toolkit and orchestration

The toolkit isn't twelve products — it's twelve jobs, and the real skill is chaining one tool's output into the next tool's input.

The portal's toolkit is deliberately job-first: voice dictation for prompts longer than typing (Wispr Flow), meeting memory (Fireflies), source-grounded Q&A with citations (NotebookLM), multi-source deep research, voice role-play for interviews and hard conversations, data-analysis dashboards, product creative (Phot.AI), personal-brand drafting (Supergrow), warm-referral search (Happenstance), agentic browsing (Comet), many-local-files analysis (Claude Cowork), and task-led tool discovery (There's An AI For That).

Each entry ships a verbatim starter prompt and a stated limitation. The meta-lesson is orchestration — the demonstrated pattern chains a browser agent's profile summary into a voice-interview rehearsal. And the directory itself is flagged as a dated snapshot: verify availability, price, privacy terms before relying on any named product.

Worked example · from the session

The orchestration demo: Comet crawls the learner's own professional profile into a verified summary → that summary becomes the context pack for the voice-mode mock interview — two tools, one workflow.

Why it matters

This is the portal's capability-library core: twelve reusable job-shapes with starter prompts, exactly the repertoire the KB exists to make addressable.

People get this wrong

Being an AI generalist means knowing many AI products.

It means recognizing which job a problem is, reaching for that category, and chaining results — the products are interchangeable.

For your projects

Several toolkit categories are already your daily stack (Cowork = local multi-file work, this KB = source-grounded Q&A). The gaps worth trying: voice role-play for client calls and warm-path search for law-o-matic outreach.

Go deeper

In one line: Twelve job categories with named example tools (June–July 2026 snapshot), each with a verbatim starter prompt and limitation. Durable content: the job taxonomy and the orchestration principle (one tool's output is the next tool's input); perishable: every product name, price and feature.

Dictation, meeting memory, source-grounded Q&A, deep research, voice role-play, data dashboards, product creative, brand drafting, network search, agentic browsing, local multi-file work, tool discovery — the full twelve

Every tool entry carries a stated limitation (consent for meeting bots, data policy for dictation, citations to be opened, smallest folder scope for local work)

Discovery is task-led: search 'the work to be done', not tool names

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What makes the toolkit durable when every product in it will churn?

The twelve jobs and the orchestration principle. Products are cameras; the shot list is yours.

Before adopting a directory tool, what four things does the portal say to verify?

Current availability, price, privacy/data terms, and whether a general tool you already have covers the need.

05

The privacy and accuracy protocol: human at the decision point

Classify data before it goes up; verify claims before they go out; keep a person at every decision and external action.

The portal's nine-step protocol is the safety spine of the whole course. Before upload: classify the data (public / internal / confidential / regulated / prohibited); if it can't leave the organization, use an approved private or local deployment and accept the capability trade-offs. On the way out: prefer cited outputs and open the citations; spot-check two or three material claims; reproduce at least one calculation independently; ask the model to self-audit but never count self-audit as independent verification; for high-impact work, have a second model critique the first and resolve disagreements with source evidence.

The record-keeping step is the professional tell: log assumptions, model, source date, and human reviewer. And the closing principle: AI expands the calculation; the person with authority owns the decision and the external action.

Worked example · from the session

The applied activity: one real two-option decision, run through a reasoning model with full context, then two factual claims or one calculation verified independently, and the prompt revised based on what verification found.

Why it matters

Every other concept in the portal assumes this one. It's also the cleanest written statement of the human-in-the-loop stance that recurs across all of Catalyst.

People get this wrong

Citations mean the output is verified.

Citations mean the output is checkable. Verification happens when you open them.

AI expands the calculation; the person with authority owns the decision and external action.
Go deeper

In one line: Nine steps: classify data pre-upload; private/local deployment for restricted data; prefer and open citations; spot-check 2–3 material claims; reproduce one result independently; self-audit is not verification; second-model critique for high-impact work; record assumptions/model/date/reviewer; human owns decisions and external actions.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

The model double-checked its own work and found no errors. What's that worth?

It's self-review — useful, but never independent verification. Independent means you, a reproduction, or a second model resolved against source evidence.

What five classes does data fall into before any upload decision?

Public, internal, confidential, regulated, prohibited — the class decides whether it can touch a hosted model at all.

06

Bot → project → AI employee: the assistant ladder

Don't jump to the autonomous agent — each rung of the ladder depends on the one below it.

The progression: a simple custom bot (topic in, LinkedIn post out) fails instructively — thin instruction, thin assistant. A specialized project adds a detailed system prompt, style knowledge, examples, and persistence. An AI employee adds a goal, file and tool access, a working checklist, research, and eventually a schedule.

Two governing tests. Suitability: the task repeats, a good result is describable, it follows a pattern, examples exist, a trained junior could do it, and an imperfect draft is survivable. Delegation boundaries: define what it may read, create, change; what needs approval; cost/step ceilings; failure behavior; and how output is logged — 'start with drafts and recommendations; expand authority only after repeated, reviewed success.' The employee analogy carries the whole design: intelligence doesn't replace onboarding.

Worked example · from the session

The demonstrated employee: goal (find promising content ideas and draft posts), research instruction, historical performance data, Style DNA, and a compare-select-explain-draft process — run over a dedicated local folder, scheduled at 7 AM only after repeated manual success.

Why it matters

This ladder is the org chart for every assistant you'll ever build — and the delegation-boundaries list is the missing safety spec in most agent tutorials.

People get this wrong

A smarter model makes the ladder unnecessary — just ask the big model to do everything.

The ladder is onboarding, not compensation for weak models. A good manager gives tools, data, process, standards, feedback — intelligence alone does not replace that.

A bot answers; an assistant uses role, examples, and knowledge; an AI employee adds tools, schedule, memory, evaluation, limits, and human escalation. Autonomy is earned through tested runs.
Go deeper

In one line: Three rungs: bot (single transform), project (system prompt + knowledge + persistence), employee (goal + tools + data + process + schedule). Suitability test for the task; delegation boundaries (read/create/change/approve, cost ceilings, failure handling, logging); autonomy earned through evaluated runs.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What does the employee rung add that the project rung lacks?

Tools, a goal it decomposes into a checklist, data access, a schedule, and evaluated autonomy — a project answers when asked; an employee works.

What authority does a new AI employee start with?

Drafts and recommendations only. Write, send, purchase and delete arrive after repeated reviewed success — same as a human hire.

07

XML-structured system prompts and the tuning matrix

The tags aren't code — they're labels that make a prompt diagnosable: tone failure points to writing_style, invented facts point to do_not.

The structure: role; context (creator, audience, writing_style); task (input, goal); ordered instructions; constraints (do_not, must_do); output_format. Its value is diagnosis — when the assistant fails, exactly one section owns the failure, so you edit that tag and re-test rather than rewriting everything.

The portal doesn't ask beginners to author this by hand: describe the use case in plain language and have the model generate the full structured prompt ('the prompt generator'), then inspect. Testing doctrine: an easy case, a vague case, and an edge case; rate format, tone, correctness, grounding, safety; fix ONE tag at a time. Real guardrails start with 'Never' — the production examples ban 'Excited to share', invented metrics, and corporate filler by name.

Worked example · from the session

The Outskill LinkedIn-writer prompt, production-condensed: role (sharp practitioner voice), audience (hype-averse professionals), do_not ('Never open with Excited to share… Never invent metrics'), output_format (one 150–300-word post + three hooks).

Why it matters

This is the exact discipline the KB's own skills and extraction prompts need — structured, diagnosable, one-tag fixes. The tuning matrix (failure → tag) is a reusable table on its own.

People get this wrong

XML tags make the model behave differently because models 'speak XML'.

They're clear labels for humans and models alike — the win is diagnosability, not syntax magic.

Go deeper

In one line: Six-part XML shape (role / context / task / instructions / constraints / output_format) whose payoff is per-tag diagnosis: tone→writing_style, ignored rule→must_do/do_not, wrong shape→output_format, wrong steps→instructions, invented facts→grounding+knowledge. Generate the first draft with AI, then test easy/vague/edge and tune one tag at a time.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

The assistant nails tone and facts but returns prose when you need a table. Which tag?

output_format — and only that tag. One targeted edit, then re-run the three-case test.

Why generate the system prompt with AI instead of writing it?

The structure is the quality control, not the authorship. Describing the job in plain language and inspecting the generated block is faster and usually more complete.

08

Style DNA: capturing a voice with evidence

Five to ten strong samples in, one evidence-backed voice description out — approved by the human before anything automates it.

The protocol: supply 5–10 posts with variety (story, list, analysis, opinion) and demand analysis of tone, first-line hooks, structure and line breaks, sentence rhythm, vocabulary, use of stories and proof, recurring themes, and closing patterns — with short quoted evidence for every claimed trait, and consistent patterns separated from one-off quirks. The output is a 5–6 line summary that pastes into a system prompt's writing_style tag.

The governance point matters as much as the technique: the learner approves the DNA before the voice is automated. 'A model's description is an analysis, not permission to add traits the creator never used.'

Worked example · from the session

The workbook flow: samples → evidenced DNA → human approval → DNA into the writing_style tag, with originals retained as reference knowledge.

Why it matters

This is the difference between an assistant that writes like you and one that writes like the internet's average — and it's the reusable pattern behind every brand-voice tool.

People get this wrong

More samples always make a better style profile.

Variety and strength beat volume: 5–10 strong, varied posts with evidence-checked analysis outperform 50 uncurated ones.

For your projects

Directly applicable to your Cowork writing-style profile: the evidence-per-trait requirement is the upgrade over adjective-style profiles.

Go deeper

In one line: Voice-capture protocol: 5–10 varied samples → analysis of tone/hooks/structure/rhythm/vocabulary/themes/closings with quoted evidence per trait, consistent-vs-quirk separation → 5–6 line summary → human approval → paste into writing_style; keep samples as knowledge.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why demand quoted evidence for every claimed trait?

Because unevidenced style claims are generic brand adjectives. Evidence anchors the DNA in what the writer actually does.

Who signs off on the DNA and why does that step exist?

The creator — the analysis isn't permission. Automating an unapproved voice imitation misrepresents the human it speaks for.

09

App anatomy: front end, back end, database — and the key rule

Every app is three layers, and the food-delivery analogy carries all of it: the menu is front end, the rider assignment is back end, your remembered address is the database.

Front end is everything seen and touched; back end is hidden logic — validation, permissions, calculations, integrations; the database is persistent memory that survives closing the app. Around them: hosting keeps it online, a domain names it, APIs let applications talk, and an API key is a credential — 'never exposed in browser code or a public repository.'

The pair the portal is careful to split: authentication proves identity ('this is Phani'); authorization decides what that identity may access (Phani cannot see another learner's data). Conflating them is the classic beginner security hole.

Worked example · from the session

The live CRM's requirements read straight off the layers: sign-up (auth), per-user data visibility (authorization), records that survive refresh (database), dashboards (front end over back-end queries).

Why it matters

This vocabulary is the precondition for directing any builder: you can't reject a mock-only build if you can't name the database layer it's missing.

People get this wrong

A polished interface implies working accounts, saved data, and security underneath.

The front end proves nothing about the other two layers — 'looks done' and 'is done' are separated by the database and permissions.

Go deeper

In one line: Three layers: front end (visible UI), back end (logic/permissions/integrations), database (persistent records) — plus hosting, domain, APIs. API keys are server-side credentials, never client-visible. Authentication = who you are; authorization = what you may access.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Your prototype looks complete but forgets everything on refresh. Which layer is missing?

The database — you got a front-end mock. This is exactly why the build brief must state which data persists.

Authentication vs authorization in one line each?

Authentication proves the identity; authorization scopes what that identity can see and change.

10

The builder ladder: start at the simplest surface that proves the idea

Prompt-first builders, AI IDEs, agentic CLIs — the tool is not the level; move down the stack only when requirements force you.

Three tiers: prompt-first app builders (Lovable, Bolt, Replit, Base44, Emergent, v0) covering front end, back end, database and hosting for portfolios, landing pages, internal tools and MVPs; AI coding environments (Cursor, Windsurf) when you want code ownership and precise multi-file changes; agentic/CLI builders (Claude Code, Codex) for larger repositories, planning, testing, and repeated tool use — with version control and permission discipline as prerequisites.

The rule is directional: start at the simplest surface that can prove the idea; descend only when traffic, integrations, maintainability or code ownership demand it. Descending isn't graduation by prestige — it's a response to requirements.

Worked example · from the session

The portal's own CRM build stays on tier one (Lovable) because the requirement was proof, not scale — while noting the exports and GitHub push that keep the descent path open.

Why it matters

This resolves the perpetual 'which tool should I learn' question with a decision rule instead of a fashion answer.

People get this wrong

Serious builders start in the terminal.

Serious builders start where the idea is provable cheapest, and keep the export path open. The Catalyst cohort itself climbed this exact ladder.

Go deeper

In one line: Tier 1 prompt-first builders (portfolio/MVP/internal tools), tier 2 AI IDEs (code ownership, multi-file precision), tier 3 agentic/CLI (large repos, planning, testing; requires git and permission discipline). Start simplest; move down only when requirements demand.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What justifies moving from a prompt-first builder to an IDE or CLI tool?

Requirements: code ownership, custom backend, integrations, scale, tests, maintainability. Not prestige, not tool fashion.

11

Plan before build: the brief, the loop, the definition of done

If generation starts before you've decided whether data must survive refresh, the builder happily ships you a beautiful mock.

The product brief comes first: product, one user, one painful problem, core action, required screens, data to store, rules and permissions, version-one integrations only, design direction, definition of done as observable tests, and explicit out-of-scope. Then the loop: describe the full first version → ask the builder to plan data and screens BEFORE coding → confirm real vs mocked data → generate → test the core action, not the home page → one specific change at a time → on failure, hand back the exact error and ask for root-cause diagnosis → re-test after every repair → security checks → publish only after acceptance tests pass.

The portal's live build failing at publish is kept as curriculum: 'code breaks. The correct response is not panic or repeated random prompts' — inspect the build error, apply a focused repair, rerun. And the prototype/production boundary is stated plainly: a builder prototype can validate demand and serve early users; growth demands stronger hosting, database design, observability, and engineering ownership.

Worked example · from the session

The strong-vs-weak prompt pair: 'Build a CRM' versus the full brief with per-user data isolation, dashboard metrics, loading/empty/error states, accessibility, a pre-code screen map and data model, and explicit exclusions (no billing, no team roles in v1).

Why it matters

The nine-point definition-of-done checklist (account → persistence → isolation → edit/delete → empty states → invalid input → responsive → published-equals-preview → no client-visible secrets) is the single most copyable QA asset in the portal.

People get this wrong

Prompting skill is what separates good vibe-coded products from bad ones.

Briefing and testing discipline separate them. The builder amplifies whatever clarity — or vagueness — it receives.

Vibe coding compresses implementation time, but the learner still owns the brief, trade-offs, tests, data, security, deployment, and maintenance.
For your projects

law-o-matic against the nine-point list is the cheapest possible first pass of the OI-041 audit — especially 'secrets not visible client-side' and the per-user isolation checks.

Go deeper

In one line: Brief (user, problem, core action, screens, data, rules, integrations, design, done-tests, out-of-scope) → plan-first generation → one-change iteration → exact-error debugging → security check → publish after acceptance. Definition of done: signup works, data persists per user, isolation holds, edit/delete correct, empty/error states useful, responsive, preview==published, no exposed secrets.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What question must be answered before the first generation, and why?

Real data or mocked? A mock looks complete but forgets everything on refresh — deciding late wastes credits and trust.

The published build fails. Walk the correct response.

Open the build error, give the exact text back to the builder, ask for root-cause diagnosis, apply the focused repair, rerun checks — never re-prompt randomly.

12

Trigger → transform → decide → act (and who decides: rule, LLM, agent, or human)

Every automation is the same four beats — and the craft is choosing, per beat, between a rule, a model, an agent, and a person.

n8n's vocabulary: workflows of nodes; triggers (manual, scheduled, app-event, chat, webhook); connections carrying JSON between nodes; expressions referencing earlier output (drag fields, don't type guessed paths); credentials; executions as inspectable runs. The universal flow is trigger → transform → decide → act.

The decision discipline is the portal at its best: use a deterministic rule for exact conditions ('amount > 1,000'); an LLM for language judgment (classify, extract, draft); an agent ONLY when the system must choose tools or next steps; a human when context, authority, risk or accountability requires judgment. The canonical support pattern runs all four: email arrives (trigger), AI classifies into strict JSON — 'a beautifully written paragraph is a failure' when JSON is expected (LLM), fields normalize (rule), a guarded draft is written but SAVED AS DRAFT for human review (human gate), and the case logs to a sheet. Test node by node; publish narrowly; watch executions for days before expanding authority.

Worked example · from the session

The classifier contract: return ONLY one JSON object — category ∈ {refund, technical, billing, general, complaint}, priority ∈ {low, medium, high, urgent}, one factual summary sentence, no markdown, no preamble, no invented detail.

Why it matters

The rule/LLM/agent/human table is the sharpest statement of automation judgment anywhere in the KB — cleaner than the recorded sessions that demonstrate it.

People get this wrong

AI automation means putting a model in every step.

Models take only the language-judgment steps. Rules are more reliable where conditions are exact, and the consequential step stays human.

When a downstream node expects JSON, a beautifully written paragraph is a failure.
Go deeper

In one line: n8n blocks (workflow/node/trigger/connection/expression/credential/execution/webhook); flow = trigger → transform → decide → act. Per-step chooser: deterministic rule for exact conditions, LLM for language judgment, agent only for tool/step choice, human for consequential approval. Support pattern: classify to strict JSON → normalize → guarded draft (saved, not sent) → log; test per-node, publish narrow, observe.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

'Does this email sound like an urgent complaint?' vs 'is amount > 1000' — assign each its mechanism.

The first is language judgment → LLM. The second is an exact condition → deterministic rule. Deploying an LLM on the second is cost and nondeterminism for nothing.

Where is the human gate in the support pattern, and what makes it cheap?

The reply is created as a Gmail draft, never sent. Review costs seconds; a wrong auto-sent reply costs a customer.

Your workflow fails mid-run. Where do you start?

The first red or empty node — inspect its input and output. Usual suspects: credentials, invalid expression, renamed sheet column, non-JSON model output, expired token, quota.

13

The AI Director: image ingredients, motion sentences, credit discipline

A director doesn't type prompts — they storyboard, cast models per shot, manage continuity, budget takes, and finish in an editor.

Image prompts are compact comma-separated direction in eight ingredients, most important first: subject, action, environment, atmosphere, camera, lens, lighting, style reference. Video prompts are different animals — natural-language motion sentences describing subject movement, camera movement, timing and mood. Image-to-video anchors identity where text-to-video gambles the first frame; start/end frames define transitions; one principal action per short clip.

The economics are directorial: storyboard before generating; validate on a cheap model and spend premium only on chosen finals; edit a nearly-right image ('remove the blinds') instead of regenerating; track credits per usable shot; treat failed generations as takes, not failures. Continuity lives in discipline — same consented reference image, exact wardrobe language, consistent lighting words across every shot. And the hard line: consent and rights are non-negotiable — no real person's likeness or voice without permission, and commercial rights checked per plan and model.

Worked example · from the session

The coffee-commercial case study: storyboard six beats → reference frames in a cheap model → the same consented headshot in every shot → image-to-video clips → 'from the hallway on the right' added when the character entered wrong → assembled and continuity-checked in an editor.

Why it matters

Model names here are the portal's most perishable content (flagged dated in the source itself); the ingredient framework, motion-sentence pattern, credit discipline and rights posture are the durable craft.

People get this wrong

Better video models will make editing skills obsolete.

Generation replaces shooting, not directing or editing — storyboard, continuity review, assembly and sound remain the craft.

Go deeper

In one line: Image prompting: 8 prioritized ingredients (subject/action/environment/atmosphere/camera/lens/lighting/style). Video prompting: motion sentences; image-to-video for identity anchoring; start/end frames for transitions. Discipline: cheap tests → selective premium, edit-don't-regenerate, credits-per-usable-shot, continuity via consistent references and language, consent and rights checked always. Model landscape = dated snapshot by the source's own admission.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What's structurally different between an image prompt and a video prompt?

Image = prioritized visual ingredients, comma-separated. Video = sentences describing motion — subject movement, camera movement, timing. Treating them as identical is the listed first mistake.

One detail in a generated image is wrong. What's the credit-smart move?

Upload it and request the one change ('remove the blinds'), preserving everything else — editing beats regenerating for cost and continuity.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01The AI hierarchy and the five-stage LLM mental modelHierarchy: AI ⊃ machine learning ⊃ deep learning ⊃ LLMs, with generative AI as the creation-focused applica…

Hierarchy: AI ⊃ machine learning ⊃ deep learning ⊃ LLMs, with generative AI as the creation-focused application layer. LLM answer production in five stages: tokenization, embeddings, attention, prediction, variation — probabilistic sampling means same prompt, differently-worded answers, which is expected behavior, not failure.

02The Magic Prompt: five layers of context engineeringContext engineering via five layers — Identity / World / Task / Examples / Constraints — plus a missing-con…

Context engineering via five layers — Identity / World / Task / Examples / Constraints — plus a missing-context check, and an iteration loop of one named gap → one targeted revision per cycle. Instruction without context produces generic work.

03Job-to-be-done model selection and reasoning modelsSelection by job: fast general (low-risk direct), reasoning (trade-offs/calculation/ambiguity), source-grou…

Selection by job: fast general (low-risk direct), reasoning (trade-offs/calculation/ambiguity), source-grounded (must answer from supplied documents), multi-model comparison (consequential/subjective), primary+backup per category. Decision prompts end 'Do not make the decision for me' and demand assumptions, contrasting strategies, and risks.

04The twelve-use-case toolkit and orchestrationTwelve job categories with named example tools (June–July 2026 snapshot), each with a verbatim starter prom…

Twelve job categories with named example tools (June–July 2026 snapshot), each with a verbatim starter prompt and limitation. Durable content: the job taxonomy and the orchestration principle (one tool's output is the next tool's input); perishable: every product name, price and feature.

Dictation, meeting memory, source-grounded Q&A, deep research, voice role-play, data dashboards, product creative, brand drafting, network search, agentic browsing, local multi-file work, tool discovery — the full twelve

Every tool entry carries a stated limitation (consent for meeting bots, data policy for dictation, citations to be opened, smallest folder scope for local work)

Discovery is task-led: search 'the work to be done', not tool names

05The privacy and accuracy protocol: human at the decision pointNine steps: classify data pre-upload;

Nine steps: classify data pre-upload; private/local deployment for restricted data; prefer and open citations; spot-check 2–3 material claims; reproduce one result independently; self-audit is not verification; second-model critique for high-impact work; record assumptions/model/date/reviewer; human owns decisions and external actions.

06Bot → project → AI employee: the assistant ladderThree rungs: bot (single transform), project (system prompt + knowledge + persistence), employee (goal + to…

Three rungs: bot (single transform), project (system prompt + knowledge + persistence), employee (goal + tools + data + process + schedule). Suitability test for the task; delegation boundaries (read/create/change/approve, cost ceilings, failure handling, logging); autonomy earned through evaluated runs.

07XML-structured system prompts and the tuning matrixSix-part XML shape (role / context / task / instructions / constraints / output_format) whose payoff is per…

Six-part XML shape (role / context / task / instructions / constraints / output_format) whose payoff is per-tag diagnosis: tone→writing_style, ignored rule→must_do/do_not, wrong shape→output_format, wrong steps→instructions, invented facts→grounding+knowledge. Generate the first draft with AI, then test easy/vague/edge and tune one tag at a time.

08Style DNA: capturing a voice with evidenceVoice-capture protocol: 5–10 varied samples → analysis of tone/hooks/structure/rhythm/vocabulary/themes/clo…

Voice-capture protocol: 5–10 varied samples → analysis of tone/hooks/structure/rhythm/vocabulary/themes/closings with quoted evidence per trait, consistent-vs-quirk separation → 5–6 line summary → human approval → paste into writing_style; keep samples as knowledge.

09App anatomy: front end, back end, database — and the key ruleThree layers: front end (visible UI), back end (logic/permissions/integrations), database (persistent recor…

Three layers: front end (visible UI), back end (logic/permissions/integrations), database (persistent records) — plus hosting, domain, APIs. API keys are server-side credentials, never client-visible. Authentication = who you are; authorization = what you may access.

10The builder ladder: start at the simplest surface that proves the ideaTier 1 prompt-first builders (portfolio/MVP/internal tools), tier 2 AI IDEs (code ownership, multi-file pre…

Tier 1 prompt-first builders (portfolio/MVP/internal tools), tier 2 AI IDEs (code ownership, multi-file precision), tier 3 agentic/CLI (large repos, planning, testing; requires git and permission discipline). Start simplest; move down only when requirements demand.

11Plan before build: the brief, the loop, the definition of doneBrief (user, problem, core action, screens, data, rules, integrations, design, done-tests, out-of-scope) →…

Brief (user, problem, core action, screens, data, rules, integrations, design, done-tests, out-of-scope) → plan-first generation → one-change iteration → exact-error debugging → security check → publish after acceptance. Definition of done: signup works, data persists per user, isolation holds, edit/delete correct, empty/error states useful, responsive, preview==published, no exposed secrets.

12Trigger → transform → decide → act (and who decides: rule, LLM, agent, or human)n8n blocks (workflow/node/trigger/connection/expression/credential/execution/webhook);

n8n blocks (workflow/node/trigger/connection/expression/credential/execution/webhook); flow = trigger → transform → decide → act. Per-step chooser: deterministic rule for exact conditions, LLM for language judgment, agent only for tool/step choice, human for consequential approval. Support pattern: classify to strict JSON → normalize → guarded draft (saved, not sent) → log; test per-node, publish narrow, observe.

13The AI Director: image ingredients, motion sentences, credit disciplineImage prompting: 8 prioritized ingredients (subject/action/environment/atmosphere/camera/lens/lighting/style).

Image prompting: 8 prioritized ingredients (subject/action/environment/atmosphere/camera/lens/lighting/style). Video prompting: motion sentences; image-to-video for identity anchoring; start/end frames for transitions. Discipline: cheap tests → selective premium, edit-don't-regenerate, credits-per-usable-shot, continuity via consistent references and language, consent and rights checked always. Model landscape = dated snapshot by the source's own admission.

Tools referenced

ToolCoverageMomentContext
ChatGPTexplainedNamed across sessions as general assistant, Custom GPT builder (paid plan required in the source snapshot), and voice-mode rehearsal surface
ClaudeexplainedProjects (free alternative to Custom GPTs in the source snapshot), data-analysis dashboards, Research, and Claude Design for presentations
Claude CoworkexplainedThe many-local-files pattern: quarterly letters read in order with per-file citations; smallest-folder-scope advice
NotebookLMexplainedSource-grounded Q&A with citations; 'source-grounded does not mean error-free — open the cited passage'
n8nexplainedSession 4's entire automation vocabulary, canvas shortcuts, AI-node selection table, and the canonical support build
LovableexplainedThe live CRM case study: planning mode, Lovable Cloud backend, per-user auth, publish failure debugged, security scan
Wispr FlowexplainedToolkit #1 dictation; investment-thesis roast prompt shipped verbatim
FirefliesexplainedToolkit #2 meeting memory; consent and verify-against-recording limitations stated
GeminimentionedNamed among assistants; Gems as the saved-assistant equivalent (limited in source snapshot); Nano Banana image family in session 5
OllamamentionedThe local-model privacy path with its hardware/maintenance trade-offs — 'local does not automatically mean compliant'
PerplexitymentionedComet agentic browser (toolkit #10) — crawl-your-own-profile pattern feeding the interview rehearsal
CursormentionedTier-two AI IDE on the builder ladder, with Windsurf
Claude CodementionedTier-three agentic builder, with Codex — version control and permission discipline as prerequisites
VercelmentionedHosting/deployment named alongside Netlify, Hostinger, Firebase, Supabase in the infrastructure growth path
ElevenLabsmentionedAudio synthesis in the session-5 directory; voice-cloning consent rule attached
Phot.AI / Supergrow / Happenstance / There's An AI For ThatmentionedToolkit entries 7–9 and 12 (product creative, brand drafting, warm paths, task-led discovery) — dated directory snapshot
Krea / Kling / Seedream / Runway / Midjourney / Flux / VeomentionedSession 5's dated image/video model landscape (June 2026 snapshot, flagged as such in the source itself)
CapCut / Premiere PromentionedThe finish-in-an-editor half of the AI Director loop

Action items

Resources mentioned

Resources
  • docThe Magic Prompt template (five layers + missing-context check)
  • docDecision prompt pattern ('Do not make the decision for me')
  • docSystem-prompt generator (describe the job, get the six-tag block)
  • docStyle DNA analysis prompt (evidence per trait)
  • docSupport-classifier JSON contract
  • docStrong CRM build brief (the weak-vs-strong prompting exhibit)
  • docProduct brief template (plan-before-build)
  • docn8n canonical support-build field mappings (Edit Fields, draft, sheet append)
  • docSource archive: 35 portal pages + 4 verbatim corpora + 176 external links

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

True on recording day — verify before relying