AI, Demystified

· A long road to an overnight success

"AI" isn't new — it's about seventy years old, and it took three big waves to get to the thing in your pocket.

· So what is it, underneath?

Strip the wonder and a language model does one humble thing astonishingly well: it predicts the next chunk of text. You hand it words; it returns its best guess at what comes next; you pick one, add it, and ask again. Run that loop thousands of times a second and out comes an essay, a plan, working code.

Hold that split and three confusing things make sense: why it doesn't remember you on its own, why it can be confidently wrong (it predicts what's plausible, not what's true), and why everything depends on what you put in front of it.

Everything ahead is one of those two levers in action — the ways you feed the model (memory it can search, systems it can reach, know-how it can follow), the wider field of tools built on top of it, and what running all of it actually costs.

· A model is a big bag of numbers

A "model" is just the frozen artifact from training: billions of learned numbers — its weights or parameters. That's it. No database of facts, no little person inside. The intelligence is encoded in how those numbers transform whatever you feed in. An inference engine is the software that runs that math, token by token.

· What happens between your words and its answer

• Tokens. First your text is sliced into bite-size pieces — "playing" might split into "play" + "ing" — and each piece is swapped for a number, because numbers are all the model can actually do math on. Those pieces are called tokens.
• Embeddings. Each token is turned into a long list of numbers you can picture as a dot placed in a huge space, where things that mean similar stuff sit close together — "king" lands near "queen," "pizza" lands far away. So meaning becomes location. That dot is its embedding, and a little order info is mixed in so "dog bites man" doesn't read like "man bites man."
• The thinking layers (the "Transformer"). Those dots flow through dozens of identical layers. The key move in each is attention: every word glances back at all the other words and pulls in the ones that matter — the way you reread the start of a sentence to work out who "she" refers to. Stack that 30–100+ times and the model builds a rich read on what you mean.
• A bet on the next word. The top of the stack turns all that into odds for every possible next token — basically a ranked guess: maybe 70% "the," 9% "a," and so on down the list.
• Pick one, then do it all again. The engine picks a token from those odds, sticks it on the end, and runs the whole thing over — now one word longer. That loop is generation; it's literally why the answer types itself out one piece at a time.

· The same idea, in pictures

· Why speed, cost, and memory behave the way they do

