Foundations Β· Milestone Companion: Be Right Before You Are Heard
What this milestone asks
Write a 3,000-word essay titled "Agent 101 for non-technical friends," then hand it to a real layperson β not a colleague, not a fellow enthusiast β and ask them to retell it back to you in their own words. The retelling is the deliverable, not the essay. The stage goal behind it: an evangelist's biggest risk is being wrong, so spend a full month on fundamentals before publishing anything. Concretely: explain the Transformer to three audiences (a child, a product manager, an engineer), keep a fact ledger with traceable sources and confidence levels, follow primary sources, and understand costs and limits at least as well as capabilities.
Why this milestone
Evangelism is a credibility business. A builder who ships a buggy demo can patch it next sprint; an evangelist who publishes a confident error teaches hundreds of people something false, and the correction never travels as far as the original claim. The layperson-retelling test exists because it is the only test you cannot game. Technical readers silently correct imprecision as they read; laypeople cannot β they absorb exactly what you wrote. If your explanation of attention, context windows, or tool calling survives being retold by someone with no background, it is probably accurate. If it comes back mangled, the mangling is a precise map of where your writing traded truth for fluency.
The three-audience test works the same way. Explaining the Transformer to a child forces analogy; to a product manager forces value framing; to an engineer forces mechanism. If you can only do one register, your audience will notice within two paragraphs.
How to use the resources
Sequence matters more than coverage:
Week 1 β mechanism intuition. Start with 3Blue1Brown's neural network and attention series, watching each video three times: once for the concept, once for the analogy, once to study how animation carries intuition. Then watch Andrej Karpathy's Intro to LLMs, widely regarded as the narrative benchmark for LLM technical storytelling.
Week 2 β structured depth. The Hugging Face LLM Course is free and systematic; MIT 6.S191 (2026 edition open-sourcing lectures weekly from March 30, Alexander Amini among the opening lecturers) gives the deep-learning substrate fast and dense. To see a top program decompose a hard topic into clean lectures, study Princeton COS 597G Understanding LLMs β Danqi Chen's Fall 2022 slides are public. Stanford CS25 Transformers United shows how frontier researchers present this material themselves.
Week 3 β primary sources and the fact ledger. Open a spreadsheet now, not later, with columns for claim, source (paper or official doc only), date checked, confidence, and the exact sentence you plan to publish. Every capability claim in your essay must trace to this ledger. For field-level numbers β adoption, costs, trends β the Stanford HAI AI Index report is the authoritative source; cite it rather than secondhand summaries. When a blog post says "research shows," find the research.
Week 4 β costs, limits, and writing. Spend two full days on what agents cannot do: context limits, hallucination, tool-use failure modes, real token economics. Understanding cost and limits matters more than understanding capability, because your audience's first decision is not "how does it work" but "should I trust it." Then write the 3,000 words. Read Andrew Ng's AI-for-everyone-style material first β the model for addressing non-technical audiences without condescension β and Steven Pinker's The Sense of Style before drafting.
The retelling session. Do it live. Hand over the essay, leave the room, come back, and say: "Now explain agents to me as if I knew nothing." Record it (with permission). Every stumble is a revision task; every confident repetition of something you did not write is a factual emergency.
Common failure modes
- Writing for the reader you wish you had. An essay that secretly assumes the reader knows what an API is. The retelling test catches this brutally.
- Analogy without mechanism. "It's like a new hire" is a fine opening, but if the reader cannot say what the new hire actually does β predicting tokens, calling tools, reading a limited context β you have entertained, not explained.
- Capability-only essays. Three thousand words of wonders with zero on failure modes is marketing copy, not evangelism β and it will be quoted back when the reader's first real attempt fails.
- Sourcing from summaries. Citing another explainer's claim about a benchmark instead of the benchmark itself. The fact ledger exists precisely to prevent this.
- Skipping the retelling because the essay "reads well." Readability and accuracy are different axes; only the retelling measures the second one.
Acceptance checklist
- The essay is complete at roughly 3,000 words, titled "Agent 101 for non-technical friends" (or a close variant).
- You can explain the Transformer to a child (analogy), a product manager (value), and an engineer (mechanism) β all three, live, without notes.
- Your fact ledger contains every factual claim in the essay, each with a primary source, a check date, and a confidence level.
- The essay contains at least one substantial section on costs, limits, or failure modes.
- A genuine layperson has read the essay and retold it back to you; you have a recording or written notes of the retelling.
- Every place the retelling diverged from your intended meaning has been fixed in a revised draft.
- No claim in the essay traces only to another explainer, a news article, or your own impression.
Going further
Publish the revised essay. It is your first credibility asset β the thing you point to when you later ask for a talk slot or a reader's trust. Keep the fact ledger alive: in Stage 3 it becomes your topic pool, in Stage 4 the backbone of your enterprise case library. And keep the retelling ritual β every future piece gets one layperson pass. The explanations that survived become the analogies for your Stage 2 video.