A large language model — the thing inside Claude, ChatGPT, all of them — is a next-piece-of-text predictor. You give it some text, and it predicts what comes next. Then it adds that piece, looks at everything again, and predicts the next piece. Over and over.

That's it. That's the whole engine. It's the autocomplete on your phone, except instead of suggesting one word it has read a huge fraction of everything ever written, and it predicts not just the next word but paragraphs, code, arguments, plans — one small chunk at a time.

Three things it is not

• Not a database. It doesn't store and retrieve facts in slots. Knowledge is smeared across billions of weights as patterns, which is why it can be fluent and confidently wrong in the same breath.
• Not a search engine. Out of the box it isn't looking anything up. It's generating plausible continuations. (Tools can give it search later — that's Module 11.)
• Not a person. No goals, no memory between conversations, no understanding in the human sense. It's a very deep pattern-completer that's good enough to look like all three.

Models don't see letters or words. They see tokens — chunks of text, usually about ¾ of a word. Common words are one token; rare ones get split. hunting is one token; WuTangNAS is several stitched-together pieces.

Every token is turned into an embedding: a long list of numbers (a vector) that places the token as a single point in a vast multi-dimensional space. The whole point of that space is that meaning becomes distance. Tokens with similar meaning sit near each other; unrelated ones sit far apart.

This representation explains real behavior you'll hit:

• Token math, not letter math. Ask a model to count the r's in "strawberry" and it may fumble — it sees tokens, not letters. Same reason it's shaky at character-level tricks.
• Cost and limits are in tokens. API pricing, context limits, speed — all measured in tokens, not words. Roughly 750 words ≈ 1,000 tokens.
• Retrieval runs here. When you "search your journal by meaning" later (RAG, Module 12), you're finding the nearest points in exactly this kind of space.

To predict the next token well, the model has to figure out which earlier tokens actually matter. The mechanism that does this is attention: for every token, the model looks across all the other tokens and weighs how relevant each one is, right now, to what it's trying to predict.

Stacked into layers

A single attention pass isn't enough. A transformer stacks dozens of these blocks. Each block re-mixes the tokens through attention and then a small processing step, passing richer representations up the stack. The pattern that emerges in practice:

• Early layers catch surface stuff — grammar, word shape, "this is a noun."
• Middle layers assemble relationships — who did what to whom.
• Deep layers hold abstract meaning, intent, and the threads needed to predict what's coming.

The model starts as billions of random numbers (parameters, or "weights"). Training is the process of nudging those numbers until the machine gets good at prediction. It happens in three stages, each doing a different job.

What "learning" leaves behind

• Frozen weights. After training, the numbers are fixed. When you chat with it, it is not learning — it's running. New knowledge only enters through what you put in front of it (context) or tools.
• A knowledge cutoff. It only "knows" what existed in its training data. Anything after that date has to be fed in — which is exactly why web search and retrieval exist.
• Smeared, not stored. Facts live as patterns across weights, so the model can blend two true things into one false thing with total confidence. This is hallucination, and it's structural, not a bug you can fully patch. (Verification is Module 18.)

Using a trained model is called inference. It computes the probability of every possible next token, then has to actually pick one. How it picks is controlled by a dial called temperature.

This is why the same prompt can give different answers, and why a model can sound certain about something it's inventing — it's sampling from a distribution, not reciting a record.

The context window — the one limit that explains everything

The context window is everything the model can see at once: your message, the system instructions, the conversation history, any documents or tool results — all of it, counted in tokens. It is the model's entire working memory. Nothing outside the window exists to the model.

• No memory between sessions. A fresh conversation starts blank. Any "memory" feature works by re-injecting saved facts back into the window — it's not the model remembering, it's the harness reminding it.
• Bigger isn't free. Larger windows cost more and can dilute focus — bury the key instruction in 100k tokens of noise and the model may lose the thread. Curation beats dumping.
• This is the lever you control most. Everything in Modules 8–17 — prompts, tools, RAG, memory, agents — is ultimately about managing what's in this window.

There are two ways to make a model smarter. The old lever is train-time scale — more parameters, more data. Reasoning models add a second: test-time compute. Instead of a bigger model, you let the same model do more work at the moment you ask — generating a long private chain of reasoning, then writing the answer you see. Spent well, that compute can let a smaller model match a much larger one on hard problems.

The "thinking" is not a new kind of cognition. It's the same next-token prediction from Module 5, just a lot more of it, aimed inward: more tokens means more chances to break a problem into steps, try an approach, notice a mistake, and correct course before committing. OpenAI calls these reasoning tokens; Anthropic emits thinking content blocks. Either way they're billed as output (you pay for every one), they eat context-window space, and the raw trace is usually hidden or summarized — you see a précis, not the full scratchpad.

Trained to reason vs. just told to

This is the honest distinction from "think step by step." Prompted chain-of-thought is an inference-time trick on a normal model: you write "let's think step by step" and it produces visible steps. It helps, but the model was never trained to reason — it's pattern-matching the shape of worked examples and can't reliably backtrack or check itself. A trained reasoning model has the chain-of-thought baked in by reinforcement learning: it's rewarded for reaching correct answers on checkable problems (math, code, logic), and over training it learns strategies — self-verification, trying alternatives, catching its own errors mid-stream. DeepSeek-R1 showed these behaviors emerge from RL without being programmed. That's why you don't need to tell a reasoning model to slow down; it already does, and its self-correction is real rather than performed.

The control dial: reasoning effort

You don't just toggle thinking on and off — you meter it. OpenAI exposes reasoning.effort (none → minimal → low → medium → high → xhigh, model-dependent). Anthropic exposes extended thinking with a budget_tokens cap or an adaptive effort where the model decides how much to think per request. Newer models lean adaptive: think hard on the hard parts, barely at all on the easy ones. The tradeoff stated plainly: higher effort buys accuracy on genuinely hard problems, at the cost of more latency (seconds to minutes) and more dollars — and on easy problems it buys little or nothing.

The rule: reasoning buys accuracy on hard problems, and you pay for it whether the problem was hard or not. Reach for it when correctness matters more than speed and the problem actually needs steps. Default to a normal model otherwise.

A raw LLM is just the prediction engine from Modules 1–6: text in, next token out. By itself it has no persona, no rules, no tools, no memory, no idea it's in a chat. The product you actually use — Claude, ChatGPT, Claude Code, your Marked chatbot — is the model plus a whole apparatus wrapped around it. That apparatus is the harness, and it's where almost all the product engineering lives.

This distinction is the hinge of the whole guide. From here up, the heat is about systems, not the engine. The engine barely changes between "a chatbot" and "an autonomous agent that refactors your codebase" — the harness is what changes.

A harness is everything wrapped around the raw model to turn a next-token predictor into a useful system. It's the part you, as a builder, actually design and control.

The pieces

• System prompt — standing instructions injected before your message: who it is, the rules, the tone, the output format. (This guide's structure, your Marked chatbot's "land manager" persona — all system prompt.)
• Tool definitions — the menu of actions it's allowed to call: search, run code, query a DB, fire an ntfy push. (Module 11.)
• Memory / state — what survives between turns or sessions, re-loaded into context as needed. (Module 12.)
• Context manager — the logic deciding what actually gets shown to the model each call, given the window limit.
• The loop — whether the harness calls the model once and stops (chat) or repeatedly toward a goal (agent). (Modules 8–9.)
• Guardrails — budgets, max iterations, human approval gates on irreversible actions.

Same engine. The difference between "a chatbot" and "an agent" is not the model — it's how many times the harness lets the model act, and whether the model gets to decide its own next step.

• Chat — you ask, it answers. One model call per turn. You are the loop: you read the reply, decide what's next, and type again. The human is in the loop on every single step.
• Agent — you give it a goal and a set of tools, and the harness lets the model loop on its own: decide an action, take it, look at the result, decide the next action — repeating until the goal is met. The human sets the goal and the guardrails; the model drives the steps.

It's a spectrum, not a switch

• Plain chat → conversation, no actions.
• Chat + tools → it can search or run code once to answer better, but you still drive.
• Workflow → fixed steps you defined, run in order. Predictable, no improvisation.
• Agent → the model chooses the steps and the order to hit your goal.
• Multi-agent → several agents with roles, coordinated. (Module 14.)

An agent is a loop with a goal. The model thinks about what to do, acts by calling a tool, observes the result, and repeats — each result folded back into context so the next thought is better informed. This pattern is often called ReAct: Reason + Act.

Why looping is the superpower

A chat model gets one shot. An agent gets to be wrong and recover. It can write code, run it, read the error, fix it, and re-run — exactly what a human engineer does. The loop turns a one-shot guesser into something that converges on a working result. That's why Claude Code can actually fix a failing test suite instead of just suggesting a patch and hoping.

• Stopping conditions — the agent must know "done." Vague goals loop forever; checkable goals ("all tests pass," "file written and validates") terminate cleanly.
• Budgets — cap iterations and spend so a confused agent fails cheap instead of expensive.
• Checkpoints — gate destructive or external actions behind a human "yes." This is the difference between a helpful agent and a loose cannon.

A model can't natively query your database or push a notification — it only emits text. Tools bridge that gap. You describe a function to the model ("send_ntfy, takes a message"); when it wants to use it, it emits a structured request; your harness runs the real function and feeds the result back into context. That request-and-return protocol is function calling.

MCP — the standard that makes this plug-and-play

Early on, every tool had to be wired by hand into every app. MCP (Model Context Protocol) fixes that: it's an open standard for exposing tools and data so any model can plug into any tool without custom glue. Think of it as USB-C for AI — one connector shape, and your Pocket recorder, Gmail, Drive, Supabase, and a dozen others just snap in.

Since the weights are frozen and the window is finite, everything useful comes down to one craft: getting the right information in front of the model at the right moment. That's context engineering, and it has two big tools — retrieval and memory.

RAG — Retrieval-Augmented Generation

Instead of relying on what the model memorized, RAG fetches relevant material at question time and stuffs it into the window before the model answers. The fetch uses the embedding space from Module 2: your question becomes a vector, and you grab the nearest chunks of your own documents.

Memory — persistence across the gaps

The model forgets everything between sessions. Memory is a harness feature that stores durable facts and selectively re-injects them into context when relevant — so it can "remember" your subnet, your vendors, your projects. Key mental model: the model isn't remembering; the harness is reminding. Memory is a store on the side, loaded back into the window on demand.

• Context window = short-term working memory, this conversation only, wiped at the end.
• Memory store = long-term notes the harness keeps and re-surfaces — like the running picture I keep of your stack so you don't re-explain it every time.
• RAG store = a searchable body of documents pulled in on demand by relevance.

RAG changes what the model knows; fine-tuning changes how the model behaves. Pick by asking which of those your problem actually is — and most of the time the honest answer is "reach for retrieval first."

They get confused because both are sold as "customize the AI on your data," but they're completely different levers. RAG leaves the frozen weights alone (Module 4): at question time it fetches the relevant facts from an external store (Module 12) and drops them into the context window. Knowledge lives outside the model; you swap it freely. Fine-tuning continues training the model on your examples so its default behavior shifts — tone, format, the shape of an answer, a niche task it does reliably without being re-instructed. Knowledge baked into weights; changing it means training again.

Which lever, when

• Reach for RAG when facts are fresh / changing (prices, policies, this week's stand notes), proprietary to you (your subnet, your journal, your medallion tables), or you need grounding and citations traceable to a source. Auditability is structurally a RAG property — weights can't cite.
• Reach for fine-tuning when you need a consistent format, style, or voice every time without re-prompting, a narrow task done reliably (emit exactly this JSON shape) where a long prompt is brittle, or latency / cost wins — bake behavior in so each call needs a shorter prompt.

The decision question, front and center: is my problem about what the AI knows, or how it behaves? Knowledge → RAG. Behavior → fine-tuning. And they're not rivals — the strong pattern is fine-tune for behavior and layer RAG for facts. Berkeley's RAFT formalizes it: a model fine-tuned specifically to read retrieved documents — including learning to ignore irrelevant "distractor" chunks — beats either approach alone on domain-specific QA.

Failure modes — credibility lives here

• Fine-tuning to "add knowledge." The seductive mistake. Research (Gekhman et al., EMNLP 2024) shows models learn fine-tuning examples containing new facts much slower than facts they already half-know — and as those new-knowledge examples get learned, they linearly increase the model's tendency to hallucinate. The field's takeaway: models acquire facts in pretraining; fine-tuning teaches them to use what they have, not to learn new facts. Want it to know something new? That's RAG's job.
• Stale indexes. RAG is only as fresh as its store. An index not re-embedded when source data changes will confidently serve last quarter's price. RAG moves the freshness problem out of the weights — it doesn't delete it.
• Retrieval quality dominates. Garbage in, garbage out: no model rescues a bad fetch. Most "RAG is broken" pain is a retrieval problem — bad chunking, weak embeddings, distractor docs — not a generation problem. Debug the retriever before you blame the model.
• Fine-tuning the freshness away. Choosing fine-tuning for facts that change means re-training on every change — slow, expensive, and you still inherit the hallucination risk. Almost always the wrong trade.

2025/26 default: start with RAG (and good prompting). Fine-tune only once you've proven RAG can't deliver the behavior you need — it handles the large majority of "use our data" asks faster, cheaper, and reversibly.

A single agent juggling a huge task fills its window with too many concerns and starts dropping threads. The fix mirrors how you'd run a crew: break the job into roles, give each a clean context, and have a coordinator stitch the results together.

Common patterns

• Orchestrator-worker — a lead plans and farms subtasks to workers, then merges results. (How deep-research systems fan out across sources.)
• Critic / debate — one agent produces, another reviews and pushes back, raising quality through friction.
• Pipeline — agents in sequence, each transforming the previous one's output, like a Bronze→Silver→Gold medallion flow but with reasoning at each stage.

Module 14 answered should you go multi-agent. This answers how it's wired: which shape routes the work, and how agents that each have their own separate context window — possibly running in different harnesses — share what they've learned without flooding, contradicting, or poisoning each other.

The topologies — pick the shape that matches the work

Module 14 named three patterns in passing. Here's the fuller toolkit, and the rule for when each fits is always the same question: how coupled are the subtasks? Independent work fans out; dependent work must serialize or share state.

• Orchestrator-worker (hub-and-spoke). A lead plans, spawns workers, synthesizes their returns — the workhorse Module 14 diagrams. Fits breadth-first, parallelizable work ("find every board member across 20 companies"). The lead holds the plan and the only complete picture; the lead decides it has enough and stops spawning.
• Hierarchical / recursive. Workers are themselves orchestrators with their own workers — a tree. Fits deep decomposition, but cost compounds with depth, so cap the depth explicitly.
• Sequential pipeline. Agents in a line, each transforming the previous one's output (extract → reason → draft → check). Fits a fixed dependency order. The most deterministic shape — closest to a data pipeline — and the easiest to debug, because state flows one direction.
• Parallel fan-out / fan-in. Sibling subtasks dispatched at once, results merged — the orchestrator-worker's parallel core. Fits when latency matters and subtasks are independent. The fan-in (merge) step is where the hard problems live: dedup, conflict resolution, provenance.
• Blackboard. No one boss routes the work. Specialists all watch a shared workspace; each contributes when the current state matches what it knows how to do; a lightweight control loop picks who goes next. Fits ill-defined problems with no fixed solution path. Coordination is indirect — agents never talk to each other, only to the board — which makes it the cleanest model for the shared-state problem below.
• Debate / critic. One agent produces, another adversarially reviews. Going a level past Module 14: the critic must have a different context/prompt than the producer or it just rubber-stamps — the same reason an eval judge must be validated separately (Module 16).

Shared context — the genuinely hard part

The uncomfortable truth: each subagent has its own context window, and they cannot see into each other's. A worker never witnesses the lead's reasoning or its siblings' transcripts — it gets only what was explicitly handed to it, and the lead gets back only what the worker chose to return. There is no shared mind; there is only what you wire through the seams. Three ways agents share state, coldest to hottest:

• Message passing (handoff). The orchestrator sends a distilled task (objective, format, boundaries, the few facts it needs) and gets back a distilled result — never the raw transcript. You pass conclusions, not transcripts. Raw transcripts are huge and full of dead ends; the sender summarizes at the boundary. Dominant mode, and the one most prone to "lost in translation" loss.
• Shared memory / scratchpad / blackboard. A common store all agents read and write. Lets many agents converge on one evolving artifact without N×N messaging. The discipline that makes it safe: a single writer per slot (or append-only with provenance), so two agents don't clobber each other. Reads are cheap; uncoordinated writes are where it corrupts.
• Shared store / artifact. A durable external object — a file, a row, a doc, a task record — that outlives any single agent's context and serves as the handoff medium, especially across harnesses. Agent A in one harness writes the artifact; Agent B in another reads it. The artifact is the shared context; neither agent shares its internal memory.

Across harnesses, and why opacity is correct

When agents live in different harnesses (or vendors/frameworks), there's no shared process, no shared window, no implicit anything — they share context only through an explicit boundary protocol. The emerging standard split, stated plainly:

• MCP connects an agent to its tools (agent → tool) — Module 11.
• Agent-to-agent protocols (e.g. A2A) connect agents to each other (agent → agent), and their first design principle is opacity: agents exchange tasks, messages, and artifacts — distilled, structured handoffs — without exposing internal memory, tools, or chain-of-thought. That opacity isn't a limitation; it's the correct shape. You hand over the call, not the whole sensor feed.

Summarization at boundaries is load-bearing, not optional. Every handoff is a lossy compression, so good systems make the summary structured (schema'd fields, not prose) and keep a pointer back to the source so a claim can be re-checked.

Provenance & trust on merge

When the orchestrator merges several agents' outputs, it is ingesting text it didn't write — and an LLM can't tell instructions-from-you from instructions-hidden-in-data. A worker that read a poisoned web page can return output carrying a smuggled command; if the lead treats merged worker output as trusted instructions, that's prompt injection between your own agents. This is the same hazard as Module 17, now turned inward. So: tag every contribution with where it came from, treat cross-agent output as data, not commands, and gate any consequential action behind verification — the least-privilege, cut-a-trifecta-leg posture from Module 17, applied to the seams inside your swarm.

Coordination failure modes — where it bites

• Context fragmentation. No agent holds the whole picture; the synthesis is only as good as the distilled returns. Detail dies at every boundary.
• Duplicated / conflicting work. Vague task boundaries make two workers do the same thing or reach contradictory conclusions. (Anthropic's system hit exactly this; the fix was detailed delegation — objective, format, boundaries.)
• Lost-in-translation handoffs. The boundary summary drops the one nuance that mattered; the receiver confidently builds on a misread.
• Runaway fan-out cost. Multi-agent burns ~15× the tokens of plain chat (single agents already ~4×). Spawning subagents for a one-line question, or searching endlessly for info that doesn't exist, are real early failures.
• No clean termination. Without explicit budgets the swarm doesn't know when "enough" is — orchestrators over-invest, recursion never bottoms out, debate never converges.
• Error propagation. One worker's wrong fact, passed up as a clean conclusion, gets laundered into the final answer with false confidence — same shape as poisoned provenance, minus the adversary.
• Tight-coupling mismatch. Some work needs shared context and real-time coordination (most coding: edits conflict, order matters). Today's agents are bad at coordinating edits live, so forcing that work into a parallel fan-out backfires — it wants a pipeline or a single agent.

Practical levers — what keeps it alive

• Budgets / limits. Cap tokens, tool calls, subagent count, and recursion depth per task — and scale them to complexity (a fact-lookup gets one agent and a few calls; a broad comparison gets several). Budgets are the primary termination mechanism.
• Idempotent steps. Make each action safe to retry, so a re-run or crash-recovery doesn't double-write.
• Single writer for shared state. One owner per slot; everyone else appends with provenance. Kills the clobber-and-conflict class.
• Verification / critic stages. A dedicated checking pass before consequential output — the merge isn't trusted blindly. (Straight into Module 16, Evals.)
• Deterministic orchestration vs. model-driven delegation. The biggest lever. Where the flow is known, hard-code it as a deterministic pipeline (cheap, debuggable, repeatable) and let the model reason only inside each step. Reserve model-driven delegation for genuinely open-ended work. Don't pay for dynamic orchestration on a fixed problem.

An eval is how you find out whether an AI system actually works — not by watching one good demo, but by running it against a fixed set of real cases and scoring the output. Because the output is non-deterministic, "it passed once" tells you almost nothing; you need a measurement you can repeat.

Why normal tests stop working

Traditional tests are exact: assert add(2,2) == 4 — same input, same output, forever, and a red test means a real bug. LLM output varies run to run, and the "right" answer is usually a set of acceptable answers, not one string. So assert response == "..." is either too brittle or meaningless. An eval is not a unit test — it's a measurement: run N cases, score each, report the rate. You're estimating a probability, not asserting a constant. A demo is one hand-picked sample with the operator steering: it has no denominator, so it tells you the system can succeed, never how often, and never where it silently fails.

Build the set from real failures, not imagination

The highest-leverage activity is error analysis: read real traces, tag what actually went wrong, group the tags into a failure taxonomy. An LLM has near-infinite ways to fail — you can't anticipate them, so don't pre-write evals before you've seen failures. The productive order: ship something small → look at outputs → discover failures → write a targeted eval for each → fix → repeat. Anthropic's guidance: start with 20–50 tasks from real failures and the manual checks you already run. Each case must be unambiguous (two domain experts independently reach the same verdict) and solvable (write a reference solution). The set is living: every new production failure becomes a new case, so that bug can never silently come back.

The grader ladder — cheap to expensive

Build evaluators in ascending cost; only climb when a cheaper rung can't capture the quality you care about.

• Assertions / code checks (cheapest, deterministic). Valid JSON? Schema matches? Required fields present? No blocked phrase? Number parses? These catch a huge share of real failures and cost nothing on every commit.
• Reference-based checks. Compare against a known-correct answer — exact match, set membership, numeric tolerance. Works when "correct" is well-defined: extraction, classification, structured output. (BLEU/ROUGE are weak as verdicts; use them only to find interesting traces.)
• LLM-as-judge (most expensive). A model scores against a rubric — for subjective qualities rules can't capture (is this summary faithful? is the tone right?), used after you've fixed the easy stuff.

Offline, online, and the CI gate

Reference-based evals have ground truth and run offline before you ship — this is where regression evals live, the safety net that says "my change didn't break the 50 cases that used to pass." Reference-free evals have no gold answer and run online on sampled live traffic — judging intrinsic properties (is the answer grounded in the retrieved context? does it address the question?) to watch for drift. Mature setups run evals at three points: offline on a curated set, in CI before any prompt/model change merges, and online on live traffic. Keep CI evals cheap and mostly deterministic; reserve the expensive judges for the slower cadence.

Agents and RAG get graded differently

• Agents have a trajectory. Capture the transcript (reasoning, tool calls, order) and the outcome (final state). Grade the outcome, not the path — pinning the agent to one "correct" tool sequence punishes valid creative solutions. Tool-use checks are strongest when execution-based (run the call in a sandbox, check the result). pass@k = ≥1 success in k tries (any success is fine); pass^k = all k succeed (when consistency is the product — a finance extraction that must be right every time).
• RAG fails in two places, so split it. Retrieval: context precision (is what we retrieved relevant) and recall (did we get everything needed). Generation: faithfulness/groundedness (does the answer stay inside the context or invent?) and answer relevancy. A wrong answer with good retrieval is a generation problem; with bad retrieval it's an indexing problem — lumping them hides the cause.

An LLM can't tell the difference between instructions from you and instructions hidden in the data it reads — so any untrusted text an agent ingests (a web page, an email, a trail-cam caption, a tool's output) can quietly become a command it obeys. The more an agent can do, the worse a single poisoned sentence gets, and there is no patch that fully closes this.

The whole problem is one architectural fact carried over from Modules 2 and 5: the model reads instructions and data through the same channel — one flat stream of tokens. There's no "this part is trusted, this part is just content" tag the model can rely on. Whatever looks like an instruction can act like one.

Direct vs. indirect injection

• Direct prompt injection. The attacker is the user — they type "ignore your previous instructions and…" to override the system prompt, leak it, or jailbreak guardrails. Annoying, but the blast radius is usually just their own session.
• Indirect / data-borne injection (the dangerous one). The malicious instruction rides in on data the agent fetches on your behalf — a web page, an email body, a calendar invite, a GitHub issue, a PDF, a RAG chunk, even text hidden in white-on-white font. The agent reads it as part of "doing its job" and follows it. You never see the payload; the agent does. This is the attack that matters for agents, because agents read untrusted content by design.

"Just instruct the model not to" fails reliably. The model is non-deterministic and the input space is infinite — an attacker only needs one phrasing that slips through, across unlimited tries. Security that works ~95% of the time is, against an adversary who moves second, security that fails. Treat in-prompt instructions as a preference, never a boundary.

The lethal trifecta

Simon Willison's model is the clearest: an agent becomes exploitable when it has all three of —

• Access to private data (your inbox, your notes, secrets, prod configs),
• Exposure to untrusted content (it reads attacker-influenced text),
• An exfiltration / external channel (it can send mail, hit a URL, write to a DB, render a markdown image whose URL it controls).

With all three, one poisoned document can make the agent read your secrets and ship them out — no code vulnerability required. The classic exfil needs no obvious "send" tool: the injection tells the agent to embed stolen data in a URL —  — and the moment the markdown image renders, the browser leaks it. This is the confused deputy (OWASP LLM06): the agent acts with your privileges, so the real flaw isn't that it was tricked — it's that it was over-privileged, making being tricked catastrophic instead of harmless. Drop any one leg and that specific catastrophe becomes impossible.

Realistic defenses — defense-in-depth, not a fix

No item below is sufficient alone. You stack them and accept residual risk.

• Least-privilege tools. Scope every tool to the minimum — read-only by default, narrow row/path scopes, short-lived tokens, separate identities per agent. The single highest-leverage control: it caps the blast radius whether or not injection succeeds.
• Cut a leg off the trifecta. Meta's Agents Rule of Two (Oct 2025): an unsupervised agent may hold at most two of {untrusted input, sensitive access, external comms}. Want all three? A human gates it.
• Human-in-the-loop on consequential actions. Require explicit approval before anything irreversible or outbound (send, delete, pay, deploy). Reversible/read actions can stay autonomous.
• Provenance / tainting. Track which tokens came from untrusted sources; forbid tainted data from triggering consequential tool calls.
• Output handling (LLM05). Treat model output as untrusted too — never eval it; sanitize before it hits a shell, SQL, or HTML; strip auto-rendered images/links to kill the exfil channel.
• Sandboxing. Run tool/code execution in an isolated, network-restricted environment so even a fully hijacked step can't reach your data or the open internet.

1 · Pick the right altitude for the task

The most common mistake is using an agent where chat would do, or chatting where you needed an agent. Match the tool to the shape of the work:

• Use chat for thinking, drafting, explaining, deciding — anything where you want to stay in the loop and the output is words. (Vendor emails, "explain this Databricks feature," sanity-checking an approach.)
• Use chat + tools when one lookup or one calculation makes the answer real. (Search, a quick data pull, a one-off script.)
• Use a workflow when the steps are fixed and you want the same path every time. (Incident-report → JSON. Predictability is the feature.)
• Use an agent when the task is multi-step, the path varies, and success is checkable. (Refactor across files until tests pass; triage an inbox by rules.)

2 · Prompt like you're briefing a sharp contractor

The model is capable but has zero context about your situation beyond what you give it. Good prompts front-load that:

• Be specific about the goal and the format. "Give me a 5-row markdown table comparing X on cost, speed, and lock-in" beats "tell me about X."
• Give it the context it can't have. Your constraints, your stack, your hard rules (ntfy-only, offline-first). It can't read your mind or your network diagram.
• Show an example of good output. One example of the shape you want is worth a paragraph of description — and a counter-example ("not like this") sharpens it further.
• Let it reason before it answers for anything non-trivial. "Think it through step by step, then give the answer" measurably improves hard tasks.
• Iterate. First output is a draft, not a verdict. Tell it what's off; it adjusts fast. Treat it as a conversation, not a vending machine.

3 · Verify — always, especially when it sounds confident

4 · Manage the context window like a campsite

• Pack what's relevant, leave the rest. Don't paste an entire repo when three files matter — noise dilutes focus (Module 12).
• Start fresh when it gets muddy. If a long thread has wandered, open a clean one with a tight summary. A polluted window quietly degrades every later answer.
• Decompose big asks. Break a mountain into checkable steps and hand each at the right altitude. Small, verifiable chunks beat one giant vague request.

5 · Know what good looks like (evals)

Before you lean on an AI for something repeated, define how you'll know it's working. "It seemed fine" is how silent failures creep into finance data — even a tiny eval set of five hand-checked examples turns "I hope" into "I checked." How you actually prove it works gets its own full treatment — see Module 16.

6 · Let your role shift up the stack

The throughline of this whole guide: as the tooling climbs from chat to agents, your job moves from doing the work to specifying it, verifying it, and orchestrating it. The leverage isn't in typing faster — it's in being the person who frames the goal precisely, sets the guardrails, and knows enough (from Modules 1–16) to tell when the machine is bluffing.

Two knobs decide your experience: the model (the engine, Module 1) and the harness (the app around it, Module 8). The thing most people get backwards: for day-to-day work the harness matters more than the model. Two people on the same model in different apps have wildly different experiences — and the top harnesses now let you swap the model underneath anyway. So pick the workflow first, the engine second.

The models — the engines

Frontier chat models are close enough that "best" usually means "best for this task." The honest differentiators:

Anthropic's surfaces — your home turf

All of these run the same Claude engine. They differ in where they run and who they're for.

Cowork vs. Claude Code — same engine, different vehicle

This is the one that trips everyone up, because they overlap heavily. Both run the identical Claude agentic core — plan, spawn subagents, use tools, edit files, run code, finish without babysitting. Both reach your local files, your connected apps, run on a schedule, and take orders from your phone. The choice is about fit and interface, not raw capability.

Coding & agent harnesses beyond Anthropic

Omnigent — the meta-harness

Databricks' open-source Omnigent sits a layer above the harnesses above. Instead of being yet another coding agent, it orchestrates the ones you already use (Claude Code, Codex, Cursor) — swap the model or harness with a one-line config change, run multi-agent teams, and enforce policy at the orchestration layer (spend caps, sandboxing, "pause before this action") rather than by hoping a prompt holds. The clean mental model: Kubernetes for AI agents. It's early/alpha, but it's the answer to "how do I avoid lock-in and govern a fleet of agents."

Picking in practice

• Chat to think, an agent to do. Human-in-the-loop each turn → chat. Want a finished thing produced autonomously with your review at the end → agent.
• Non-developer path: Claude.ai → Cowork → Claude in Office → Design.
• Developer path: Claude.ai/ChatGPT → Claude Code or Codex → Cursor/Copilot in-IDE → Devin for delegated tickets → Omnigent once you're orchestrating several agents.
• Bet on the workflow, not the brand. Models leapfrog monthly and harnesses increasingly let you swap them, so don't marry an engine.

Reading top-to-bottom gives you the path. This shows you the shape: foundations on the cool side feeding the central engine, systems on the hot side wrapping around it. The whole field is one connected structure — which is exactly why understanding the engine makes the agents make sense.

The software development lifecycle (SDLC) is the repeating loop a change travels: plan → code → build → test → release → deploy → operate → monitor, then back to plan. CI/CD is the machinery that automates the middle of that loop — build, test, deploy — so the path from "I changed a line" to "it's running in production" is fast, repeatable, and boring. Boring is the goal.

Underneath all of it is version control, and in practice that means git. Git is the system of record for every change — who, what, when, and the exact state of the code at every point. You can't automate a pipeline over code you can't precisely name and roll back to.

The vocabulary you'll actually use

• Repository (repo). The project plus its entire history. git clone copies it; the hidden .git folder holds every snapshot.
• Working tree → staging → commit. You edit files (working tree), pick what to record (git add stages it), then git commit freezes a snapshot with a message, an author, a timestamp, and a unique hash.
• Commit hash. The 7g8h9i-style id is the immutable name of one exact state. Pipelines and rollbacks key off it.
• HEAD. A pointer to "where you are now" in history — usually the tip of your current branch.
• Remote / push / pull. Your local repo and the shared one (on GitHub or Azure Repos) sync via push (send) and pull (receive).

A branch is a cheap, throwaway parallel timeline. You snap one off main, do your work in isolation, and when it's ready you merge it back. A pull request (PR) is the formal proposal to do that merge — the place review happens, automated checks run, and the team says "yes, this can join."

Merge vs. rebase — the one nuance that trips people up

Both integrate one branch into another; they differ in what they do to history.

The rest of the key terms

• Conflict. When two branches change the same lines, Git can't auto-decide — you resolve it by hand, then commit the resolution. Normal, not a failure.
• Code review. A human reads the diff and comments before approving. The single highest-leverage quality habit in the whole pipeline.
• Branch protection. A rule on main: no direct pushes, PR required, checks must pass, N approvals needed. This is what makes the gate real instead of optional.

Branching strategies

• Trunk-based. Tiny short-lived branches off main, merged daily. Pairs best with strong CI. The modern default.
• GitHub flow. Branch → PR → review → merge → deploy. Simple, continuous, what most small teams and your own projects use.
• GitFlow. Long-lived develop + release + hotfix branches. Heavyweight; fits scheduled, versioned enterprise releases — less so continuous delivery.

Continuous integration is a simple discipline with a big payoff: merge small changes often, and have a machine build and test every one automatically. The "check" your PR was waiting for in the last module is a CI pipeline — a defined sequence of steps a server runs on your code the moment it changes.

The terms, decoded

• Pipeline / workflow. The sequence of automated steps, defined as code in a YAML file that lives in the repo. Versioned with everything else.
• Trigger. What kicks it off — a push, a PR opening, a schedule, or a manual run.
• Runner / agent. The machine that executes the steps. A clean, ephemeral environment each run, so "works on my machine" stops mattering. Hosted (the platform's) or self-hosted (yours).
• Job / step / stage. Steps group into jobs; jobs can run in parallel and group into stages.
• Artifact. The build output (a bundle, an image, a .whl) the pipeline produces and stores for later stages to deploy.
• Status check. The pass/fail signal CI hands back to the PR — the gate from Module 23, now filled.

The two D's people blur together: Continuous Delivery means every green build is always ready to release — going live is a button a human presses. Continuous Deployment goes one step further: if it's green, it ships to production automatically, no button. Same pipeline; the difference is whether a human stands at the prod gate.

Deployment strategies — how the new version actually goes live

The rest of the vocabulary

• Environment / stage. A place the app runs — dev, test, staging, prod — each a checkpoint the same artifact is promoted through. You never rebuild per environment; you move the one build forward.
• Approval gate. A required human (or policy) sign-off before promotion to a sensitive environment, usually prod.
• Rollback. Re-deploying the last known-good artifact when a release goes wrong. Fast rollback > perfect releases.
• Feature flag. A switch that ships code dark and turns it on later — decouples "deployed" from "released," so you can flip a feature off without a redeploy.

Everything in this group — repos, branches, PRs, pipelines, environments — exists in both Azure DevOps and GitHub, just under different names and menus. They're sibling products under one owner. Pick by context, not by capability: the concepts transfer one-to-one.

So which do you reach for?

Read top-to-bottom and you get the path; this shows you the shape. The cool side is version control — a repo full of commits, branched and merged through pull requests. The hot side is automation — CI and CD, the two hubs everything turns on: CI proves a change, hands off an artifact, and CD promotes it to production. Both houses, Azure DevOps and GitHub, sit at the top because they host every node below them under different names.