• The context window is its only memory. Everything the model can use for this answer — your question, the chat so far, any files — has to fit inside one fixed-size window. Anything outside it simply doesn't exist for this reply: no attic, no notebook it can wander off to check. That window is the context.
• Reading is fast; writing is slow. It reads your whole prompt in one big gulp (engineers call that the prefill), then writes the reply one word at a time (the decode). Writing is the slow part — which is why a long answer takes longer than an equally long question.
• The KV cache — its scratch notes. To write word #500 it would otherwise have to re-read the first 499 every single time. So it jots its work-so-far in a sticky-note pile and reuses it, the way you keep notes beside a book instead of restarting from page one. That pile is the KV cache: fast, but bulky — and how much memory it eats is usually the real limit on how long a conversation can run.
• The speed tricks. Everything done for speed is really "do less work": quantization (rounding the numbers to shorter ones that are quicker to shuffle around), mixture-of-experts (waking only the slice of a giant model each word needs, not all of it), and batching (handling many people's requests together in one pass). Same goal every time — move fewer bytes, do fewer sums.

· Not all models are the same

Models split along a few axes you'll choose between constantly: closed/frontier (Claude, GPT, Gemini, Grok — you rent access over the internet; an API is just a hatch one app uses to call another) vs. open weights (Llama, Mistral, DeepSeek, Qwen — you can download and run them yourself); big & smart vs. small & cheap; reasoning models that think longer vs. fast models for bulk. The craft is matching the model to the job, not running the biggest one on everything.

· The problem this solves

The model is frozen at training time and has no memory between calls. It doesn't know your contracts, your wiki, last week's meeting, or anything that happened after training. And you can't just paste a 5,000-page library into the window — it doesn't fit. So you need a way to find the few passages worth spending precious context tokens on, and hand only those over.

· Embeddings, again — meaning as coordinates

The same trick from Part 1 does the heavy lifting. Run any chunk of text through an embedding model and you get that dot in space again, where similar meaning lands nearby no matter the exact words. "How do I reset my password" and "I'm locked out of my account" end up neighbors even though they barely share a word.

· A vector database is a map of meaning

Chop your documents into chunks, turn each into its dot, and store the millions of dots in a vector database (Pinecone, Weaviate, Chroma, or pgvector living right inside a normal Postgres database). To answer a question, you drop the question's dot onto the same map and grab the dots sitting closest to it — the chunks most similar in meaning. (The technical name for "closest dots" is nearest neighbors.) It's search by idea, not by matching keywords.

· RAG — retrieve, then generate

Retrieval-Augmented Generation is the whole move in one line: retrieve the most relevant chunks, paste them into the context window, then let the model generate its answer grounded in them. It isn't teaching the model anything — the weights never change — it's curating the input so the answer is grounded in your material and can cite where it came from.

This is the engine under "talk to my documents" tools like NotebookLM, under most enterprise AI, and under the kit's own setup. Get the sources right and the answers get right; feed it noise and it drowns.

· From knowing to doing

So far the model can think and, with RAG, read your files. But your work lives in live systems — email, calendars, a ticketing tool, a database, the web. A connector is the wiring that lets the model reach those systems: pull a real value out, or take a real action (send, create, update) when you allow it.

· MCP — one standard plug for everything

MCP (the Model Context Protocol) is the open standard that makes this sane. Rather than a custom integration per tool per model, MCP gives every tool one common way to describe what it offers and every model one common way to call it. Think USB-C for AI: one port, many devices. A server can expose tools (actions), resources (data/context), and prompts (ready-made templates). It started at Anthropic and is now adopted broadly across the ecosystem.

· Why it matters — and the catch

Reach is exactly what turns an assistant (answers you) into an agent (does the job). It's also where the risk lives: capability without governance is the danger. A connector can read and act, so least-privilege access, auditing, and trusting the source of a tool are first-class concerns — not afterthoughts.

· Skills — the recipe cards

A Skill is a folder of procedural know-how — step-by-step instructions, and even scripts the agent can run — that it pulls out only when a task matches. Building a clean spreadsheet or a slide deck? There's a recipe behind that telling it how to do it properly, instead of improvising each time.

• Progressive disclosure. Only a one-line description sits in memory by default; the full recipe loads when it's needed — so a pile of skills costs almost nothing until used.
• It can run code. Skills aren't just prose; they can carry and execute scripts, which is how reliable document creation actually works.
• An open standard. The same Skill format runs across Claude, the API, and a growing set of other agents — not locked to one product.

· The "named assistant" pattern — same idea, many brands

Here's the unlock for the whole ecosystem: every major platform lets you package a reusable assistant — pre-loaded instructions + knowledge + tools — once, and reuse it forever instead of starting cold each time. Same idea, different names:

· The other path — changing the model itself

Everything above leaves the model untouched and works on the input. There’s one move that changes the model: fine-tuning — feeding it many examples so its weights shift toward your style or domain. It’s how open models like Hermes get their flavor. Heavier than prompting, and usually the last lever to reach for, not the first.

· Read every vendor through three lenses

Comparing AI tools on a single score is how you get confused. Three separate lenses actually differentiate them, and a company can win on one while losing another:

• Model — the raw intelligence (reasoning, coding, writing). Reorders every few months.
• Product — the app around the model: projects, agents, connectors, image/video/voice. Usually the real day-to-day differentiator.
• Deployment — cloud-hosted (convenient, your data leaves your boundary) vs. self-hosted open weights (you own the infra and the data). A governance call as much as a technical one.

· The players, in one breath

· The layer beneath: systems & processes

Around the chat boxes sits the real machinery: agents and coding agents that do multi-step work; deep-research modes that browse and synthesize; and a self-hosting stack for running open models yourself — vLLM for throughput, Ollama/LM Studio for local runs, LibreChat/Open WebUI as governed front-ends, pgvector for retrieval. Same context-assembly ideas from Parts 2–4, just operated on your own hardware.

· The honest nuances

• It varies wildly by model and task. A simple prompt is fractions of a watt-hour; a reasoning model or a very long prompt can be 10–65× more (GPT-5-class responses ~18–40 Wh; some reasoning models ~29 Wh). Cheap-to-buy is not cheap-to-run.
• Inference now dominates. The headline used to be giant training runs (a frontier model can train on tens of GWh). But the bigger ongoing draw is now everyday use — inference — growing ~30% a year.
• Water and carbon, briefly. Liquid cooling cuts direct water use 70–90%, but it doesn't reduce the electricity, which is the dominant cost. Energy per query keeps falling fast (Google reports a 33× drop in a year); total emissions are still rising because growth outpaces clean-energy supply.
• It's local, not just global. The strain shows up in specific places — Ireland's data centers already exceed 20% of national electricity; parts of Virginia, Texas, and Arizona face real grid build-out.

· Every build is the same little loop

A poster, an app, a video clip — building any of them with AI runs the same circle. You don't need to know the how; you need to know the loop:

You bring the describe and the fix — the taste and the judgment. The tool does the draft and the run. So below, you're the director: change the description, watch it rebuild, keep what you like.

· Your turn — pick something to make

· Now take it off the page

Those knobs were training wheels — in the real thing you just say what you want. Open a coding agent like Claude Code, type "build me a one-page site for my dog-walking gig," and it writes the files, runs them, and shows you the result. You read it and say "make the header teal and add a booking form," and it does. Same loop you just ran — only now the agent does the typing.