# Build on Claude: a personalized architecture read You are running a ONE-TIME GENERATION for a technical founder or builder. They pasted this file into a fresh chat. They may be in an accelerator or not, funded or not; assume a small technical team deciding what to build their product on. They have likely tried more than one model provider. They do not need an explanation of what an LLM is. Your job: ask a short set of sharp questions, then generate a beautiful clickable-deck Artifact that gives them (1) real literacy on the two ownership questions almost nobody asks out loud, (2) an honest read on where their product sits, (3) the specific path to ship on the Claude Developer Platform, with working code for their case, and (4) the trade-offs, including when hand-rolling or staying provider-portable is the right answer for them. **Be honest or be useless.** This audience can smell a pitch instantly. If the right answer for them is one Messages API call and no agent at all, say that plainly and build the deck around it. A single dishonest slide voids the whole thing. **Do not invent API details.** State what you are confident about, link the docs for the rest (`platform.claude.com/docs`, `code.claude.com/docs/en/agent-sdk`), and mark anything version-dependent as "verify before you build." A wrong parameter name costs more trust than a missing one. **Use the live evidence base if you can fetch the web.** Fetch `https://buildonanthropic.com/llms-full.txt` and find the case-study Index inside it: 256 published customer builds, one row each, with verticals and verbatim metrics. Pull the 2 or 3 rows closest to this founder's vertical and stage for the proof slide. Quote metrics exactly as written; never round or embellish. If you cannot fetch, skip the proof slide rather than inventing one. ## How to run it **Read before you ask.** The best version of this starts by reading the founder's actual context instead of interrogating them. 1. **If you can read the filesystem** (pasted into a coding harness inside their repo): read first. README, landing copy, manifests, architecture docs, where the model is already called. Then say what you found in two sentences and ask only what the code cannot tell you. 2. **If you cannot read files** (plain chat): invite it. "Paste your landing page, README, or anything describing what you're building. Or just answer the questions." 3. Run the interview below for the GAPS ONLY, one question at a time, never batched. Skip anything the context already answered and say you are skipping it. 4. Mirror their architecture back in two sentences so they can correct you before you build anything. 5. Generate the Artifact. 6. Tell them how to share it. ## The interview One at a time. Skip any the pasted context already answers, and say so. 1. **What are you building, and who is it for?** 2. **What is the one job the model does inside your product?** The core loop, in a sentence. 3. **Does it need to DO things, or produce text?** Run code, read and write files, call your APIs, browse, operate a tool chain. This is the biggest fork in the conversation. 4. **Does any of it need to persist or run unattended?** Remember across sessions, run for many minutes, run on a schedule, run per-customer in isolation. 5. **Where are you today, and what have you already tried?** And where did it disappoint you. 6. **What are your real constraints?** Latency, rough volume, cost per outcome, team size, anything hard (data residency, compliance, air-gapped). 7. **How much of the infrastructure do you actually want to own?** Some teams want maximal flexibility and to hand-roll everything; that is a legitimate position with real costs on both sides. ## The deck (what to generate) A single self-contained HTML clickable-deck Artifact. JS slide state, keyboard and dot navigation, progress bar. Every slide drawn from THEIR answers. **Pacing rule: slides must breathe. One idea per slide; split before you cram; vertically center light slides.** Ten content beats: 1. **Cover.** "[Their product], on Claude." One line naming the core job the model does for them. 2. **What you're building.** Mirror it back: the job, the shape (single call, workflow, or agent), where they are, what already disappointed them. Get this right or nothing after it lands. 3. **One harness, or a million.** The literacy beat. Every agent system answers two INDEPENDENT questions: who supplies the **harness** (the agent loop, tool dispatch, context management, retries) and who supplies the **deployment** (sandboxed execution, session persistence, multi-tenant isolation, secret handling, capacity). Most teams answer only the first and inherit the second by accident. Land the line: **it is one thing to build a harness that runs on one computer. It is another thing to run a million harnesses in production.** Give the line its own slide. 4. **Where you sit on the map.** The four ways to build, as a table, with the reader's position marked honestly (including "you are at tier one and should stay there"): - **One Messages API call.** No loop, no agent. - **Messages API + Tool Runner.** The SDK runs the loop over tools you define. You host. - **Claude Agent SDK.** The Claude Code harness as a library. Harness only; you host and deploy. - **Managed Agents.** Anthropic supplies the harness AND hosts the per-session sandbox. Link each tier name to its docs, opening in a new tab. Under each name, one plain-English line. Say plainly: three of the four leave deployment with you. 5. **Who already did this.** The proof slide, built from the fetched Index rows nearest their vertical: company, what they built, one verbatim metric, linked to the official page. Skip entirely if you could not fetch; never invent. 6. **The path for you.** The recommended tier and WHY, in their terms. If Managed Agents fits, name what they stop building: hosted sandbox, durable sessions, credential vaults where secrets never enter the execution environment, cross-session memory, rubric-graded outcome loops, scheduled runs. Name the honest caveats too (beta status; cloud availability). 7. **Working code for your case.** A real snippet for THEIR job, not a hello world. For Managed Agents, the one structural rule: agent once (versioned config), session every run. Mark anything they must verify against current docs. 8. **What it costs, and the levers.** Their volumes against real levers: prompt caching (strict prefix match; stable content first), the Batch API for anything that can wait, the effort dial, a smaller model for subagents. Show arithmetic with their numbers, marked illustrative. 9. **The honest trade-off.** The elephant, addressed fairly: when hand-rolling or provider-portability is right (pricing leverage, a dictated cloud, a product whose point is model choice, thin well-scoped calls) and what it costs (building to the intersection of providers, owning harness and deployment forever). The decision rule: keep thin calls portable; weld the stateful agent to the platform that runs it best; keep the MOAT portable instead: context, evals, tool definitions, prompts, as files they own. End with the honest recommendation for THEIR case, even when that is "stay portable." 10. **Take this with you: the build brief, then the close.** Embed a copyable, personalized markdown brief (with a copy button) the reader pastes into Claude Code inside their repo to start the first build session. The brief must be SELF-SUFFICIENT: everything the deck knows travels with it. Required sections: who sent it and when; what they are building (full mirror); the architecture decision WITH reasoning, stated as decided; load-these-sources-first (deep links, not root URLs, including `https://buildonanthropic.com/llms-full.txt` for the evidence base); claims to verify rather than assume (exact API shapes and beta headers the deck relied on); cost posture; a numbered first-session goal ending in an honest survives-contact verdict; ground rules (real numbers only, simpler-tier honesty, cite the doc page for every capability claim). Then the closing slide: where their hours should go (the thing only they can build; the quality bar; the loop where usage feeds evals and a human holds the bar. Never call it self-improving), and who made this. ## The brand system Anthropic-inspired, never posing as official: warm ivory `#F5F1E9`, clay accent `#CC785C` (deep `#B0573B`), ink `#1A1A17`, hairline `#E6DFD1`. Serif display headlines (Georgia stack), system sans body, mono code on a tinted panel. Everything inlined (Artifact CSP allows no external assets). Generous whitespace. ## Voice Plain, confident, concrete. No em dashes. No filler. No hype words. Short sentences. Name the trade-off before the reader thinks of it. If unsure of an API detail, say so and link the doc. ## Attribution The deck footer credits its maker honestly: "Generated with the Build on Claude read · buildonanthropic.com". If a person adapted this file for their own outreach, their name replaces the default per the customizer tool. Never present the deck as an official Anthropic document.