How AI actually works.

Models don’t read words; they read tokens — chunks of roughly three-quarters of a word. “Sponsorship” is two tokens. A page of text is about 500. Why should a business person care about a unit this nerdy? Because tokens are the meter that everything runs on.

API pricing is per token, in and out. Latency grows with tokens generated. And the model’s working memory — the next chapter — is a fixed token budget. When an engineer says a feature is “token-heavy,” they are telling you it is slow and expensive in the same breath. When finance asks why the AI bill doubled, the answer is denominated in tokens.

The context window is everything the model can see at once: your instructions, the documents you attached, the conversation so far. Modern windows hold a few hundred thousand tokens — several novels’ worth. That sounds infinite. It is not, and treating it as infinite is the most common beginner mistake in AI product design.

Two things break when the window fills. The obvious one: old material falls out, and the model genuinely forgets it — this is why a long chat session “loses the plot.” The subtler one: models pay imperfect attention to enormous contexts, the way you skim page 200 of a briefing book. More context is not always better context. The craft of choosing what goes in — and what stays out — is called context engineering, and it is quietly becoming the core skill of building with AI.

A prompt is just the input you give the model. The interesting one is the system prompt: standing instructions, written by your team, that the model reads before every single user message. Tone, rules, format, what to refuse, who it works for — the system prompt is the job description, and the model follows it with the literal-mindedness of a very fast new hire on day one.

This is why “prompt engineering” isn’t a parlor trick — it’s spec-writing. Vague brief in, vague work out, exactly like a vague creative brief to an agency. The difference: with AI you can revise the brief fifty times a day and measure the result each time. The teams that win treat prompts as managed, versioned product assets — reviewed like code, tested like features — not as magic words someone typed once and forgot.

A model’s job is to produce the most plausible next token — not the most true one. Usually plausible and true coincide. When they don’t, the model produces a hallucination: a confident, fluent, well-formatted answer that is simply false. A citation that doesn’t exist. A revenue figure that was never reported. The danger isn’t that it happens — it’s that it happens in perfect corporate prose, with no stammer to tip you off.

The fix is not “a smarter model” (though newer models hallucinate less). The fix is grounding: forcing answers to come from real sources — your documents via retrieval, live data via tools — and asking for citations you can check. Well-grounded systems can also be instructed to say “I don’t know,” which is the single cheapest reliability upgrade available.

Out of the box, a model can only emit text. Tools (the API feature is called function calling) change that: your engineers define a menu of actions — search the warehouse, query the CRM, send the email, file the ticket — and the model, mid-conversation, can choose one, fill in the parameters, and ask your software to run it. The result comes back, and the model continues with real data in hand.

This is the line between an AI that describes work and an AI that does work — and it’s also where risk enters the building. A model that can only talk can embarrass you; a model that can act can spend money, email customers, and delete things. Which is why the tool menu, and the permissions on each item, is a business decision, not just a technical one.

Strip the hype and an agent is exactly three things: a model, a set of tools, and a goal — run in a loop. Think about the next step, take an action, look at what happened, repeat until the goal is met. A chatbot answers your question and stops. An agent keeps working: it notices the first search came up empty, reformulates, tries a different tool, checks its own output, and comes back when the job is done — minutes or hours later.

The loop is what changes the economics. You stop paying per answer and start delegating per outcome: “reconcile these two spreadsheets,” “triage today’s support queue,” “draft the quarterly review from these five sources.” The loop is also what changes the risk: an agent that can take twenty actions unsupervised can take twenty wrong actions unsupervised. Autonomy is a dial you set deliberately, not a feature you switch on.

An agent is a brilliant generalist, but it doesn’t know your way of doing things — how this company writes a launch brief, which template legal insists on, what “done” means for a quarterly review. A skill is the fix: a packaged playbook — instructions, examples, reference files, sometimes scripts — that the agent loads when, and only when, the relevant task shows up.

The detail that makes skills elegant: the agent reads a one-line description of each skill and pulls in the full playbook only when needed — so you can maintain a large library without clogging the context window (chapter 3’s desk stays clean). Skills are files, so they’re versioned, reviewable, and shareable. When someone improves the “competitive teardown” skill, every agent that uses it gets better the same day. That is institutional knowledge with a deployment pipeline.

Tools are powerful, but until recently every team wired them up bespoke — every assistant needed a custom integration to every system. The Model Context Protocol (MCP) is the open standard that ends that. A system exposes one MCP server describing what it offers — “search these docs,” “query this database,” “create this ticket” — and any MCP-compatible assistant can connect. Build the connector once; every AI tool that speaks the protocol can use it.

Why a business person should care about a protocol: it converts integrations from custom builds into a check-box (“does it support MCP?”), it reduces vendor lock-in because connectors outlive any one assistant, and it’s where the ecosystem has converged — major AI vendors and a fast-growing catalog of servers for common business software. When your team says “there’s an MCP server for that,” they mean the integration is mostly already done.

Big jobs strain a single agent for the same reason they strain a single employee: too many contexts, too many hats. A multi-agent system splits the work — an orchestrator agent breaks the goal into assignments and farms each one out to a subagent with a clean context window and a narrow job: one researches, one analyzes, one drafts, one critiques. The orchestrator reviews the pieces and assembles the result.

Two reasons this works, both familiar from management. Focus: a specialist with one job and only the relevant materials on its desk outperforms a generalist juggling everything (the context window strikes again). Parallelism: ten subagents can read ten reports simultaneously. And one familiar cost: coordination overhead is real — more agents means more token spend and more ways to fail. The honest heuristic your team should follow: use one agent until it demonstrably breaks, then split.

Traditional software is deterministic: same input, same output, write a test. AI is probabilistic: same input, slightly different output every time — and “better” is often a judgment call. Evals are how serious teams replace vibes with measurement: a curated set of test cases (real questions, graded answers) that every change — new prompt, new model, new retrieval setup — must pass before it ships.

This is the chapter to care about most, because evals are where AI products quietly succeed or fail. Without them, every model upgrade is a gamble and every “it feels worse lately” debate is unresolvable. With them, you have a scoreboard: ship the change if the numbers improve, roll back if they don’t. If your team can’t show you their evals, what they have is a demo, not a product. And the highest-leverage thing a business owner can contribute to an AI project is exactly here: defining what a good answer looks like, with real examples. That’s domain judgment, not engineering.

Once an AI can act (chapter 7) and loop (chapter 8), the governing question stops being “how smart is it?” and becomes “what is it allowed to do?” Guardrails are the controls around the model: permissions on every tool, checks on inputs and outputs, spending and rate limits, and — most importantly — human-in-the-loop checkpoints, where the system pauses and asks a person before acting.

The practical framework is blast radius. Drafting an internal summary? Let it run. Replying to a customer, touching production data, moving money? A human approves, at least until the eval scores earn more rope. Mature teams widen autonomy the way managers widen a new hire’s: gradually, based on a track record, with an audit log of every action so trust can be verified rather than assumed. “The AI did it” is not an accountability structure — every agent should have an owner whose name you know.