## Lecture
The machine. Claude is a large language model: given a sequence of tokens (word-fragments, ~3–4 characters of English each), it predicts what comes next, repeatedly. Everything else is scaffolding. Two consequences dominate all architecture:
First, the context window is the model's entire working world. What's in the window — system prompt, conversation, tool results, files — is what the model can act on. Frontier Claude models in 2026 carry 1M-token windows (Haiku 4.5: 200k), which sounds infinite and isn't: cost scales with tokens processed, and signal quality degrades when the window fills with junk. The architect's reflex: *curate, don't dump.*
Second, the model is stateless between calls. It remembers nothing. All "memory" — Chat's memory feature, Claude Code's CLAUDE.md, the API memory tool — is scaffolding that re-inserts selected state into the next call's window. Once you internalize this, features that seem magical become legible engineering.
The lineup. As of July 2026, four models matter, verified against platform.claude.com/docs:
| Model | API ID | Context | Max out | $/MTok in/out | Role | |---|---|---|---|---|---| | Claude Fable 5 | `claude-fable-5` | 1M | 128k | $10 / $50 | Frontier. Hardest reasoning, long-horizon agents. Always-on adaptive thinking. | | Claude Opus 4.8 | `claude-opus-4-8` | 1M | 128k | $5 / $25 | The coding & agentic workhorse. Notably better at catching flaws in its own code than 4.7. | | Claude Sonnet 5 | `claude-sonnet-5` | 1M | 128k | $3 / $15 (intro $2/$10 through Aug 31, 2026) | Production default: ~90% of the capability at a fraction of the cost. | | Claude Haiku 4.5 | `claude-haiku-4-5-20251001` | 200k | 64k | $1 / $5 | High-volume, low-latency: subagent worker, classifier, real-time. |
(Also live: Claude Mythos 5, a limited-release frontier sibling of Fable 5, and older 4.x models in maintenance. Time-boxed notes: Fable 5 was free for paid users through July 19, 2026; Sonnet 5 intro pricing ends Aug 31.)
Thinking and effort. The big 2026 shift: adaptive thinking replaced manual thinking budgets. On Fable 5 and Opus 4.8, the model decides when and how deeply to reason — you cannot turn it off on Fable 5. Your dial is the `effort` parameter: `low` / `medium` / `high` / `xhigh` (and `max` in some harnesses). Same model, different depth-vs-cost tradeoff. Architect's rule: pick the cheapest model that can do the job, then tune effort — model choice sets the ceiling, effort sets how hard it pushes toward it.
The economics that change your designs. Two features turn "expensive" into "cheap" and thus reshape what's worth building:
*Prompt caching:* cached prefix reads cost 0.1x normal input price (writes cost 1.25x–2x once). A 100k-token system prompt + reference corpus that would cost $0.50 per call on Sonnet 5 costs ~$0.03–0.05 on cache hits. This is why big stable system prompts, loaded skills, and long-lived agent sessions are economically viable — *if* you structure prompts stable-prefix-first so the cache actually hits.
*Batches API:* 50% off for async, non-urgent workloads. Nightly evaluation runs, bulk classification, corpus processing — half price for tolerating latency.
Everything else the platform does (you'll meet these in context later): tool use and MCP, structured outputs (schema-guaranteed JSON), vision, web search and web fetch tools, code execution containers, the memory tool, computer use (beta), context editing and compaction, 1M-context long-horizon support. File the names; sessions 4–6 make them concrete.
The four laws (memorize verbatim — the whole track hangs on them):
1. Context is the scarce resource. 2. The loop is the unit of work, not the message. 3. Generation and evaluation must be separated. 4. Model choice is an economic decision.
## Anecdotes
*The $4,000 classifier.* A team ran a frontier model over every inbound support ticket for sentiment tagging — a task Haiku 4.5 does indistinguishably well at a tenth the price. Nobody chose that; it was the default model left over from a prototype. The bill was the code review. Law 4 exists because defaults are sticky and invoices are quiet.
*The prompt that got cheaper by getting longer.* An agent builder resisted adding a 30k-token style guide to a system prompt — "too expensive." With caching structured correctly (stable guide first, variable request last), the guide cost full price once, then ~10% on every subsequent call in the cache window. The counterintuitive lesson: with caching, *stable* context is nearly free; it's *churning* context that costs. Architects design for cache hits the way web devs design for CDN hits.
*The disappearing thinking dial.* In 2025, developers hand-tuned `budget_tokens` for extended thinking per request. In 2026, adaptive thinking made the model self-tuning and `effort` became the coarse dial. The meta-lesson: the platform absorbs low-level knobs over time. Learn the current abstraction, and re-check the docs before reusing last year's integration pattern — knowledge here has a shelf life, which is exactly why this track flags dates.
## Lab (10 min)
1. In Claude Code or Cowork, ask: *"Which model are you running, what's its context window, and what effort level is this session using?"* Note the answer. 2. Fetch the live lineup yourself: have Claude fetch `https://platform.claude.com/docs/en/about-claude/models/overview` and produce a two-line delta report vs the table above. (Habit being installed: verify against live docs, don't trust memory — yours or the model's.) 3. Cost estimate by hand: a loop runs every hour with a 60k-token stable prompt and 2k variable tokens, producing 1k output, on Sonnet 5 standard pricing. Compute daily cost with and without caching (5-min cache expires between runs — so use the 1-hour cache write at 2x, reads at 0.1x). Check yourself in the answer key (file 11).
## Key takeaways
The model predicts tokens; scaffolding does the rest. The context window is the working world and the cost driver. Four models span the price/capability space: Fable 5 (frontier), Opus 4.8 (agentic workhorse), Sonnet 5 (production default), Haiku 4.5 (volume). Adaptive thinking is on by default; `effort` is your dial. Caching makes stable context ~10x cheaper; batches halve async work. And the four laws — context scarcity, the loop, gen/eval separation, model economics — are the load-bearing walls of every session that follows.
## Lecture
Recall Law 2: the loop is the unit of work. Every Anthropic surface is the same model family wrapped in a different harness — a runtime that decides what the loop can touch (sandbox), what survives between runs (persistence), and what starts a run (trigger). Choosing a surface *is* choosing those three properties. Here is the 2026 map.
Claude Chat (web, desktop, mobile) — the conversational surface; the harness for *thinking with* the model. Current feature set: Artifacts (live interactive apps/documents), Projects, redesigned memory (July 2026: individual, categorized entries Claude reads and updates), real-time web search, Research mode (multi-search deep research with citations, paid plans), Connectors (Drive, Slack, Microsoft 365 with write access as of July 2026), file generation (docx/pptx/xlsx/pdf), 1M-token context. Sandbox: none to speak of — it acts on the conversation, not your filesystem. Trigger: you, typing. Use it for: exploration, drafting, analysis-in-dialogue, anything where *you* remain the loop.
Claude Cowork — Anthropic's general agent for non-coding work, and the biggest product story of 2026. Timeline: research preview January 12, 2026 (macOS desktop, Max users); GA on macOS/Windows April 9; web + mobile July 7. Under the hood it's the Claude Code agent loop wrapped in a friendlier harness: sessions run in an isolated environment on Anthropic's servers and persist when you close the app; connecting the desktop app adds local file access, browser use, and computer use. It has skills, plugins (bundles of skills + connectors + subagents, with private marketplaces for orgs), global instructions, three permission modes (Manual/Auto/Skip), parallel subtask execution, and scheduled tasks that run remotely — your laptop can be closed. Anthropic reports >90% of Cowork usage is non-software work. Use it for: delegating multi-step work on real files and tools — reports, ops, research, pipelines.
Claude Code — the software-engineering agent, now on six surfaces: terminal CLI (primary), VS Code extension, JetBrains plugin, desktop app, web (claude.ai/code, cloud sandboxes, auto-fix PRs), and mobile monitoring. Deep customization: CLAUDE.md, skills, hooks, subagents, plugins, MCP, checkpoints, headless/CI mode. Session 3 is entirely about it. Use it for: anything that ends in a commit.
Claude for Chrome — browser extension agent (beta, all paid plans): navigates, clicks, fills forms, extracts, runs scheduled browser workflows. Site-permission pre-approval and confirmation gates for irreversible actions; Anthropic explicitly warns prompt-injection defenses "aren't foolproof" — treat web content as untrusted input. Use it for: acting inside websites that have no API.
Claude for Excel / Microsoft 365 — add-ins living inside Excel, PowerPoint, Word (GA on paid plans), Outlook (beta). Formula-preserving model edits, template-respecting slides, tracked-changes document work, email triage with held drafts. Use it for: work whose native habitat is an Office document.
The routing framework. Ask three questions, in order:
1. *What does the task need to touch?* Conversation only → Chat. Files/tools/schedules → Cowork. A repo → Code. A website with no API → Chrome. An Office document's internals → Excel/M365. 2. *Who is the loop?* If you'll steer every step, Chat is fine and fastest. If Claude should run multi-step and report back, you want an agentic surface (Cowork/Code) with real sandbox and persistence. 3. *What triggers the work?* One-off → any surface. Recurring or event-driven → the surfaces with remote scheduling (Cowork scheduled tasks; Claude Code routines/web) so execution doesn't depend on your machine being awake.
Notice these are exactly sandbox, persistence, trigger — the harness properties. The surface decision is a harness decision; Session 4 makes the same analysis formal for the developer-facing harnesses (Agent SDK, Managed Agents).
## Anecdotes
*The wrong-surface tax.* A founder ran a weekly competitive-research ritual in Chat: paste links, ask questions, copy results into a doc, forty minutes of human-as-glue. Moved to Cowork: one scheduled task, files written directly, delivered every Monday, laptop closed. Same model, same quality. The forty minutes were pure harness mismatch — the human was doing the persistence and scheduling that the harness should have owned.
*Cowork's origin story.* When Cowork previewed in January 2026, developer Simon Willison described it as "regular Claude Code wrapped in a less intimidating default interface and with a filesystem sandbox configured for you." That framing is architecturally exact and worth keeping: the agent loop is the invariant; products are harness skins over it. Once you see that, new Anthropic product launches stop being surprising — you just ask "same loop; what's the new sandbox, persistence, trigger?"
*The browser is hostile territory.* An early Chrome-agent user asked it to summarize a page that contained hidden text instructing agents to exfiltrate the user's data. Anthropic's defenses caught classes of this, but their own docs refuse to call the protections foolproof. The architect's posture: the browser surface handles *untrusted* input by default, so scope its permissions per-site, keep irreversible-action confirmations on, and never point it at pages you wouldn't paste into a prompt.
## Lab (8 min)
1. List your three most repetitive weekly tasks. Route each through the three questions (touch / who's-the-loop / trigger) and write down the correct surface. At least one is probably running on the wrong surface today. 2. In Cowork, schedule a trivial recurring task (e.g., a Monday-morning one-liner). Confirm it's server-side scheduled — that's persistence + trigger living in the harness, not in your calendar. 3. In Chat, check what memory holds about you (ask it). Connect that to Session 1's statelessness fact: where must that memory physically live for the model to "know" it?
## Key takeaways
Every surface = same model family + different harness. A harness is defined by sandbox, persistence, and trigger. Chat is for thinking-with (you are the loop). Cowork is the general agent for delegated, non-coding, file-native work — server-side sessions, plugins, remote scheduling. Code is the engineering agent across six surfaces. Chrome acts in the browser but treats the web as untrusted input. Excel/M365 acts inside Office documents. Route by what the task touches, who runs the loop, and what triggers it.
## Lecture
Claude Code is the reference implementation of everything this track teaches: an agent loop (model proposes tool calls; the harness executes Read/Write/Edit/Bash/search/web tools; results feed back; repeat until done) with the richest configuration surface Anthropic ships. Master its config model and you've mastered the pattern the Agent SDK and Cowork reuse. Docs live at code.claude.com/docs.
Install & surfaces. Native installer (`curl -fsSL https://claude.ai/install.sh | bash`), Homebrew, WinGet, apt/dnf. Runs in: terminal (primary), VS Code extension (inline diffs, @-mentions, plan review), JetBrains plugin, desktop app, web (claude.ai/code — cloud sandboxes, GitHub integration, auto-fix PRs on CI failures), and mobile monitoring. Sessions can move between web and terminal (`--teleport`).
Context configuration — CLAUDE.md. Instructions loaded into the window at session start (Law 1 in action: this is *curated standing context*). The hierarchy, broadest to narrowest: managed policy (org-enforced) → user (`~/.claude/CLAUDE.md`, all your projects) → project (`./CLAUDE.md`, checked in, team-shared) → local (`./CLAUDE.local.md`, gitignored personal overrides) → nested per-directory files loaded on demand. Supports `@file` imports. Keep it lean — it's paid-for context on every session (mitigated by caching, but attention is also a budget). Separately, auto memory lets Claude write its own learnings to `~/.claude/projects/<project>/memory/MEMORY.md`, loaded at startup — the harness-maintained counterpart to your hand-written CLAUDE.md.
Settings — five scopes, highest precedence first: managed (can't override) → CLI args → local (`.claude/settings.local.json`) → project (`.claude/settings.json`) → user (`~/.claude/settings.json`). Settings carry permissions, env, hooks, model choice, and more.
Permission modes are the trust dial: `default` (ask per unlisted tool), `plan` (read/reason only; edits prompt), `acceptEdits` (file edits auto-approved), `dontAsk` (pre-approved runs, unlisted denied), `auto` (a classifier adjudicates each call), `bypassPermissions` (everything allowed — CI/containers only, never on a laptop with credentials). Granular rules like `Bash(npm *)` allowlist command families. The architect's habit: trust is *scoped and graduated*, matched to blast radius.
Extension points — the four you must be able to distinguish:
- Skills (`.claude/skills/<name>/SKILL.md`): packaged instructions/workflows the model invokes when relevant or via `/name`. They are *prompt-space*: they change what the model knows to do. - Hooks: shell commands or callbacks firing on lifecycle events (PreToolUse, PostToolUse, SessionStart, Stop…). They are *deterministic-space*: they run regardless of model judgment — the right place for "always run the linter after edits," "block writes to /prod," audit logging. Rule of thumb: if it must *always* happen, it's a hook, not a prompt. - Subagents: separate agents spawned via the Agent tool with fresh, isolated context (they inherit CLAUDE.md but not the conversation). The context-scaling tool — Session 6 goes deep. - MCP servers: the standard bus for external tools (Slack, Airtable, Vercel, Figma…). Config in `.mcp.json` or `claude mcp add`; tool schemas are deferred by default and loaded on demand to save context (Law 1 again).
Plugins bundle skills + agents + hooks + MCP servers into installable packages, distributed through marketplaces (official + community + private org marketplaces). This is how a team ships a shared way-of-working as an artifact.
Operational features. Checkpoints & rewind: file state tracked across turns; rewind code, fork the conversation, or both — cheap experiments, safe exits. Headless mode: non-interactive runs for CI/CD. Routines: scheduled execution on Anthropic infrastructure. Channels: route events (Slack, webhooks) into sessions. `/compact`, `/context`, `/usage` for context and cost hygiene.
Best-practice project setup (the lab makes you do this): a lean CLAUDE.md stating stack, conventions, commands, and verification expectations; project settings with scoped permissions; a hook enforcing your non-negotiable (tests/lint on edit); skills for your repeated workflows; MCP servers only for tools this repo actually needs.
## Anecdotes
*The 40-line CLAUDE.md that beat the 400-line one.* Two engineers configured the same monorepo. One wrote 400 lines — architecture essays, style philosophy, aspirations. The other wrote 40: build commands, test commands, "verify at runtime before declaring done," three hard prohibitions. The 40-line file outperformed consistently. Instructions compete for attention with the actual task (Law 1); every sentence must earn its tokens. Write CLAUDE.md like a pre-flight card, not an onboarding deck.
*The hook that ended a category of failure.* A team kept catching the agent "forgetting" to run tests before declaring victory — prompt reminders helped, sometimes. They moved the requirement to a PostToolUse hook running the test suite after every edit batch and surfacing failures into context. The category vanished. Moral, stated as the track's sharpest config rule: prompts request, hooks guarantee. Anything on the "must always happen" list belongs in deterministic-space.
*Rewind as a strategy, not an undo.* An architect facing a risky refactor stopped pre-negotiating every detail. Instead: checkpoint, let the agent attempt boldly, review the diff, rewind wholesale if wrong — often keeping the *learning* ("approach B hits the ORM problem") while discarding the code. Checkpoints turn the agent into a cheap hypothesis-tester. That's Law 3 flavored: generate boldly, evaluate independently, discard freely.
## Lab (12 min)
On a real repo: (1) Run `/init` and inspect the generated CLAUDE.md; cut it to ≤40 potent lines. (2) Create `.claude/settings.json` with a scoped permission set — allow your build/test commands, deny anything touching secrets. (3) Add one PostToolUse hook that runs your linter or test suite after edits. (4) Write one three-line SKILL.md for a workflow you repeat weekly. (5) Ask Claude Code to make a small change, watch the hook fire, then rewind it. Verify each piece *behaves* — runtime proof, not "looks right."
## Key takeaways
Claude Code = the reference agent loop + the richest harness config. Context config: CLAUDE.md hierarchy (managed→user→project→local→nested) + auto memory; keep it lean. Control config: five settings scopes, six permission modes, granular tool rules. Extension points: skills change what the model knows (prompt-space); hooks make things always happen (deterministic-space); subagents isolate context; MCP buses external tools; plugins package all of it for distribution. Checkpoints make bold generation cheap because evaluation and rollback are independent.
## Lecture
The official vocabulary. Anthropic's canonical distinction (from *Building Effective Agents*, still the field's reference text): a workflow is a system where LLMs and tools are orchestrated through *predefined code paths* — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. An agent is a system where the LLM *dynamically directs its own process and tool usage*. The distinction is about who holds the control flow: your code (workflow) or the model (agent). Workflows are predictable and cheap to reason about; agents handle open-ended tasks your code couldn't have scripted. Anthropic's standing advice, worth quoting into memory: use the *simplest* pattern that works, add autonomy only when the task demands it, and invest heavily in tool documentation and transparency.
The agent loop, precisely. One turn: assemble context → model call → model returns text and/or tool requests → harness executes the tools → results appended to context → repeat. The loop ends when the model stops requesting tools (task complete) or a stop condition fires: max turns, budget cap, timeout, or an explicit goal check. An agent without engineered stop conditions is an unbounded process — Session 5 makes "goals as termination conditions" the centerpiece.
The harness, precisely. The harness is the runtime and control layer *around* the loop: it executes tools, enforces permissions, manages context (compaction, caching, memory), persists sessions, and provides triggers. Model quality gets the headlines; harness quality determines whether agents work in practice. In 2026, "harness engineering" is a named discipline in Anthropic's engineering writing.
The harness spectrum — the build-vs-buy ladder for architects:
1. Claude Code / Cowork — full harnesses, human-operated. Zero build cost; you configure rather than construct. 2. Claude Agent SDK (Python `claude-agent-sdk`, TypeScript `@anthropic-ai/claude-agent-sdk`) — Claude Code's entire loop as a library *you embed and host*. Ships the built-in tools (Read/Write/Edit/Bash/Glob/Grep/WebSearch/WebFetch/ToolSearch/Agent…), hooks as in-process callbacks (PreToolUse, PostToolUse, Stop… — they don't consume context), subagent definitions, session persistence with resume/fork, MCP config, permission rules (`allowed_tools`, granular `"Bash(npm *)"` patterns), and the crucial safety rails: `max_turns` and `max_budget_usd`. Auth via API key, or Bedrock/Vertex/Foundry env switches. This is how you put a Claude agent *inside your product*. 3. Managed Agents (beta, `managed-agents-2026-04-01` header) — Anthropic hosts the loop server-side: stateful sessions via REST/SSE, file persistence, sandboxed execution, MCP with vault-based auth (up to 20 servers), metered at ~$0.08/session-hour. You call an API; the agent runs on their infrastructure. The tradeoff vs SDK: least ops burden, least control; still beta, so treat GA-dependent plans as provisional.
Choose by asking the harness-property questions from Session 2 — whose sandbox, whose persistence, whose trigger — plus one more: *whose ops pager*.
Long-running agents: the hard part. Anthropic's engineering guidance on multi-hour/multi-session agents (from *Effective Harnesses for Long-Running Agents*) is a pattern language worth memorizing because it generalizes:
- Initializer/worker split: a first agent sets up the foundation (scaffolding, feature list, progress file); resumed sessions run a *worker* prompt that reads state and advances incrementally. Different phases want different prompts. - Externalized state: a machine-readable feature list (all items starting "failing"), a progress file, and git commits form the agent's durable memory — because context dies but files persist. This is Session 1's statelessness fact scaled up to days. - Incremental execution with clean handoffs: small verified steps, committed, documented, so any future session (or any *other* agent) can resume cold. - The failure modes this prevents: premature "done" claims, lost context on restart, untested features, dirty handoffs.
Note what that pattern smuggles in: discovery of what to do next (read the feature list), verification (tests flip features from failing), persistence (files + git). Session 5 names this structure formally as the five moves.
## Anecdotes
*The workflow that didn't need to be an agent.* A builder spent two weeks on an autonomous "research agent" — planning, self-directed browsing, tool selection — for what was actually: fetch five known sources, extract the same six fields, compile a table. A 40-line workflow (fixed fan-out, one extraction prompt, one merge) did it faster, cheaper, and deterministically. Anthropic's simplicity principle isn't modesty; autonomy you don't need is variance you pay for. Reserve agency for tasks where the *path* is genuinely unknown.
*The overnight agent that forgot everything.* An early long-running-agent experiment ran beautifully for three hours, hit the context limit, compacted, and "woke up" having summarized away the subtle constraint that motivated the whole design — then confidently violated it. The fix wasn't more context; it was external state: constraints in a file re-read at each phase boundary, progress in git, a feature list as ground truth. Context is working memory; files are long-term memory. Never leave anything important solely in working memory.
*Same loop, three addresses.* One team shipped the same underlying agent three ways as their needs matured: prototype in Claude Code (a skill + hooks), productized via the Agent SDK inside their backend, then moved the always-on version to Managed Agents to shed ops. The agent logic barely changed — the *harness* did. That's the spectrum working as designed: promote along it as requirements harden.
## Lab (8 min)
1. Take one automation you run today and classify it, in writing: workflow or agent? Who holds control flow? What are its stop conditions — and if you can't name them, write them now. 2. Sketch (paper is fine) the SDK skeleton for it: which built-in tools, which permission rules, `max_turns`, `max_budget_usd`, and the one hook you'd register first. 3. Write the three external-state artifacts a long-running version would need: the state file, the progress log, the "done" definition. Keep this — it's a capstone input.
## Key takeaways
Workflow = your code holds control flow; agent = the model does; use the simplest that works. The loop: context → call → tools → results → repeat, ended by completion or engineered stop conditions. The harness is the runtime around the loop — tools, permissions, context management, persistence, triggers — and harness quality is what separates demos from systems. The spectrum: Claude Code/Cowork (configure), Agent SDK (embed and host), Managed Agents (rent, beta). Long-running agents survive on externalized state: initializer/worker splits, feature lists, progress files, git.
## Lecture
Session 4 gave you the loop's anatomy. This session gives you the engineering discipline for building loops that run *without you* — and the audit lens for knowing when they only pretend to. The frame: a loop is a system that prompts the agent so the human doesn't have to. The practitioner's journey is moving from *inside* the loop (steering every turn) to *outside* it (building the thing that steers). Judgment is your scarce resource; loop engineering is the practice of spending it only where it's irreplaceable.
The five moves. Every turn of a mature loop decomposes into five capabilities. Score each 0–3 (0 absent · 1 human-supplied · 2 engineered but fragile · 3 robust and independent):
1. Discovery — how the loop decides *what* to work on. Does it find its own targets (scan the queue, diff the repo, read the feature list), or does a human hand it one every run? 2. Handoff — how context reaches the agent. Assembled by the system (skills, CLAUDE.md, state files, connectors), or re-typed by a human each time? 3. Verification — how output is judged. An *independent* check, or the loop trusting its own work? 4. Persistence — what survives between runs. Durable state (files, git, memory, databases), or cold starts? 5. Scheduling — what triggers a run. Self-triggering (cron, webhook, event, server-side scheduled task), or a human remembering?
Report the vector, not just the sum: a 12/15 loop scoring 0 on verification is more dangerous than an even 9 — it's a machine for shipping unchecked output at scale.
The generator/evaluator test — the single highest-signal check, and Law 3 operationalized. Ask of any loop: *is the thing that judges the output a different prompt/agent/check than the thing that produced it?* A model grading its own work in its own context tends to praise it — its evaluation is correlated with the very reasoning that produced the errors. Pass: separate evaluator, ideally adversarial (a skeptical reviewer prompt, a test suite, a runtime check). Soft fail: a "verification step" that's the same agent re-reading itself — treat its approval as near-worthless. Hard fail: no evaluation at all. The gate rule: no loop scores 3 on verification without passing this test. Cheap strong evaluators, in rough order of strength: runtime proof (run it, click it, curl it) > test suites > independent adversarial agent > schema/lint checks > self-review (barely counts).
Goals as termination conditions. "Improve the docs" cannot stop a loop; "every public function has a docstring, checked by script X returning zero" can. An architect's goal spec has three parts: a target state (machine-checkable), a budget (max turns / dollars / wall-clock — from Session 4's `max_turns`/`max_budget_usd`), and an escalation rule (what happens on budget-exhausted-but-goal-unmet: stop and report, never thrash silently). Write goals the evaluator can check — that's what makes the loop closed rather than merely long.
The four silent costs. Automation's failure modes that accrue invisibly until something breaks:
- Verification debt — output volume exceeding what anyone actually checks. Fifty unreviewed PRs a week is debt regardless of loop quality. - Comprehension rot — you no longer understand what the loop does because you stopped reading its output. Hits solo operators hardest. - Cognitive surrender — the most dangerous, because it disguises itself as trust: you still "review," but you've stopped exercising judgment and now rubber-stamp. - Token blowout — cost = run frequency × context size, and nobody watches the meter. Flag any loop that re-loads heavy context every scheduled run (the Session 1 caching lab is the antidote).
The realistic mitigation for a solo operator drowning in loop output is almost never "review harder" — it's a *better evaluator*, plus deliberately keeping a few loops manual so judgment stays exercised.
Scheduling done right. Server-side by default: Cowork scheduled tasks and Claude Code routines run on Anthropic infrastructure whether your machine is awake or not. Event triggers (webhooks, channels, CI events) beat timers when work arrives irregularly — polling on a timer is discovery-by-brute-force. And a schedule wrapped around an unverified loop is *theater with a cron entry*: scheduling multiplies whatever the loop already is, including its flaws.
## Anecdotes
*The changelog loop that praised itself.* A weekly loop summarized merged PRs into a changelog and "reviewed its own summary for accuracy" in the same conversation. For months it approved itself; a customer eventually flagged a described feature that had been reverted before release. The generator hallucinated continuity, and the "reviewer" — sharing every token of the generator's context — inherited the blind spot. Fix: a separate evaluator agent that received only the raw git log and the drafted changelog, prompted to find discrepancies. It caught a real error in week one. Same model, different *information structure* — that's why separation works.
*Fifteen minutes to close a loop.* An operator ran a "find broken links weekly" loop that emailed findings — which sat unread (verification debt meets comprehension rot: a report nobody reads is not verification). The upgrade: loop fixes trivial breakages itself, opens a PR gated on a link-checker script passing on the built site (independent, runtime evaluator), and messages a one-line summary. Human judgment now spent only on the PR diff — the irreplaceable part. Score before: discovery 3, handoff 3, verification 0, persistence 2, scheduling 3. After: verification 3. The fix took fifteen minutes. Most loop libraries have several of these lying around.
*The $300 cron job.* A nightly loop re-ingested a full knowledge base — 200k tokens — to answer what was usually "no changes today." Token blowout, textbook: frequency × context, unwatched. Rearchitected: a cheap Haiku 4.5 pre-check diffs the corpus and exits early if unchanged; the heavy pass runs only on real deltas, with the stable corpus behind a cache prefix. Ninety-plus percent cost reduction, identical output. Every scheduled loop deserves the question: *what does the cheapest possible first step know?*
## Lab (10 min)
1. Pick your three most-used automations/commands/skills. Score each on the five moves (0–3); write the vector. 2. Run the gen/eval test on each: pass / soft fail / hard fail. Be harsh — self-review is a soft fail. 3. For your worst verification score: design the cheapest *independent* evaluator (prefer runtime proof), and write the goal as target-state + budget + escalation. Implement it if it's a 15-minute fix — it usually is. 4. Check one scheduled loop for token blowout: what context does it load per run, and could a cheap pre-check gate the expensive pass?
## Key takeaways
A loop is a system that prompts the agent so you don't have to; your job migrates from inside it to outside it. Five moves: discovery, handoff, verification, persistence, scheduling — report the vector; verification is the move that keeps loops honest. The gen/eval test gates everything: separate the judge from the maker, feed the judge independent information, prefer runtime proof. Goals are termination conditions: target state + budget + escalation, machine-checkable. Watch the four silent costs — verification debt, comprehension rot, cognitive surrender, token blowout — and remember that scheduling multiplies whatever the loop already is.
## Lecture
One loop eventually isn't enough — the task outgrows one context window, or demands perspectives that shouldn't share one. This session is Law 1 (context scarcity) and Law 3 (gen/eval separation) applied at scale.
Subagents: context isolation as a feature. A subagent is a fresh agent spawned by a parent (the `Agent` tool in Claude Code/SDK). It inherits standing configuration (CLAUDE.md, system prompt) but *not* the parent's conversation. It burns its own window on the messy work — reading forty files, chasing dead ends — and returns only its conclusion; the parent's window receives a paragraph instead of a novel. Three reasons to spawn one: context economy (exploration is high-volume, conclusions are small), specialization (a focused prompt with restricted tools outperforms a generalist on a narrow task), and independence (an evaluator that never saw the generator's reasoning can't inherit its blind spots — the mechanical basis of honest verification). Corollary: subagents are why gen/eval separation is *cheap*. The judge is one spawn away.
Fan-out patterns (Anthropic's workflow patterns, in orchestration dress):
- Parallel fan-out: independent workers on independent items — N files, N sources, N dimensions of review. Wall-clock ≈ slowest worker, not the sum. - Pipeline: each item flows through stages independently — item A can be in stage 3 while B is in stage 1. Default for multi-stage work; no waiting on stragglers. - Barrier: all results collected before proceeding. Justified *only* when the next stage needs cross-item context — dedup across findings, early-exit on zero results, "compare with the other candidates." Otherwise it's wasted idle time. - Orchestrator-workers: a lead decomposes, delegates, synthesizes. The orchestrator holds the map, never the territory. - Evaluator panels: N independent skeptics per claim, majority-vote survival; or better, *diverse lenses* (correctness, security, does-it-reproduce) — diversity catches failure modes redundancy can't.
Choosing pipeline-vs-barrier is context engineering by another name: a barrier is a decision to *merge* information streams; only pay for it when the merge is the point.
MCP: the tool bus. The Model Context Protocol is the open standard for handing agents external capabilities — Slack, Airtable, Stripe, Figma, your own services — as tool servers. It's what makes orchestration reach beyond the filesystem. Three architect-grade facts: (1) tools are *context*: every schema loaded is tokens spent, which is why harnesses now defer MCP schemas and load on demand via tool search — dozens of connected servers, near-zero standing cost. (2) Config is layered like everything else: project `.mcp.json`, user-level, plugin-bundled. (3) Building your own MCP server is the standard way to give every Claude surface — Code, Cowork, the SDK — the same door into your product. One integration, all harnesses.
Context engineering: the craft. The discipline of deciding what's in the window, in what order, at what price:
- Order for the cache (S1): stable prefix first — system prompt, skills, reference corpus — variable request last. Cache reads at 0.1x make stable context nearly free; churn breaks the prefix and re-bills it. Design prompts like cache-friendly URLs. - Compaction: when a long session nears its limit, the harness summarizes history to reclaim space. Lossy by nature — the overnight-agent anecdote (S4) is what compaction does to unprotected constraints. Anything that must survive compaction belongs in a *file*, not the transcript. - Context editing (beta): surgically removing stale tool results/definitions mid-conversation — finer-grained than compaction. - The memory tool / auto memory: durable, model-maintained notes re-inserted across sessions — statelessness (S1) bridged by scaffolding, selectively. - The summarize-vs-spawn decision: to reclaim space you can compress the past (summarize: keeps one thread, loses detail) or isolate the future (spawn a subagent: full fidelity in a fresh window, costs coordination). Rough rule: summarize *narrative*, spawn for *work*.
The economics of fan-out. Ten subagents cost roughly ten contexts — orchestration multiplies spend as fast as it multiplies coverage. Match model to role (Law 4): frontier model as orchestrator/judge, Sonnet 5 or Haiku 4.5 as the worker fleet; cheap pre-checks gating expensive passes (the $300-cron fix from S5, now as a fleet policy). Scale ceremony to stakes: a quick check gets one finder and one vote; an audit gets a panel.
## Anecdotes
*The 100-file review that fit in one window.* Asked to audit a large codebase, an architect didn't read files into the main session. The orchestrator globbed the tree, spawned a dozen subagents — each reading 8–10 files and returning findings-only — then a barrier (justified: dedup across findings), then one adversarial verifier per surviving finding, each given only the file and the claim. Main window at the end: file list, findings table, verdicts. Territory explored: ~40x the window's size. The orchestrator holds the map, never the territory — the sentence that unlocks working beyond context limits.
*The verifier who knew too much.* A team's review pipeline had the finder agent *hand its full reasoning* to the verifier "for context" — and verification pass-rates ran suspiciously near 100%. The verifier, marinating in the finder's argument, kept agreeing with it. Rebuilt so the verifier received only the artifact and the claim — cold — the pass rate dropped to ~70%, and the 30% it killed were real false positives. Independence isn't a separate *name* on the agent; it's separate *information*. What you withhold from the evaluator is as much a design decision as what you provide.
*One server, every surface.* A product team built a small MCP server over their internal order system for a Cowork pilot. Weeks later, without new integration work, the same server powered Claude Code sessions (support engineers debugging with live order context) and an SDK-embedded assistant in their admin panel. Cost of admission: one tool server, well-documented. That's the architectural meaning of a *standard* bus: the integration outlives the surface that requested it.
## Lab (10 min)
1. Take a task too big for one window (audit a repo, digest 30 documents). Write the orchestration plan on paper: worker count, what each returns (conclusions only!), pipeline or barrier — and if barrier, name the cross-item need that justifies it. 2. Run a miniature: spawn two subagents on different halves of a real question, then a third given *only* their conclusions, prompted to find disagreement. 3. Cache audit: open your heaviest-use prompt/skill/CLAUDE.md. Is stable content first and variable content last? Fix the order if not — it's minutes of work (S1 math says ~10x on the stable part). 4. List the MCP servers connected in your daily harness. For each: would you grant this tool to an *unattended* scheduled loop? Note the ones that fail that test — that's your permission-scoping to-do.
## Key takeaways
Subagents buy context economy, specialization, and independence — and make gen/eval separation one spawn cheap. Pipeline by default; barrier only when the next stage genuinely needs all results; evaluator panels get diverse lenses, not clones. The orchestrator holds the map, never the territory. MCP is the standard tool bus: tools are context, schemas defer, one server serves every surface. Context engineering: stable-prefix-first for cache, files for anything that must survive compaction, summarize narrative but spawn for work, and match model tier to role so fan-out multiplies coverage faster than cost.
## Lecture
Where Claude runs. Four sanctioned roads to the same models (July 2026):
1. Claude API (platform.claude.com) — first-party, highest feature parity, features land here first. 2. Amazon Bedrock — AWS-native billing/IAM/VPC; some features lag or differ (e.g., web-search variants). 3. Google Vertex AI — GCP-native equivalent; broad current-model coverage including Fable 5. 4. Microsoft Foundry — GA as of July 2026; Azure-native, with some features requiring "Hosted on Anthropic" deployments.
The cloud marketplaces exist for procurement gravity: if your compliance, credits, and IAM live in AWS, Bedrock is how Claude enters without a new vendor relationship. The architect's caution: feature asymmetry is real — verify that the specific capability you need (a web-search variant, a beta header, structured outputs) exists on your chosen road before committing. Claude Code and the Agent SDK can all be pointed at Bedrock/Vertex/Foundry via environment switches (`CLAUDE_CODE_USE_BEDROCK=1` etc.), so the harness doesn't change when the road does.
Data residency, not data possession. The first-party API supports `inference_geo` per request — currently `"global"` (default) and `"us"` (with a 1.1x price multiplier on supported models) — plus workspace-level geo restrictions; Bedrock/Vertex/Foundry handle regionality through their own deployment machinery. EU-specific residency remains a visibly in-demand gap. If a client asks "can our data stay in-region," this — not local hosting — is the conversation.
The local question, answered honestly. *You cannot run Claude locally.* Anthropic has never released Claude's weights, and that's deliberate, standing policy — there is no self-hosted, on-prem, downloadable Claude, and no enterprise tier that changes this. Every "run Claude locally" tutorial is either confused or describing something else (a local *client* talking to the cloud API). When you hear "store the model locally," translate to the three things people actually mean:
- *Local tooling, cloud inference*: Claude Code, the SDK, your harness all run on your machine — every model call still goes to a cloud endpoint. This is the normal state and satisfies most "local" wishes people actually have. - *Data control*: residency (`inference_geo`), retention terms, cloud-provider VPC isolation via Bedrock/Vertex/Foundry. Contractual and architectural, not on-device. - *Genuinely offline/private inference*: possible only with open-weight models — a different model family, honestly weaker at the frontier, but real.
The open-weight local stack (2026), so you can speak it fluently: Runtimes: Ollama (easiest: `ollama pull`, `ollama run`, OpenAI-compatible local API; models stored under `~/.ollama/models`), LM Studio (GUI), llama.cpp (the underlying engine), vLLM for production serving. Model files ship as GGUF — a single binary packing weights, tokenizer, and metadata, typically quantized. Sizing rules of thumb: Q4 quantization needs roughly 0.5GB of VRAM/unified memory per billion parameters — a 7–8B model fits in 4–6GB, a 70B model wants ~40GB (large-RAM Apple Silicon handles it via unified memory); keep 100GB+ of disk if you collect models. Treat specific speed/benchmark claims as approximate and dated — this corner of the field moves monthly.
The hybrid pattern — the architecture that makes local + Claude a system rather than a debate: route by task criticality. Local open-weight model for high-volume/low-stakes/privacy-bound work (drafting, tagging, local embeddings, redaction *before* anything leaves the machine); Claude for judgment, complex reasoning, and anything customer-visible; a router/gateway (LiteLLM-style proxy) presenting one API with fallback rules. It's Law 4 with a longer menu — and the same warning in both directions: frontier prices for mechanical work waste money; local models trusted with irreversible judgment waste something worse.
Claude in your IDE — the distinction that sorts confusion. Two different things ship under "Claude in my editor":
- Claude Code *in* the IDE (Anthropic's harness): the VS Code extension (graphical panel, inline diffs with accept/reject, `@file#L5-10` mentions, plan review, checkpoints) and the JetBrains plugin (needs the CLI on PATH; IDE diff views; diagnostics sharing). Both auto-run a hidden `ide` MCP server exposing real IDE state — diagnostics, selection — to the agent. Full harness: your CLAUDE.md, skills, hooks, permissions all apply. - Claude *as a model* in third-party harnesses: Cursor, Windsurf, and GitHub Copilot let you select Claude models — but the harness is theirs. Their context assembly, their permissioning, their agent loop; your Claude Code configuration does not follow you there. Not an Anthropic product surface — a model-supply relationship.
Both are legitimate. The architect just never confuses *model* with *harness*: "we use Claude in Cursor" and "we use Claude Code" are different systems with different capabilities, and by now you can enumerate exactly which (skills? hooks? subagents? checkpoints? your permission rules?).
## Anecdotes
*The on-prem ask.* An enterprise prospect told a founder: security requires the model on their infrastructure — could he "get the Claude weights under NDA"? No — no one can; that's policy, not pricing. The deal survived anyway: workspace-restricted `us` inference geo, Bedrock inside the client's own AWS org for IAM/VPC alignment, and a local redaction pass (small open-weight model) stripping PII before any token left their network. The lesson generalizes: "local" is almost always a *proxy requirement* for control, residency, or privacy — solve the real requirement and the proxy dissolves.
*The 70B on a MacBook.* A developer ran a 70-billion-parameter open model on a high-memory Apple Silicon laptop — genuinely useful, genuinely private, and noticeably behind Sonnet 5 on hard reasoning. Their verdict was the architecturally correct one: not "local wins" or "cloud wins" but a routing table — local handled bulk summarization and anything touching sensitive files; Claude handled the thinking. The interesting question is never *which*; it's *what routes where, and what checks the router*.
*"Claude works differently on my machine."* Two engineers, same team, both "using Claude for coding" — one in Cursor, one in Claude Code with the team's repo config. Their outputs diverged; confusion followed. Diagnosis in this session's vocabulary took one sentence: same model, different harnesses — the Cursor user had none of the team's CLAUDE.md conventions, hooks, or permission gates. The fix wasn't picking a winner; it was knowing which system each person was actually operating, and porting the team's non-negotiables (the deterministic-space checks, per S3) into CI where every harness meets them.
## Lab (8 min)
1. Say the sanctioned-roads list from memory: four ways to reach Claude models, plus what `inference_geo` does and its current options. 2. Rehearse the local answer aloud, sixty seconds, as if to a security-minded client: why there's no local Claude, the three things "local" usually really means, and the hybrid pattern. (This exact speech is a capstone oral item.) 3. If you use a third-party AI IDE: write the two-column list — which capabilities you get there vs in Claude Code (skills, hooks, checkpoints, subagents, your permission rules). Decide, deliberately, which harness owns which part of your day. 4. Optional, if hardware allows: `ollama pull` a small model, find the GGUF on disk under `~/.ollama/models`, and note its quantization suffix. Ten minutes to permanent fluency in the local stack's vocabulary.
## Key takeaways
Four roads to Claude: first-party API (feature-first), Bedrock, Vertex, Foundry (procurement gravity; verify feature parity per road). Data residency is `inference_geo` and deployment machinery — not possession. No local Claude, ever, by policy: translate "local" into control/residency/privacy and solve those. The open-weight stack (Ollama, GGUF, quantization math) is real and useful — as the cheap/private tier of a *routed* hybrid, per Law 4. And in editors: Claude Code in the IDE is Anthropic's full harness; Claude in Cursor/Windsurf/Copilot is Anthropic's model in someone else's harness — never confuse model with harness.
## Part II — The Architect's Operating System
The operating principles — the daily discipline that makes the stack trustworthy:
1. Runtime-first verification. "Looks correct" is not a verification state. Run it, click it, curl it, read the logs; the artifact's *behavior* is the only evaluator that can't be sweet-talked. Debugging works the same way: reproduce the live failure before touching source. Reading code tells you what should happen; runtime tells you what does. 2. Gates, not vibes, before irreversible steps. Anything that ships — a deploy, a publish, a send — passes an explicit sequential gate: health, then tests, then security/permissions review; any red stops the line. Gates are deterministic-space (S3): they run every time *because they are not optional judgment calls*. The generator never operates the gate it's passing through (S5, Law 3). 3. Judgment budget accounting. You have a fixed daily supply of real attention. Spend it where it's irreplaceable — reviewing the one diff that matters, killing a bad idea early — and engineer everything else into loops with evaluators. Audit quarterly for the silent costs (S5): the loop you no longer read, the approval you now rubber-stamp, the meter nobody watches. Deliberately keep one or two loops manual as judgment exercise. 4. Small blast radius by default. Scoped permissions, checkpoints before bold moves, unattended loops holding strictly fewer capabilities than interactive sessions (your S6 lab question — "would I grant this tool to an unattended loop?" — is a standing policy, not a one-time audit). 5. Verify against the live world. Docs over memory — the platform moves faster than anyone's recall, yours or the model's. Current facts get checked at platform.claude.com/docs and code.claude.com/docs; time-boxed facts (intro prices, betas, promos) get dates attached when written down. This track obeyed its own rule; so should everything you build from it.
The maturity ladder — locate yourself, then climb one rung at a time: (1) *Chat user* — asks, accepts, copies out. (2) *Tool user* — right surface per task, decent prompts. (3) *Configurer* — CLAUDE.md, skills, permissions tuned; the harness fits like clothes. (4) *Loop builder* — recurring work runs itself, with evaluators. (5) *Architect* — a portfolio of loops across surfaces with routing, gates, telemetry, and a judgment budget consciously spent. The 80th-percentile bar this track promised sits at rung 4 solid, rung 5 conversant — the capstone tests exactly that.
The capstone. The proof of the whole course: design, build, schedule, and verify one loop that does real recurring work from your life — written goal spec (target state + budget + escalation), generator and evaluator as separate agents with the evaluator receiving only independent inputs, state externalized to files/git, server-side scheduling, unattended-grade permissions, and runtime logs including at least one evaluator catch. Passing = five-move score ≥12/15 with verification = 3. A gate never tested red is a decoration.