AI

2026-11-06 · open the original ↗

• Three developments converged to make modern LLMs possible. These were the 2017 transformer architecture, the explosion of digital training data (websites, code repositories, other text), and big gains in compute (GPUs, TPUs, clusters). Scaling laws showed performance improving predictably with size, and abilities nobody programmed appearing as models grew.
• Training turns a document completer into an assistant. Pre-training on next-text prediction produces "a very competent, literal document completer". Fine-tuning with human feedback and reinforcement learning then teaches it to follow instructions and avoid harm. A prompt is continued from learned patterns, not looked up in a database.
• Strengths: versatility, conversational memory and tool use. One model switches between tasks without retraining, keeps track of earlier points in a conversation, and can increasingly search the web, process files or use other applications.
• Each limitation traces back to how these systems work. The lesson lists knowledge cutoffs (e.g. a November 2024 cutoff means no later data), hallucinations from unverified training data and statistical generation, a context window that drops content first-in-first-out, non-deterministic output (adjustable via "temperature"), weakness on multi-step reasoning (improving with extended-thinking models), and no access to data or tools it hasn't been given.
• The best results pair human judgment with AI speed and scale. Humans contribute critical thinking, creativity and ethical oversight; AI contributes pattern recognition and volume. The lesson expects some limits to remain even as retrieval-augmented generation and tool use improve, without knowing which ones.

2026-11-06 · open the original ↗

• The framework runs as two loops of different scope. The inner Description-Discernment loop covers day-to-day interactions. The outer Delegation-Diligence loop covers whether to use AI at all and the ethical responsibilities around it. The lesson calls the inner loop critical but not sufficient alone.
• Good Description covers the output, the method and the AI's role. Beyond output, format, audience and style ("summarize for a non-technical executive audience, three highest-impact findings, under 300 words"), you can specify the steps and reasoning approach, and the stance: critical reviewer, brainstorming partner, or fact checker.
• Discernment is the rarest skill and the biggest gap. In Anthropic's research, Description behaviours came most naturally, while questioning AI's reasoning, checking facts and spotting missing context were among the least common behaviours observed. Discernment means iterating, not just accepting or rejecting output.
• Delegation requires understanding both the work and the tool. A routine status update can take an AI first draft; a sensitive negotiation needs the person's own tone. Confidential data calls for checking the system's privacy and security features first.
• Diligence means transparency and full accountability for the result. That covers choosing systems deliberately, telling colleagues and stakeholders when AI was involved, and checking every claim before sharing. The lesson says diligent practice in turn sharpens later Delegation decisions.

2026-11-06 · open the original ↗

• Building is the whole arc, not just the coding. Michael (CEO of CodePath) and Kristen (Anthropic education team) describe the job as finding the problem worth solving, making hundreds of design decisions, shipping, and learning from what follows. They argue most AI training covers only the prompt-to-code slice, which is useful but not enough.
• Delegate implementation, but usually not judgment. In the 4D Framework (Joseph Feller and Rick Dakan with Anthropic), Delegation means breaking the problem into parts and assigning AI a role at each. The call on whether something is actually good and ready is the part the course advises against handing off.
• Many failures that look like code problems start in Description. A user complaint traced back often lands not in the code but in how the builder understood and described the user's problem. The lesson says passing tests are necessary but not sufficient.
• Discernment catches what runs but fails anyway. Its examples are code that is locally correct but breaks under load, and UX that works but confuses. Diligence means owning the outcome, including migrations, rate limiting, monitoring and the 2 a.m. outage: "prototype freely, ship selectively", and be willing to veto your own build.
• Treat AI as a capable but very literal collaborator. It is fast and tireless but needs clear tasks, real context about why something is being built, and specific feedback. The course frames managing that collaborator as its core skill.

2026-11-06 · open the original ↗

• A personal AI use policy records decisions and the reasoning behind them. It gathers your articulated practice, lens analyses, Delegation decisions and Diligence commitments; it is for you first, and a reference when clients, collaborators or audiences ask. Three questions anchor it: where AI fits and where it does not, what you disclose and to whom, and when you will revisit it.
• Value Lens ratings rule AI out of high-connection, high-expression work. In the worked example, Sam's children's books rate high on all three dimensions and editorial work rates high expression, medium connection and high distinctiveness, so AI in the final work is excluded for both. Commercial work, rated medium expression, low connection and medium distinctiveness, with the brand carrying the audience relationship, leaves AI more room.
• AI saves time only where execution, not conceptual work, binds. Time is Sam's binding constraint in every mode but works differently in each. AI as Consultant during research could free editorial time for the load-bearing concept work, and Tool Builder could handle commercial asset variations and formatting; children's books gain nothing, because their constraint is conceptual time, which is the human work itself.
• The result is a portfolio of mode-and-task decisions, not one stance. Sam ends with No AI across all visible stages of children's book work (readers and publishers expect a specific human presence), Consultant in editorial concept research, and Consultant or Tool Builder in commercial work. Each decision comes with its reasoning and Diligence attached.
• The policy needs revision triggers, or it goes stale silently. Sam would revisit it when the work shifts, the tools change or the practice evolves, treating it as a living document rather than a fixed statement.

2026-11-06 · open the original ↗

• Five delegation outcomes split on whether AI reaches the audience. No AI, Consultant and Tool Builder keep AI-generated material out of the final work; Co-Creator and Medium put it in. The roles are a vocabulary rather than a hierarchy, and one creator may land differently across projects or across tasks in one project.
• A No AI boundary needs explicit edges. It tends to fit when distinctiveness depends on decisions AI would homogenize, or when skill development is the goal. Without stating whether it covers research, reference gathering and admin, AI can creep into stages the creator never consciously analyzed.
• Consultant use risks quietly adopting AI's framing. Brainstorming with AI and drafting independently is Consultant; carrying its phrasings or framings into the draft moves to a different outcome. Working material put into a tool raises privacy questions, and the strongest consulting uses start from the creator's own framing rather than asking AI to frame the problem.
• Tools built with AI embed decisions into the work. For Tool Builder (batch scripts, asset managers, template systems), disclosure lands differently on the tool than on the work made with it. The Diligence question is whether the tool automates something that truly needs no attention, or a decision that should stay with the creator.
• Co-Creator and Medium carry the heaviest Diligence load. Co-Creator raises disclosure under contracts, field norms and platform rules, unsettled IP status in many jurisdictions, and drift toward accepting rather than directing output; what holds up is setting standards before generating and being willing to discard. Medium, where the audience interacts with AI (interactive characters, generative installations, NPC systems), makes the creator responsible for system behavior, edge cases and disclosure for as long as the work runs.

2026-11-06 · open the original ↗

• Understand the problem and the tool before delegating any task. Delegation runs in order: Problem Awareness (from the earlier articulation work), Platform Awareness (what a tool does, its tendencies and limits), then Task Delegation. The lesson adds that today's AI is the worst you will ever use, so platform capabilities keep shifting.
• Diligence splits into Creation, Transparency and Deployment responsibilities. Creation Diligence is careful tool selection and terms of use; Transparency Diligence is meeting the disclosure expectations of audience, client, field and contract; Deployment Diligence is verifying output against your standards and standing behind what is released, however it was made.
• A worked example shows the loop yielding a defensible, not single, answer. Tom, a graphic designer building a brand identity for a regional arts organization, studies several tools' aesthetic tendencies and uses AI only for initial concepting and palette tests. He checks the tools' terms for uploaded work, confirms the client is comfortable with AI involvement, and verifies the exploration has real range and reflects the community rather than tool defaults.
• Convergence and skill atrophy are the long-term pitfalls. Work can drift into the same visual neighborhood as everyone using the same model even while steering hard, so locate where the distinctive part of your work is made: AI mood boards may be low risk for a brand designer, AI final marks are not. Atrophy matters because good direction depends on knowing execution from the inside; check finished work against your standards, not against what the tool produces easily.
• Reaching for AI when unsure what you want means stepping back. The analysis starts from no AI, and both no AI and heavy AI involvement are valid outcomes. What matters, the lesson says, is that the decision is made on purpose.

2026-11-06 · open the original ↗

• Unarticulated practice leaves you exposed once AI enters. Most creators, even with decades of experience, have never put their practice into words because doing the work doesn't require it. With AI, vague description produces generic output, and standards that exist only as gut feeling make you likelier to accept whatever comes back.
• Product standards must be specific enough to teach a peer. Describe the specifics ("editorial illustrations, typically conceptual rather than representational") rather than the category, and name what makes the work yours, such as palette, line quality and emotional register. "It feels right" does no work; "the figures have weight, and the negative space carries half the composition" does. Without this, good enough wins by default because it doesn't look wrong.
• Process standards belong at the level of each step. Map where key decisions really happen (concept for some creators, revision for others), the hard stages, the handoffs to other people and the feedback relied on. Honest mapping tends to show that messy stages do more work, and "wasted" time matters more, than creators expected; step-level standards let you judge whether AI at a given step helped, rather than finding out from the output when it is too late.
• Performance, your behavior as a working creator, is most affected by AI. It covers the conditions of your best work, what a stuck or compromised state looks like, and how you respond to feedback, pressure, isolation and collaboration. AI compresses timelines and shifts the balance of solitude and collaboration, and whether that helps depends on the person.
• Diagnostic signals catch decline, including skill atrophy, before outcomes do. Outcome measures say something went wrong; diagnostic signals warn while there is still time to act. This is where the slow decline of unused execution skills shows up, which matters because "you can't direct what you can't recognize."

2026-11-06 · open the original ↗

• AI Fluency is four competencies arranged as two nested loops. It is defined as interacting with AI effectively, efficiently, ethically and safely, through Delegation, Description, Discernment and Diligence. Description and Discernment form the inner loop inside each interaction; Delegation and Diligence form the outer loop around it. The page notes the video is shared with the AI Fluency: Framework and Foundations course, while the exercise is new and creative-specific.
• Description covers the output, the approach and the AI's behavior. Beyond prompting, it means specifying output, format, audience and style, as in asking for a summary for a non-technical executive audience, focused on the three highest-impact findings, in under 300 words. It also means setting the steps or reasoning to follow, and the role wanted, such as critical reviewer, brainstorming partner or fact checker.
• Discernment is the rarer, more important skill. Anthropic reports that in its research Description skills came most naturally, while questioning AI's reasoning, checking facts and spotting missing context were among the least common behaviors observed. Discernment evaluates both the output and the process behind it, and feeds refinement of the next Description.
• Delegation means understanding both the work and the tools. It decides what humans do and what AI does: a routine status update may suit an AI first draft, while a sensitive negotiation needs your own tone. Tool knowledge matters too, such as privacy and security features when handling confidential data.
• Diligence keeps you accountable for the final result. It covers choosing systems thoughtfully, being honest with colleagues and stakeholders about AI's role, and verifying and vouching for every output shared. Diligent practice in turn informs better Delegation over time.

2026-11-06 · open the original ↗

• Technology rarely removes production constraints; it rearranges them. The lens pairs Production Constraints (Time, Effort, Resources) with Technological Complexity, citing the printing press and digital photography as earlier instances. Digital recording cut studio and equipment costs to a bedroom laptop and microphone, but moved those costs into years of learning audio software, mixing and mastering.
• AI's fast generation carries new time costs that can exceed the savings. Learning the tool, prompting, reviewing against your standards, re-prompting and verifying accuracy all take time. Whether the net is positive depends on the task, the creator's skill and the standards applied; for a personal essay, the writer trades sentence-level drafting for more time deciding voice, structure and purpose.
• Effort shifts from execution to direction, which requires execution knowledge. Knowing what you want, recognizing quality and articulating standards become more valuable. Execution skills may matter less for production but stay essential for direction, because "you cannot direct what you cannot recognize."
• AI introduces constraints that did not exist before. The lesson names dependence on continued tool access and real switching costs, steep and continual learning curves, and audiences pattern-matching against AI outputs, which shapes how work is received whether or not AI was used. A designer's hidden costs include learning time, workflow changes and reliance on one tool's availability.
• As production costs fall, the Value Lens becomes the differentiator. If baseline output approaches zero cost, what distinguishes work is what it is for, who it speaks to and what makes it specific. Expression, Connection and Distinctiveness therefore matter more, not less.

2026-11-06 · open the original ↗

• Expression value depends on the piece, not the creator. Expression is the compelling experience for both maker and audience, rated high, medium or low within one practice. The lesson's example is an illustrator doing high-expression children's books and medium-expression product packaging in the same week, with different standards and different AI questions for each; low-expression work is not something to apologize for.
• Connection lives between people and is damaged by deception. It depends on the audience's perception of who made the work and why, from high (a personal essay, where the reader is in a relationship with a specific writer) to medium (a grant proposal) to low (an anonymous or interchangeable creator).
• Authenticity has two parts: your decisions, and audience perception. Work reflecting your decisions throughout, with a process you can describe honestly, is more authentically yours than accepted AI output you never wrestled with. Even then, if AI changes a human presence the audience expects, that matters, which is why Connection is the dimension most affected by how AI use is perceived.
• Distinctiveness comes from specific decisions, and AI converges outputs. Distinctiveness combines originality with specificity of execution; a new production of Hamlet is distinct through its costume, set, lighting and performance choices, not its concept. Because two creators using the same model with similar prompts get similar results, the lens shows which work can tolerate that convergence and which is corroded by it.
• The three dimensions trade off, and the lens surfaces the choice. In the example of a community arts festival poster, unfamiliar visuals raise distinctiveness but may lose the community's sense the poster speaks to them, while familiar local imagery does the reverse. The lens does not pick a side; it makes the trade-off deliberate. The page also asks creators to name mismatches between what they value and what their audience values.

2026-11-06 · open the original ↗

• The default starting position is no AI at all. Rick Dakan of Ringling College of Art and Design, one of the course's authors, rejects the public embrace-or-reject binary. The course instead gives a framework for deciding whether to opt in, and treats arriving at "no AI" through rigorous analysis and arriving at integration as equally valid acts of AI Fluency.
• Five recurring creator concerns are real and deserve answers, not dismissal. They are authenticity anxiety ("if AI touched it, is it still mine?"), dependence and lost skills, settling for good enough, slop fatigue and guilt by association, and "what I do is worthless." Dakan's own position on the last is that the creative role is changing rather than disappearing, and that a flood of generated content makes real craft with intent rarer and more legible.
• AI's pull toward the median makes your own standards essential. AI readily produces adequate, median output but struggles with work that is unique or excellent by a creator's standards. Without articulated standards, good-enough output becomes the path of least resistance and the work drifts toward the generic, sometimes losing its distinct voice.
• The course's work sits upstream of prompting. It deliberately teaches no specific tools, interfaces or prompting techniques, and points to other Anthropic resources for those. By the time a prompt is written, the key decisions (what you are making, your standards, whether AI fits the task at all) have already been made.
• There is no single right answer, only defensible decisions. Dakan says two illustrators with similar work and audiences may legitimately land in different places. The framework does not remove the work of deciding; it structures it, and is meant to stay useful as tools and the creative landscape keep changing.

2026-11-06 · open the original ↗

• Generic answers lose; put yourself in every answer. The presenter contrasts a passable "leader in local commerce, love to bring my analytics experience" answer to "why DoorDash?" with a personal one (a working parent ordering healthy food on bad work days), and frames "why this company" as a real moment with the product, then an observation, then the company's values, never perks, comp or "exploring options."
• Hypothetical questions are behavioral questions in disguise. Asked what to do when a PM wants results early, the principle answer ("balance speed with rigor") is fine. Her own story is stronger: a PM wanted to call a checkout test on day four, she held it two weeks because Sunday was the biggest ordering day, it came back flat, and she now agrees test length before launch.
• Build an "experience database" by talking, then let AI mine it. She recommends recording at least 30 minutes, unfiltered and in breaks (she did 3 hours), covering projects, people friction, mistakes, ambiguity and leadership. AI then turns it into story cards and number cards, maps them to question types and flags missing impact numbers. She advises two stories per type, because onsite interviewers compare notes in the debrief.
• Six delivery failures sink otherwise good experience. They are: principle before example, no numbers, dodging the harder version of a repeated question, a 3–4 minute answer with the result buried, numbers that "wobble" between tellings of the same story, and "we" instead of "I". Her rule is a headline result and number up front and an answer under about 90 seconds, with detail saved for follow-ups.
• A free repo scores mock answers against these failures. The "interview prep with AI" repo from AI Analyst Lab adds a mock behavioral skill with eight question types and a scorer. In the demo it rated a sample conflict answer 4/10: headline at 2:05 against a 15-second target, about 450 words, roughly 15 "we" and no action "I", and the candidate saying "there wasn't really a conflict." She says to aim for 8/10 or above.

2026-11-06 · open the original ↗

• Bad agent answers are mostly a context problem, not a model problem. Rachel of Hex argues the models are now broadly proficient. She treats agents as "very eager interns" whose quality depends on the context they get and how it is structured.
• Context management is a loop, not a one-off waterfall project. She starts from the questions users actually ask the agent rather than a pre-written list of expected questions, then builds context, measures it with evals and ships it. Some customers gate context PRs on passing evals in CI/CD, which she does not recommend as a first step. Raw Confluence, Notion, Slack or Jira content is "inputs, not context," because the AI cannot tell which pages are stale.
• Semantic models are "a dashboard in a trench coat." This is her self-described hot take. Because no one can predetermine every question, semantic models will be one piece but not the linchpin, behind table endorsement, metadata descriptions, markdown "guides" and evals.
• Hex's context consultant skill takes a gap from evidence to a merged fix. It is built around two subagents, a context architect and an eval engineer. In the demo, the Hex CLI pulled the top three suggestions, led by product-level inventory with 15 examples, and noted that two overlapped. It wrote a 59-line "product inventory metrics" guide and an eval suite on a forked context preview that passed 3/3. She concedes there was no baseline run without the guide.
• A vendor should not own your context. On Atlan or a similar catalog versus syncing into Hex, she says either works but you should pick one, because half-and-half setups drift. Shared skills should live in one central marketplace or GitHub location. She says she reads the generated evals herself for at least the first few loops.

2026-11-06 · open the original ↗

• Making a field's tacit knowledge explicit comes first, without AI. The lesson argues you can't partner well with AI in a field until you can say what quality looks like, how experts communicate, which problems matter and what standards apply. Its closing exercise drops the AI entirely and has teachers work through the 4Ds with colleagues to build a shared document.
• Discernment starts with precise quality criteria, exemplars and failures. The lesson begins with Discernment, calling it among the most important human competencies now that AI produces endless content. Its advice: replace vague words like "well-argued" with detailed rubrics, mark up outstanding published work with students, and dissect flawed examples (failed arguments, buggy code, designs that don't scale) to show exactly where they break down.
• Description comes from mapping the field's products, thinking and norms. Don't just say "lab reports". Specify the sections and why the methods come before the results. The lesson also suggests tracing how experts think, such as how a historian evaluates sources, with practitioner interviews and flowcharts. Finally, name the observable behaviours of the discipline, such as scientists' protocols for skepticism, replication and peer review.
• Delegation means breaking tasks down to see where AI fits. The lesson takes a literature review apart into finding sources, judging relevance, synthesising arguments and writing the narrative, then asks which parts can be automated. It suggests mapping what AI could automate (data cleaning, first drafts), augment (hypothesis generation, literature synthesis) or do as an agent (monitoring experiments, early feedback on student work). Then build decision trees through case studies.
• Diligence means codifying the field's own ethics, disclosure and accountability. Go beyond general academic integrity. The lesson's examples are privacy when AI analyses patient data and client confidentiality in AI-assisted legal research. It suggests disclosure templates (how to cite AI in a research paper versus a creative portfolio versus a business report) and co-created classroom policies and honour codes. The payoff it claims is that students who know their field's quality, methods and ethics can direct any collaborator, human or AI.

2026-11-06 · open the original ↗

• AI fluency amplifies disciplinary expertise rather than replacing it. The lesson frames graduates' futures around three questions. What gets automated in their field? Where does human-AI partnership add the most value? When AI works on its own, how do they manage it and stay accountable for what it does?
• Disruption varies across curriculum, pedagogy and assessment, and expertise sorts it. The lesson's examples are a stable curriculum with transformed assessment, or evolving pedagogy around a constant core. Some disruptions are opportunities and others are problems. Telling which is which takes three kinds of expertise teachers already have: disciplinary (the field's values and methods), pedagogical (where students struggle and break through) and assessment (recognising real understanding).
• The fundamentals stay, but each one needs a discipline-specific defence. The lesson expects students to ask "why learn research methods when AI can search for me?" Its advice is to work with colleagues to map what AI can automate in the field and which concepts gain or lose importance. Directing AI agents effectively is one of the skills to teach.
• Some AI use enhances learning and some only shortcuts it. The lesson credits AI with making tutoring at scale, interactive simulations and immediate feedback possible. It asks each discipline to work out where AI helps or hinders learning, and which teaching approaches to adopt or actively discourage.
• Assessment is the biggest disruption AI creates for educators. "When students can generate essays in seconds, what are we actually assessing?" The lesson calls for authentic assessment of both AI-assisted and human-only work, assignments AI can't shortcut, and credit for process and growth. Since students will likely use AI regardless, it suggests possibly shifting to assessing critical thinking and skill working with AI. It concedes this is "easier said than done" and should be worked out with students, colleagues and institutions.

2026-11-06 · open the original ↗

• Design assignments around authenticity, iteration and pedagogical transparency. The lesson says assignments should be genuine problems where AI actually adds value, not artificial exercises. They should build in chances to refine and try again, because single-shot work misses how fluent collaboration actually goes. Students should also be told plainly that the collaboration process and their reflections are graded, not just the output.
• Outcome-based assignments grade products but expose collaboration skills. The lesson's formats: turn a mediocre AI output into an excellent one, and run the same task on several AI systems or modes (it names extended thinking and image-to-image) and compare the results. Constraint challenges set format, length, style and audience, and students submit the prompts along with the product; adding ethical, legal or professional constraints brings in creation diligence. In peer product review, students swap work and critique it against each other's stated goals.
• Process-based assignments make private, fleeting AI work visible. The lesson's options are annotated chat logs that mark turning points and recoveries, and narrated screen or audio recordings made while working. Students can also build their own playbook of strategies by task type, or debrief a chat log with an AI, a peer or both, then compare the insights.
• Reflection assignments need variety to avoid reflection fatigue. The options are guided questions that invite honest complaints as well as praise, learning journals that self-assess 4D progress with evidence in several formats, and case scenarios such as "your new boss wants you to use AI for hiring decisions." If there is room for only one, the lesson recommends a personal policy statement on the student's own values and methods.
• Plan for the extra volume these assignments generate. The lesson's fixes: granular deliverable-based rubrics that can be checked quickly, and self and peer review that condense long AI outputs. It also suggests lightning-round conferences, where five minutes of discussion can replace extensive written comments. Instead of reading every chat log in full, have students flag the key moments.

2026-11-06 · open the original ↗

• Combine outcome, process and reflection assessment for a full picture. The lesson's aim is to tell a student who has found some clever prompts from one building real collaborative skill. Outcome-based assessment judges what was produced. Process-based assessment examines iteration, recovery from failed attempts and methodological sophistication. Reflection-based assessment tests whether students can explain why their strategies worked or failed.
• Delegation and Description need evidence from plans and chat logs. For Delegation, the lesson asks whether the plan made sense, the goals were realistic and the tool fit the job. The evidence is annotated chat logs of the decision process plus students explaining the alternatives they weighed. For Description, it assesses prompt quality and how prompts evolved from first to final version. Logs, read against a rubric, should show refinement, documented failures, pivots and shared context built up over time.
• Discernment and Diligence need evidence of judgment and responsibility. For Discernment, the lesson suggests annotated AI outputs and decision logs recording what was kept, modified or discarded. It also looks for inline evaluation comments and caught errors in chat logs. For Diligence, it assesses diligence statements, attribution, fact-checking, data handling visible in the logs, and reflection on the ethical dilemmas students met.
• One essay assignment can be assessed from all three angles. In the lesson's example, students write an essay on Gen AI's impact on society and submit four things: the essay, a link to their AI interactions, a diligence statement and a learning journal. The essay and statement are read for human oversight and transparent disclosure. The interaction log is read for shared context and course correction. The journal is read for lessons learned.
• Assess observable artifacts, and make assessment a learning opportunity. The lesson's principles are to rely on concrete actions and artifacts rather than assumptions about understanding, and to match assessment methods to each competency. Above all, assessment should help students recognise their own growth as AI collaborators.

2026-11-06 · open the original ↗

• Teach building shared context, not prompt tricks. The lesson says students arrive thinking AI skill means clever hacks. It wants them to stop treating AI as an input-output command line and build a "cognitive environment" instead: shared vocabulary that evolves, defined goals and methods, set patterns of interaction, and ways to build on earlier exchanges. It argues no single prompt, however well engineered, gets there, and that this skill lasts longer than copied prompts.
• Product iteration clarifies the student's own goal as well. Product, Process and Performance are three lenses on one collaboration. In the lesson's example, "help me write about social media and teenagers" gives a generic response. Through Discernment it becomes a request to analyse how teens present different versions of themselves across platforms, written so readers grasp the psychological toll. The lesson calls this the move from automation to augmentation.
• Process descriptions grow from vague to explicit methods. In the lesson's hypothetical, "analyze this step-by-step" becomes a set routine: author's context first, then content and notable omissions, then several interpretations before any conclusion. Process discernment asks whether the method finds insights the student would miss alone. In the example, the student learns their AI is good at cross-document patterns but needs guidance on emotional and cultural context.
• Performance tunes the working relationship, and Discernment keeps revising it. The lesson's sample instructions include asking the AI to act as "a kind but rigorous skeptic," to use music analogies, or to keep some humour in creative tasks. The student later revises the first one: save the skepticism until after the initial ideas have formed.
• Assignments must span many interactions within and across chats. The lesson says single-prompt exercises can't build cognitive environments. Multi-chat work also teaches students which context carries over and which must be re-established. Teachers should show their own AI collaborations and have students record how the collaboration evolved, not just the outputs. The signs to look for are shorthand shared language and a shift from rigid "Do X then Do Y" commands to exploratory exchanges.

2026-11-06 · open the original ↗

• This loop asks whether, when and how to use AI at all. The lesson frames it as moving students from "how do I use AI?" to "how do I make good decisions about AI?" That includes choosing among human-only work, AI-human collaboration and AI automation. The loop is built from six sub-competencies: problem awareness, platform awareness and task delegation on the Delegation side, and creation, transparency and deployment diligence on the Diligence side.
• Delegation choices immediately raise Diligence questions. In the lesson's example, a student writing a policy brief on digital privacy compares AI systems and hands the AI the research synthesis but keeps the policy recommendations. That raises three questions: can stakeholder information be shared with the system, how will AI's role be acknowledged, and what fact-checking secures the data. The lesson gives students a set of questions for each step, from objectives and resources through to ethics, disclosure and verification.
• Diligence obligations also reshape Delegation, and the lesson says they improve it. A student on a community project who feels responsible for representing voices accurately lets AI analyse interview patterns but keeps the narrative interpretation for themselves. A student who documents AI contributions in detail can delegate more with confidence, because the boundaries are set. The lesson's claim is that "accountability enhances agency and creativity."
• Teach the loop through scenarios worked in both directions. The lesson suggests giving students a project brief and having them start from Delegation, then push into Diligence. Then flip it, starting from a constraint such as "your school requires all AI use to be clearly labeled," and compare what each direction revealed. The exercise has the teacher build such a scenario from their own discipline, with decision points and a plan for how students record their thinking.
• Clear rationales show students are getting the loop. The lesson's signs of success: students can say why their approach fits their goals and values, not just what they did. They treat ethical constraints as "creative catalysts" rather than limits, and they expand their AI use because they know what they are accountable for.

2026-11-06 · open the original ↗

• The framework both describes AI work and prescribes better practice. The lesson says it maps what people actually do with AI (the decisions, communication, evaluation and responsibility) and also shows what they should do. Students need both halves: how AI interactions work, and how to make them work better.
• The linear approach suits beginners. It runs the 4Ds in order: Delegation, Description, Discernment, Diligence. The lesson's example is a four-part assignment: project planning for Delegation, hands-on workshops for Description, evaluating outputs together for Discernment, then ethics discussions and transparency practices for Diligence. Each part builds on the one before.
• The non-linear approach treats the 4Ds as an interconnected system. It is meant for students with more AI experience. In the lesson's examples, problems found through Discernment send a student back to Delegation, for instance when evaluating code shows the chosen AI system doesn't suit their programming paradigm. Privacy duties under Diligence reshape Description, so prompts leave out sensitive data. Trouble describing a need exposes goals that were never defined at the Delegation stage. The lesson recommends this approach for case-based learning.
• The focused approach spends whole sessions on one competency. It suits workshops and seminars, and the lesson says it avoids the cognitive load of juggling all four Ds at once. One example is three Discernment sessions: product discernment (accuracy and usefulness of output), process discernment (the AI's problem-solving approach) and performance discernment (whether its communication style helps the collaboration).
• The two-loops approach is the most conceptually rich. Once students know the basics, the lesson splits the work into two loops. The Delegation-Diligence loop covers strategic and ethical decisions: what to do, how to divide the work, which systems fit your values. The Description-Discernment loop covers moment-to-moment tactical iteration. The lesson says each loop constantly reshapes the other, and that the choice among the four approaches should follow students' readiness, the time available and the learning goals.

2026-11-06 · open the original ↗

• An eval keeps running after launch, on edits and live traffic. The lesson argues two things keep changing: the team edits the prompt, which can break answers that were right, and real inputs drift away from the tested ones. Its example is Meridian, a fictional consultancy whose 50-case suite checks a prompt that extracts project ID, schedule status and top risk from monthly reports.
• Run a fast smoke eval on every pull request. Meridian runs 10 of its 50 cases, chosen to cover every report type, on Claude Haiku 4.5 in about a minute, against an 88% threshold (nine of ten must pass). The CI workflow runs the eval script, scores the JSON results, comments on the PR and fails the check below the threshold; Meridian uses GitHub Actions, but any CI that can run the script works.
• Make the check required, or a red X is only a warning. Merge blocking comes from a branch protection rule, not from the workflow file. In the demo, a PR titled "Simplify extraction prompt" dropped the return-null rule and the quote-the-source rule, scored 80% with two missing-risk cases (r041, r042) naming a risk that wasn't there, and stayed unmergeable until the fix brought it to 100%.
• Run the full suite through the Batch API at half price. Since nobody waits on it, the full suite (150 requests: 50 cases on each of Haiku 4.5, Sonnet 5 and Opus 5) goes as one batch; at August 2026 prices one pass cost $0.0468/$0.1301/$0.3432 standard versus $0.0234/$0.0650/$0.1716 batched. Each request needs a unique custom_id such as r041_claude-haiku-4-5 because results return in any order, and request_counts should be read before scoring, since batches expire after 24 hours and expired requests come back with no answer.
• Grade a nightly sample of live traffic to catch drift. The suite only knows the reports it was built from, so a new client format can degrade answers while CI stays green. The recommended starting points are sampling 1–5% of traffic, grading it with an LLM judge against a rubric (with occasional human spot-checks of the judge), alerting only when a night falls more than two standard deviations below the trailing baseline, and turning each failure into a new labeled case in the full suite.

2026-11-06 · open the original ↗

• Fix the prompt before paying for a bigger model. A low score doesn't say whether the model or the prompt is to blame, and an upgrade raises the price of every later request, while a prompt edit takes minutes to test. In Meridian's demo (August 2026), Sonnet 5 and Opus 5 scored 50 of 50, while Haiku 4.5 scored 84% against a 90% accuracy floor.
• Read the failures and group them by report type and field. Haiku's 8 failures were 3 typical reports on schedule_status and 5 of the 10 missing-risk reports on top_risk, each naming a risk where null was expected. In case r045 it called a routine permit renewal the top risk although the report said "the team does not anticipate any issues"; the cause was a prompt line ending in "or null" that never said when null applies.
• Choose from five standard hallucination fixes; Meridian used two. The five are letting the model say "I don't know", quoting before answering, citing back to the document, adding a verification pass, and restricting outside knowledge. Meridian stated when to return null and required a <source> quote ahead of the JSON, which means the code must now parse only the text after the closing </source> tag.
• The revised prompt made the cheapest model the best choice. Rerunning the same 50 cases on all three models, Haiku went from 90/100/50% to 100% on typical, multi-project and missing-risk reports. With every model clearing the floor, cost per completed task decided it: $0.0009 for Haiku, $0.0025 for Sonnet 5 and $0.0061 for Opus 5 at August 2026 standard prices.
• Check every column and rerun, because results vary between runs. The three schedule_status failures also passed, though no change touched that field, which the lesson attributes to run-to-run variation, so it advises running each setup two or more times and confirming no correct answer turned wrong. Its rule: keep iterating while the score moves, and upgrade only when it stalls below the floor, which signals a missing model capability.

2026-11-06 · open the original ↗

• An eval replaces opinions about models with a number. It has three parts: realistic inputs, an expected answer for each, and a way to grade what each model returns; the lesson likens it to an exam with an answer key, a scoring machine, and a teaching assistant grading essays from a guide.
• Use the quickest grader that's reliable and scales. Code-based exact matching goes first, an LLM judge handles answers where different sentences can both be right, and human grading, best quality but slow and costly, is kept for specialized, high-stakes or judgment calls. For Meridian, project_id (e.g. MER-2524) and schedule_status (on_track/at_risk/delayed) are code-graded, as is a null top_risk, while a stated top_risk sentence goes to the judge.
• The case set should look like production traffic. The rules are task-specific cases from real reports, automated grading, volume over polish, and edge cases stratified to their production share (if scanned reports are 5% of traffic, make them about 5% of cases); the lesson says 20–50 simple cases is a great start. Meridian used 50 (30 typical, 10 multi-project, 10 missing-risk), with expected answers written by hand before any model runs and kept in golden.json.
• Give the judge a rubric, a schema, and an "unknown" option. The judge's prompt holds the report, the answer and a detailed rubric in separate XML tags, but not the expected answer, so differently worded answers aren't penalized. Structured outputs force a verdict of correct, incorrect or unknown plus an explanation; "unknown" keeps the judge from guessing when unsure.
• Validate the judge before trusting it on free text. On the 30 missing-risk answers that code could also grade, the judge agreed with code 10/10 for each model, scoring Haiku 4.5 at 5 correct and 5 incorrect, and its explanation for case r045 pinned the error on a prompt that never says what to do when no risk is named. The lesson still advises hand-grading a sample, tightening the rubric where you disagree, and using a different model as judge from the one that wrote the answers.

2026-11-06 · open the original ↗

• Measure which model handles your task; don't guess. No published comparison has seen your prompt, so the lesson says to measure accuracy on your own cases first and only then look at cost. Its analogy is buying a ladder: measure the wall, discard ladders that don't reach, buy the cheapest that does.
• Set the accuracy floor from what one wrong answer costs. For Meridian, a wrong extraction means a 5-minute manual check and engineers can absorb 5 per month, so 5 of 50 reports gives a 90% floor. If one wrong answer cost $1,000, for example by reaching a client, the floor would be 100% and model price would barely matter.
• Score every model on the same cases with the same prompt. A task counts as completed only if all three fields are right, with ID and status matched exactly and the risk sentence compared loosely. On 50 reports, Sonnet 5 and Opus 5 scored 100% while Haiku 4.5 scored 84% (90% typical, 100% multi-project, 50% missing-risk), below the floor.
• Compare cost per completed task, taken from usage blocks. Read actual token counts from each response's usage block, because tokenizers differ: per the lesson, Sonnet 5 and Opus 5 produce about 30% more tokens for the same text than Haiku 4.5. At August 2026 rates (per million input/output: Haiku $1/$5, Sonnet 5 $2/$10, Opus 5 $5/$25), run costs were $0.0380, $0.0984 and $0.2323, or $0.0009, $0.0020 and $0.0046 per completed task, since failed calls are still billed.
• Pick the cheapest model that clears the floor. For Meridian that is Sonnet 5; Haiku's lower per-task figure doesn't count because it isn't a candidate. The lesson adds that the result is tied to this prompt and these cases, so the eval should be rerun when either changes; that latency isn't measured; and that evals can run on the Batch API at half price, as long as batch and standard rates aren't mixed in one comparison.

2026-11-06 · open the original ↗

• Start with the validator before debugging anything else. claude plugin validate ~/.claude/skills (personal) or claude plugin validate .claude/skills (project), which needs Claude Code v2.1.233 or later, flags SKILL.md files whose frontmatter doesn't parse. The lesson notes that the video demonstrates a separate verifier installed with uv.
• A skill that doesn't trigger almost always has a weak description. Claude matches requests to descriptions semantically, so the fix is to add the trigger phrases people actually use and to test variations such as "help me profile this", "why is this slow?" and "make this faster", adding keywords for any that miss.
• Loading failures are structural; check location, file name and debug output. SKILL.md must sit inside a named directory rather than at the skills root, and be named exactly SKILL.md; claude --debug shows loading errors mentioning the skill. For plugins, check /plugin (Installed and Errors tabs), run /reload-plugins after a mid-session install, and keep skills in a skills/ directory at the plugin root, not inside .claude-plugin/.
• Wrong or ignored skills usually mean overlapping descriptions or names. Descriptions that are too similar confuse selection and should be made more distinct. A same-named skill at a higher priority level wins every time (an enterprise "code-review" beats a personal one), so renaming is usually easier than going to the admin.
• Runtime failures come from dependencies, permissions or path separators. External packages must be installed and should be noted in the description, referenced scripts need chmod +x, and paths should use forward slashes everywhere, including on Windows.

2026-11-06 · open the original ↗

• Committing skills to the repo is the simplest way to share. Skills in .claude/skills reach anyone who clones the repo and update on the next pull, which the lesson recommends for team coding standards, project-specific workflows and skills that reference the codebase's structure.
• Plugins distribute skills beyond one repo via marketplaces. A plugin project holds a skills directory with one folder and SKILL.md per skill; once published to a marketplace, others can discover and install it. The lesson says this suits skills that aren't too project-specific and are useful beyond the immediate team.
• Managed settings deploy mandatory skills organization-wide at top priority. Administrators put skills in .claude/skills/ under the managed settings directory on each machine (e.g. /etc/claude-code/.claude/skills/ on Linux), where they override same-named personal and project skills. Managed settings also restrict plugin sources via strictKnownMarketplaces, with github and url entries shown; the lesson says this route is for what "must" be consistent, such as security and compliance.
• Subagents don't inherit skills you've already invoked. A subagent starts with a fresh context unless it's a fork, though it can still find and invoke skills if it has the Skill tool. Built-in agents like Explore and Plan don't preload skills; custom subagents in .claude/agents can list skills in a skills frontmatter field, which load in full at startup, and should keep Skill in any tools list. The lesson notes the /agents wizard shown in the video was removed in Claude Code v2.1.198, and that a newly created .claude/agents directory needs a restart.

2026-11-06 · open the original ↗

• CLAUDE.md is always loaded; skills load only when relevant. The lesson puts project-wide standards, constraints like "never modify the database schema", and framework or style preferences in CLAUDE.md, and task-specific procedures, such as a PR review checklist, in skills so they don't clutter every conversation.
• Subagents isolate delegated work; skills add knowledge to the current conversation. Subagents fit when you want a separate context, different tool access, or isolation from the main thread; skills fit when Claude's expertise should improve for the task at hand.
• Hooks are event-driven, skills are request-driven. Hooks suit operations on every file save, validation before specific tool calls, and automated side effects, while skills supply the knowledge and guidelines that shape how Claude reasons about a request.
• Combine the features instead of forcing everything into skills. A typical setup, per the lesson, pairs CLAUDE.md for always-on standards, skills for on-demand expertise, hooks for event-triggered operations, subagents for isolated delegation, and MCP servers for external tools and integrations, which it calls a different category from skills altogether.

2026-11-06 · open the original ↗

• Every frontmatter field is optional, but the description matters most. In Claude Code, name defaults to the directory name and description is the recommended field because Claude matches on it. Uploading to Claude.ai or the Claude API makes both required: name is limited to lowercase letters, numbers and hyphens up to 64 characters, and description to 1,024 characters. model picks the model for the skill.
• A good description says what the skill does and when to use it. The lesson's point is that "your job is to help with docs" would leave a person guessing, and Claude too; if a skill doesn't trigger, add keywords that match how requests are actually phrased.
• allowed-tools pre-approves tools without restricting Claude to them. Listed tools skip permission prompts for the rest of the turn that invoked the skill, and the grant clears with the next message; other tools such as edits still go through normal permissions. The lesson warns that a bare Bash pre-approves shell commands generally and suggests narrowing it to a pattern like Bash(git status *), and points to disallowed-tools for removing tools while a skill is active.
• Use progressive disclosure to keep SKILL.md small. One 2,000-line file wastes context and is hard to maintain, so essentials stay in SKILL.md, kept under about 500 lines, and links point to scripts/, references/ and assets/ with instructions on when to load each. The lesson likens this to keeping a table of contents in context rather than the whole document.
• Tell Claude to run scripts rather than read them. A script executes without its contents entering context, so only its output costs tokens. The lesson recommends this for environment validation, consistent data transformations, and operations more reliable as tested code than as generated code.

2026-11-06 · open the original ↗

• A skill is a named directory holding a SKILL.md file. The worked example is a personal pr-description skill in ~/.claude/skills/pr-description/. Its frontmatter name identifies the skill, its description ("Use when creating a PR, writing a PR, or…") is the matching criterion, and the body tells Claude to run git diff main...HEAD and write What / Why / Changes sections, so the format comes out the same every time.
• Only names and descriptions load until a request matches. Claude compares each request to the skill descriptions by intent, so "explain what this function does" matches a skill described as "explain code with visual diagrams", and then reads the whole SKILL.md. The video's narration says Claude asks for confirmation before loading. The current written lesson says a skill with only name, description and instructions loads without asking (that step was removed in Claude Code v2.1.19), and only skills that pre-approve tools or add hooks may prompt.
• Name conflicts resolve enterprise first, then personal, then project. An enterprise "code-review" beats a personal one of the same name, so the lesson advises descriptive names like "frontend-review". The video ranks plugins last; the written lesson says plugin skills are namespaced as /plugin-name:skill-name and load alongside a same-named skill instead.
• Edits and deletions take effect without a restart, with one exception. The video says to restart after changes, but the written lesson says Claude Code watches skills directories and picks up edits, new skills and deleted directories in the current session. The exception is a ~/.claude/skills directory created mid-session, which needs /reload-skills after each change.

2026-11-06 · open the original ↗

• Skills turn instructions you keep repeating into something written once. A skill is a folder whose SKILL.md carries a name and description in frontmatter and task instructions below, such as a PR review checklist. The lesson's rule of thumb: if you keep explaining the same thing to Claude, that's a skill waiting to be written.
• The description decides when a skill activates. Claude compares each request against all available skill descriptions and activates the ones that match; the terminal then shows a line such as "Successfully loaded skill" for pr-review.
• Where a skill lives decides who gets it. Personal skills in ~/.claude/skills (on Windows, C:/Users/<your-user>/.claude/skills) follow you across projects. Project skills in a repo's .claude/skills are version-controlled and reach anyone who clones it, which is where team standards such as brand guidelines belong.
• Skills load on demand and need no explicit invocation. CLAUDE.md loads into every conversation and slash commands must be typed, while skills load only their name and description up front and activate when Claude recognizes the situation, so they don't fill the context window. The lesson names code review standards, commit formats, brand guidelines, doc templates and framework debugging checklists as good fits.

2026-11-06 · open the original ↗

• Start small: one space, a few people, one agent. For the first two weeks the lesson recommends a high-trust team of three to five with a project to finish together, sharing one collaboration space and one multiplayer agent, configured most commonly through Claude Tag or the Claude Managed Agents API.
• Make the team's work public and written by default. Decisions made in meetings or DMs get posted the same day, because for an agent anything not written down and accessible doesn't exist. The team writes a roster with one owner per recurring job, agents included (the agent can propose it, people decide), and pins a measurable, ambitious north star where the agent can read it; people set the north star.
• Give the agent one visible, reviewed job first. The suggested starter is a morning briefing for the whole team, with a person reviewing it and giving feedback for the first few days. Every task should come with a rubric for what "passing" looks like, which the lesson says scales trust fastest.
• Widen autonomy per kind of task, after repeated success. Once the agent has handled a kind of task well several times in a row, it gets more latitude on that task only. Anything explained twice becomes written instructions (skills), and a weekly retro of humans and agents records what works, saved so other agents can reuse it.

2026-11-06 · open the original ↗

• Check five readiness conditions before bringing agents into a team. The lesson's questions are whether work is open and searchable rather than in private documents and DMs; whether ownership is written down, agents included; whether every teammate, agents too, has the tools for the job; whether an agent's key work can be checked by a rubric, test or second agent before a person sees it; and whether there's a written north star. It gives a consequence for each gap: agents fall out of date, work gets duplicated, agents without access guess or do thin work, finalizing takes longer, and nobody can be proactive about what comes next.

2026-11-06 · open the original ↗

• Agents raise the cost of misalignment, so team basics matter more. The lesson argues that human-agent teams complete tasks faster, which makes errors and misalignment costlier, so clear roles, a written north star, information access and trust become more important than on teams without agents.
• Work in public and give every teammate a defined role. For an agent, unwritten or inaccessible information doesn't exist. The lesson calls for one roster, one set of artifacts and one working space, with the right tools for each human and agent and human judgment kept on the most important decisions.
• A human-set north star makes agents proactive; autonomy follows reliability. An agent that knows the goal can bring useful work toward it unprompted, and autonomy is granted in proportion to demonstrated reliability, then expanded deliberately. The exercise prompt has Claude draft a roster for a real project, keep judgment calls with named people, and propose a one-sentence north star for the team to correct.

2026-11-06 · open the original ↗

• A multiplayer agent acts as itself, not as an extension of you. A single-player agent carries your credentials and knows what you know, while a multiplayer agent has its own identity, so the team decides its access and tools. Per the lesson, its other two defining capabilities are shared memory that grows from everyone who works with it and shared team context that keeps it current.
• Three questions tell whether an AI tool is a tool or a teammate. The exercise prompt asks whether it acts under its own name and sign-in or yours, whether it remembers goals between conversations, and whether it reads the team's shared spaces or only what you paste in. Claude then identifies what the team is likely re-explaining or losing, and the smallest change toward "teammate".

2026-11-06 · open the original ↗

• Single-player AI speeds individuals but silos the team's information. The lesson's image is a "super suit" that makes one person faster on their own tasks. It uses the fictional Lantern team, about to launch a health tracker app, to argue that siloed context hurts agent performance more as a team grows, with repeated questions answered differently.
• A shared space turns AI requests into team knowledge. When a meeting summary or calendar update is requested in a space every human and agent can see, it becomes knowledge the team builds on, which the lesson says lets agents be more proactive and personalized toward a common goal. The exercise has a team list three weekly recurring questions and ask Claude what goes wrong when answers differ and what one shared agent answering in public would change.

2026-11-06 · open the original ↗

• Being the human in the loop means you make every decision. The lesson defines it as deciding what to ask, judging whether the output makes sense and is good enough to use, and bringing your own judgment, creativity and ethics rather than passively accepting what comes back.
• Write a personal AI commitment that's honest, not aspirational. It should cover when you will and won't use AI (your "red lines"), how you'll use it for learning, when and how you'll disclose AI help, and how you'll keep your skills sharp. The exercise also asks how you'd want classmates, professors and employees to use AI, and the lesson suggests sharing the commitment with friends or mentors so others can hold you to it.
• Keep reflecting on whether your AI use helps you grow. The questions it poses are whether you're developing the skills you'll need or just completing tasks, whether you're honest about AI's role in your work, and whether your use fits your values. Its claim is that the 4D habits (delegation, description, discernment, diligence) will carry over to AI applications that don't exist yet.
• Human insight, judgment and care stay irreplaceable. The lesson argues AI can help you learn faster and express your talents and experience more clearly, but not substitute for them, and that fluent users will help steer how AI is used in their fields instead of just going along with it.

2026-11-06 · open the original ↗

• Treat AI as a career thinking partner, not a content generator. The lesson says generic AI-written resumes and cover letters are easily spotted and don't impress employers, and that career decisions like "what do you want to do with your life?" shouldn't be handed over to AI; sometimes the right call is not to use it at all.
• AI supplies the market information; you supply self-knowledge and values. AI is good at researching emerging roles, skills employers want, salary progressions in specific cities, and paths others took (e.g. teaching to corporate training). Only you know what energizes you and which trade-offs you'll accept, such as salary versus flexibility. The lesson suggests having AI ask you questions to surface goals you haven't stated, then narrowing to 2–3 roles and noting the skill gaps.
• Close skill gaps with specific goals and AI as an active coach. "Help me learn data analysis" is too vague. The lesson's alternative describes the actual need, analyzing survey data for a marketing take-home, and asks for a plan with practice. Then use AI for industry practice scenarios, feedback, and role-played interviews, and check regularly whether you're learning or just going through the motions.
• In the job search, AI coaches but you present yourself. AI can brainstorm, find transferable skills, run interview practice and produce drafts to borrow from, but you're responsible for how you're represented and must test its suggestions against your real professional identity.
• AI fluency is itself a career skill to show off. The lesson advises keeping track of your AI use, disclosing it when relevant, and listing AI fluency on your resume, because employers want people who can work with AI effectively.

2026-11-06 · open the original ↗

• Letting AI think for you leaves you stranded when it counts. The lesson argues that leaning on AI skips building critical-thinking skills, which shows up in a no-AI exam, a job interview where you have to explain your reasoning, or at work when you can't tell whether AI advice is "genius or garbage".
• Delegate with your learning goal in mind. Before opening an assistant, ask what the work is meant to teach you. If the goal is better argumentative writing, AI shouldn't write the arguments but can act as a debate partner throwing counterarguments; the lesson also suggests choosing platforms built for learning.
• Describe the help you want: coach, not substitute player. Assistants default to direct answers, so ask for a tutor who only asks questions, hints without solving a logarithm problem, questions that deepen your own poem analysis, practice problems, or AI playing your student so you teach it. The exercise builds a reusable "study buddy" configuration with protocols per need (problem-solving, exam prep, writing, planning) and tests whether it slips back into giving answers.
• Discern honestly whether you're learning or along for the ride. The gut check is whether you can explain it to someone else, solve a similar problem without AI, and say why it works. Frustration counts as a sign of learning, and important facts from AI should be verified against non-AI sources.
• Diligence means following policy, disclosing, and owning every submission. The lesson's three parts are using the AI tools your school allows and following its rules, documenting AI use even when not required, and being able to explain, defend and apply everything you hand in. If you can't say why you took an approach because AI chose it, you haven't learned it.

2026-11-06 · open the original ↗

• AI fluency means augmenting your work, not automating it. The lesson defines fluency as using AI effectively, efficiently, ethically and safely as a responsible human in the loop, and argues augmentation matters most in learning, where the aim is for AI to help you do your work better rather than do it for you.
• Delegation rests on problem, platform and task awareness. You first get clear on the goal (what successful studying for this test looks like), then pick a system suited to it, since some are built for reasoning and some for student learning. Finally, divide the work: humans bring creativity, judgment and real-world context; AI brings speed, consistency and the ability to process large volumes of information.
• Description covers the product, the process and the AI's behavior. Product description spells out length, key messages, audience and style; process description says how to approach the task, such as step by step or from several perspectives; performance description sets the role, such as critical editor or supportive brainstormer.
• Discernment evaluates the same three levels, and loops with description. You judge whether the output is accurate and useful, whether the reasoning and assumptions hold, and whether the AI kept the role you asked for, including noticing when it surfaces something new. Describe, discern and refine form the feedback loop the lesson says turns AI from a tool into a thinking partner.
• Diligence is about choosing tools carefully, disclosing, and owning the result. Creation diligence weighs privacy, security and fit when choosing a system; transparency diligence tells professors, teammates and employers how AI helped; deployment diligence means verifying and taking responsibility for the output ("AI might draft the email, but you send it"). The lesson expects the 4Ds to stay relevant as the technology changes.

2026-11-06 · open the original ↗

• AI fluency is a set of lasting skills, not tool tips. The hosts (Zoe, Maggie Vo and Alex Albert) say most AI guidance is use cases and tricks that go stale with new models, while the skills they've seen endure concern how to use AI effectively, efficiently, ethically and safely. That means when to hand work to AI, when not to use it at all, how to choose an assistant and check its accuracy, and whether and how to tell teachers or employers.
• The course applies the 4Ds to learning and careers. It starts with delegation, description, discernment and diligence, applies them to learning concepts more deeply and to career planning and job search, and ends on being the human in the loop. The stated aim is to make AI a partner that helps you do your work better rather than a tool that does it for you.

2026-11-06 · open the original ↗

• The workbook is the participants' copy of the 4D workshop. Unlike the deck and facilitator guide, which are for the trainer, it is for the educators being trained: a warm-up reflection, the core 4D activities, a delegation matrix and a closing commitment. It downloads as a fillable HTML file or a printable PDF, and responses stay on each learner's device. The kit is © 2026 Anthropic and the American Federation of Teachers, based on the AI Fluency Framework by Rick Dakan (Ringling College) and Joseph Feller (University College Cork), under CC BY-NC-SA 4.0.

2026-11-06 · open the original ↗

• The captured text contains no deck or guide content. The archived page is just a "Loading" placeholder for an interactive viewer, so none of the deck or facilitator guide is available to summarize. The companion "How to use the kit" lesson describes this page as the workshop deck with toggleable speaker notes holding the facilitator guide, downloadable as PDF or HTML.

2026-11-06 · open the original ↗

• The kit has three parts: deck, facilitator guide and learner workbook. The deck is the whole workshop slide by slide; the facilitator guide holds key points and activity setup for each slide and appears as toggleable speaker notes under the slide; the workbook goes to participating teachers so they can practice the 4Ds and keep their responses.
• The deck runs in the browser and downloads for offline use. Navigation is by Back/Next, arrow keys or a "Jump to section" menu, the "Meet your facilitator" slide can be personalized and is saved in the browser, and the Download menu exports the deck and guide as PDF or HTML for offline presenting or printed handouts.

2026-11-06 · open the original ↗

• Educators need a voice in today's AI decisions about classrooms. The lesson argues that decisions made now will shape classrooms for years, that teachers are closest to the impact, and that no algorithm can replicate the relational work at the heart of teaching. That is its stated reason for training educators to lead their colleagues.
• The kit assumes trainers have already built their own fluency. It builds on the AI Fluency for pK-12 Educators course's 4D Framework, guardrails and judgment, adding a ready-to-run deck, a facilitator guide with slide-by-slide talking points and timing, and grade-band exercises so trainers can lead colleagues through it in their own voice. Anyone who hasn't taken the main course is told to start there.

2026-11-06 · open the original ↗

• Accumulated context makes each new material fit the sequence. With past conversations, uploaded files and connected tools, the AI already knows your objectives, the learning journey you've mapped and your constraints, so you never start from scratch. The running example is journalism students stuck on null and alternative hypotheses: the AI knows this is a week-four objective, that these students struggle with abstraction, and that social media analytics has served as the bridge concept.
• Delegate the confusion point to the teacher, the variety to the AI. Problem awareness says why students are confused and what has to change, while AI is good at generating varied practice scenarios that fit the course's progression; the two refine together. The lesson's exercises apply the same approach to slide decks, study guides, in-class activities and 5–10-question quizzes, each ending in a check for accuracy, alignment and bias.
• Describe by referring back to shared context, then add specifics. The example prompt recalls that "my journalism students need concrete examples before abstractions" and builds on last week's social media examples. It then specifies product details (numbered worksheet, answer key on a separate page), process (target misconceptions about identifying variables first, build complexity gradually) and performance (creative scenarios at a 10th-grade reading level, flag anything too complex).
• Explain why suggestions work or fail, to keep the loop improving. Don't just accept a good scenario or reject an overly complex one; saying why grows the context and improves later suggestions. Discernment should also catch possibilities, such as an approach borrowed from another field that clarifies the concept.
• Diligence, and the integrity problem AI creates, belong to the educator. That means protecting sensitive data, checking citations, sharing diligence statements with students, and reviewing for accuracy, bias and alignment, since the educator owns the impact. The lesson acknowledges AI can pass many assignments at a passing grade or better, says there are no simple solutions across contexts from kindergarten to graduate school, and argues the payoff is coherent quality more than speed.

2026-11-06 · open the original ↗

• Rich shared context turns AI into a colleague who knows your teaching. Presenter Joe Feller argues AI's most transformative capability for educators is holding a large context while helping with interconnected decisions, applied here to course design's three tasks: choosing essential content, mapping the learning journey, and writing learning objectives.
• Decide what you need and why before choosing how to collaborate. Filling out details under topics you already have calls for different help than organizing concepts you know must be included. The description should then bring the AI into the real problem: not "introductory statistics topics" but a stats course for journalism students who are anxious about math or doubt its relevance, with a request for concepts that address those concerns and build confidence.
• Ask the AI to play a student to test the course flow. Once a sequence is drafted, the AI can say where a student would get confused, what background each stage needs, and what support transitions require. The lesson calls this an always-available student focus group that teachers often forget to use; the exercise sequences 3–4 sessions this way.
• Earlier context-building lets you iterate on learning objectives quickly. That context, or a syllabus plus a description of your teaching approach, supports objectives that are measurable, motivating, true to your philosophy and aligned with institutional requirements. Faster drafting allows more experiments, such as mapping course outcomes to resume skills to motivate students.
• Keep responsibility and document the collaboration openly. The lesson says you aren't outsourcing decisions, so record key choices and rejected suggestions and share the process with students and peers to model responsible use. It argues the real gain beyond saving time is surfacing hidden assumptions and unexpected connections, producing courses better than teacher or AI would design alone.

2026-11-06 · open the original ↗

• Fluency means augmenting your own work, not automating it away. The lesson defines AI fluency as using AI effectively, efficiently, ethically and safely as a responsible human in the loop, in contrast to asking AI to do the work without thinking about what's asked or its impact, and says this matters most in learning.
• Delegation draws on three awarenesses: problem, platform and task. Clarity about the goal, kept as a "North Star" though it can be revised, comes first. Next is choosing a system whose capabilities fit, since some excel at reasoning and some are built for learning. Last is splitting the work so humans contribute creativity, judgment and real-world context and AI contributes speed, consistency and volume.
• Description specifies the product, the process and the AI's role. Product means length, key messages, audience and style; process means how to approach the task, such as step by step or from several perspectives; performance means how the AI should behave, such as challenging critic or supportive brainstormer. The lesson frames this as conversation with a collaborator, not memorized prompts.
• Discernment judges the same three levels and feeds a refinement loop. It asks whether the output is accurate and useful, whether the reasoning and assumptions hold, and whether the AI kept its role and pushed back when it should, and it also notices useful surprises. Describing, discerning and refining in turn is where the lesson says fluency develops, turning AI into a thinking partner.
• Diligence covers choosing tools carefully, disclosing, and owning the result. Creation diligence weighs privacy, security and fit; transparency diligence tells the people affected how AI helped; deployment diligence verifies accuracy and appropriateness and owns the outcome. The lesson expects the 4Ds to hold as AI capabilities change.

2026-11-06 · open the original ↗

• The open question is how AI enters education, not whether. The presenters (Zoe, Rick Dakan, Maggie Vo, Joe Feller) say students already use AI, employers increasingly expect graduates to be fluent with it, and institutions worldwide are working out responsible integration, so educators have a chance to model thoughtful, critical engagement.
• The course applies the 4Ds to course design, materials and assessment. It treats AI as a thinking partner for designing courses, creating learning materials, and building assignments and assessments that keep the teacher's vision and academic integrity, with the goal of challenging assumptions and personalizing learning while keeping human expertise and pedagogical values at the center. It assumes the AI Fluency: Framework & Foundations course, and companion courses exist for teaching fluency to students and for students themselves.
• Start by building a reusable document describing your teaching context. The exercise has the educator reflect on values, constraints and students, then talk it through with an AI that interviews them or asks what else it needs, and synthesize the result into a structured document to paste into later conversations. The lesson's premise is that AI helps more when it understands your situation, values and constraints.

2026-11-06 · open the original ↗

• Delegate only when the intermediate work doesn't matter. The lesson's single decision rule: if you need just the result, hand it to a subagent; if you need to see and react to each step, keep it in the main thread. Research is the classic case — a subagent can read dozens of files tracing authentication and return only a line like "JWT validation happens in middleware/auth.js line 42".
• A separate reviewer context gives better code reviews. The lesson says Claude reviews code more effectively when it is presented as someone else's, so the thread that built a feature over many turns gives weak feedback on it. A reviewer subagent runs git diff and reads the changed files without that history, and its system prompt can encode project-specific review standards for consistency across a team.
• Custom system prompts justify subagents for non-coding work. Claude Code's default prompt favours concise, code-focused output, which the lesson says is wrong for a landing page or email campaign. Its examples are a copywriting subagent with tone, audience and style instructions, and a styling subagent told to read design-system files before writing CSS.
• "Expert" persona subagents add nothing. Prompts like "you are a Python expert" or "Kubernetes specialist" give no capability the main thread lacks, since Claude already has that knowledge, so the overhead of a subagent buys nothing.
• Pipelines and test runners lose information you need. A reproduce-debug-fix chain of three agents fails because each step depends on the last's discoveries, which get lost in handoffs. A test runner that returns only "tests failed" hides the output needed to diagnose; the lesson reports that in testing this pattern performed worst of all configurations.

2026-11-06 · open the original ↗

• The description decides both when a subagent runs and what it's told. Every subagent's name and description go into the main agent's system prompt, steering which one it launches, and the main agent also uses the description as guidance when writing the subagent's input prompt. Adding "You must tell the agent precisely which files you want it to review" to a code reviewer's description turned a vague "use git diff" prompt into one listing the files; "return sources that can be cited" works the same way for a web-search subagent.
• Defining an output format is the single biggest improvement. The lesson argues it gives the subagent natural stopping points — it is done once every section is filled — whereas without one subagents struggle to judge when enough research is done and run much longer. Its code-review template has Summary, Critical, Major and Minor Issues, Recommendations, and Approval Status sections.
• Ask explicitly for obstacles, or the main thread rediscovers them. Workarounds, environment quirks, commands needing special flags, and problem dependencies or imports should come back in the summary to avoid wasted time and tokens. An "Obstacles Encountered" section in the output template is the lesson's way to surface them reliably.
• Grant each subagent only the tools its job needs. This prevents unintended side effects and clarifies roles when there are several subagents. The lesson's mapping: research gets only Glob, Grep and Read; a reviewer adds Bash for git diff but no Edit or Write; only code-modifying agents such as a styling agent get Edit and Write.

2026-11-06 · open the original ↗

• A custom subagent is a markdown file with YAML frontmatter. The frontmatter tells Claude when to use it and the body directs the subagent itself. Placement sets scope: .claude/agents/ is project-level, ~/.claude/agents/ is user-level and shared across all projects on the machine.
• Create subagents by asking Claude to write the file. The written lesson says the /agents wizard shown in the video was removed in Claude Code v2.1.198, so scope, tools, model and colour now go into the request; the video's narration still presents /agents as the easiest route. Either way the recommended path is letting Claude generate the name, description and system prompt from a description of the job.
• Fields set tools, model and identity. tools lists accessible tools — a reviewer can drop edit tools but keep execution tools to find pending changes. model takes an alias (sonnet, opus, haiku, fable), a full model ID, or inherit, with Haiku for fast tasks, Opus for complex analysis and Sonnet between; name is referenced as @agent-name and color marks the subagent in the UI.
• The body below the frontmatter is the system prompt. It sets what the subagent focuses on, how it analyses, and how it reports back; the lesson says its specificity is the difference between a useful subagent and one that misses the point.
• The description controls delegation, so tune it when triggering fails. It must be a single line (escaped \n for breaks); including "proactively" makes Claude delegate without being asked, and concrete example conversations improve its judgment. Test by making code changes and asking for a review, restarting Claude Code first if the agents folder didn't exist at session start.

2026-11-06 · open the original ↗

• Subagents protect the finite main context window. Each runs in its own context, starting from its configured system prompt plus a task description written by the parent agent, and only a summary returns; the rest is saved to a separate transcript file. The stated tradeoff is that the main conversation can't see how the subagent reached its conclusions.
• Delegated digging leaves only question and answer behind. In the lesson's example, finding which service handles refunds might take 15 file reads and several searches; via the Explore subagent the main context records only the question and the answer.
• Built-in subagents cover general work, exploring and planning. Claude Code ships three: General purpose handles multi-step tasks needing exploration and action, Explore does fast codebase search and navigation, and Plan does research during plan mode. Custom subagents add your own system prompts and tool access, such as a code reviewer or test writer.
• Less context noise means longer, more effective sessions. The lesson frames the benefits as focused pieces of work, a clean main context, and concise summaries of only what is needed.

2026-11-06 · open the original ↗

• A Democratic label alone carried candidates in this midterm. Aaron Parnas argues left and centrist Democrats won alike while independents such as Dan Osborne lost, and says Democrats should invest in the South, citing Louisiana at 1.8 points (closer than Florida) and predicting Scott Colom will flip Mississippi's Senate seat, though the race was not yet called. Jessica Tarlov counters that the brand won as the opposition rather than on its own merits, and says moderates outperformed progressives on margin.
• Aaron expects hostilities with Iran to resume. He cites reporting that Iran is handing out iodine tablets near nuclear sites and a third US aircraft carrier arriving or due in the region; Trump says he will soon choose between all-out war, economic pressure or a deal. Chris Van Hollen's call to shut down the government over the war is called reasonable, but Aaron relays Adam Smith's warning that a shutdown stops service members' pay, while Jessica says voters most loudly demanded an end to the war.
• Trump owns the market slide, not voters. The Nasdaq fell more than 5% Thursday on fears Democrats would crack down on AI and data centers, then rebounded slightly Friday; Trump took credit for Wednesday's rally and blamed voters for the drop, and October added 165,000 jobs. Of 44 ballot initiatives on data-center moratoriums all but North Dakota's passed, and Aaron backs a pause until regulation roots out bad actors, citing a report that Interior Secretary Doug Burgum is setting aside federal land for data centers while profiting personally.
• Republican 2028 hopefuls are starting to distance themselves from Trump. Mike Pence's Wall Street Journal op-ed attacks Trump's spending, tariffs and Iran war handling and calls for an end to right-wing economic populism, which Jessica says the election showed animates every voter. Aaron calls the GOP field effectively a two-person race and bets on Marco Rubio.
• Democrats should pair maximal investigations with a forward-looking legislative agenda. Aaron wants Congress to subpoena Trump and Musk associates and hand the record to a future Democratic attorney general, while passing a $15 minimum wage, universal child care, expanded health coverage and a congressional stock-trading ban, possibly ending the filibuster to do it, so Trump is forced to veto or sign. Jessica adds restoring the Medicaid cuts and ACA subsidies as day-one items, and says the 2028 Senate map gives Republicans no pickup opportunities.

2026-11-06 · open the original ↗

• Young men drove the midterm rout as a protest, not loyalty. Citing exit polls, he says young men swung 36 points toward Democrats in two years, more than any cohort, in what he calls the biggest electoral rout since 1974. His argument is that the same grievance that sent them to Trump in 2024 sent them away from Republicans this week, and his warning to winners of both parties is that more such swings follow if change doesn't come. The rest of the post reprints his July 21, 2023 essay; he says some of its numbers have changed but the trend hasn't.
• America's young men are failing, and society is failing them. Per the 2023 essay, boys start school less prepared than girls and are less likely to finish high school or college; one in seven men reports having no friends; and men account for three of every four deaths of despair (suicides and overdoses). By age 27, high school dropouts are four times as likely to be arrested, fired, on government aid or addicted, and he argues that the silence on these issues left a gap filled by misogynist voices.
• The postwar middle class came from deliberate public investment. He describes 1945 fears of a new Depression as 10 million mostly male veterans came home, which instead gave way to 30 years of growth. He credits that to state support: the G.I. Bill funding college for 2 million soldiers, Truman's housing legislation, Eisenhower's highway program (over $500 billion in today's dollars) and a 91% top income tax rate. Gains reached beyond white men: 27 million women joined the workforce in 1950–1980, and Black men's middle-class share rose from 22% in 1940 to 68% in 1970.
• Boys need a later school start, male role models and non-college paths. He backs Richard Reeves's (American Institute of Boys and Men) proposal to "redshirt" boys a year, and wants more male teachers, who are fewer than 1 in 4 today against 1 in 3 in 1980. He also calls for mentoring (he cites mentored kids as twice as likely to hold school leadership roles), for fraternity-style groups, and for vocational training on the German model and Biden's $150 million Apprenticeship Building Program. He would also use taxpayer leverage to make colleges add freshman seats.
• Policy shifts money from young to old, undermining families and demography. He cites financial conflict as the strongest predictor of divorce, and 35-year-olds as having half the wealth they did in 1989 while 75-year-olds have twice as much. He blames NIMBY housing rules, child tax credit rollbacks, preferential capital gains rates, and student debt that can't be discharged in bankruptcy, and he backs extending the child tax credit. The US spends 7% of GDP on seniors against 0.5% on children, and he calls Western population decline the biggest threat to democracy.

2026-11-06 · open the original ↗

• This post includes paid content that is not available publicly. See the original source.

2026-11-06 · open the original ↗

• Salesforce is repositioning itself as infrastructure, not interface. Carlson, SVP and head of product for AgentExchange, says "headless Salesforce", announced earlier this year, opens its APIs and MCP servers so customers and partners can build personalised interfaces on 25 years of data, workflow and permissions models. He calls the standard UI the "lowest common denominator". He cites a partnership with Anthropic for building on Salesforce with Claude Code and Claude Cowork, now open to anyone. The host says the episode was made in partnership with Salesforce.
• Software will serve AI-assisted humans and autonomous enterprise agents on shared foundations. Carlson sees two patterns: people building and sharing short-lived artifacts in an agent harness, and companies running enterprise agents that do a workforce's work. The example is the host's, from a Dreamforce demo: SaaStr went from dozens of employees to three executives plus Agentforce 360 agents. Carlson confirms SaaStr's team has presented this on Salesforce's earnings call.
• The marketplace must serve agent buyers, so search becomes reasoning. AppExchange, launched in 2005, has been merged with Slack's marketplace into AgentExchange. It now lists agents, skills, plugins and third-party MCP servers, and has moved from keyword search to semantic search. Carlson's goal is a "capability reasoning engine" for queries like the best CPQ tool for a manufacturer. He also wants it to serve a procurement agent that sets evaluation criteria, issues an RFP, stack-ranks the responses and recommends a purchase, which the old platform could not support.
• LLMs are compute, harnesses the OS, plugins the new apps. Carlson argues value is shifting to the harness and plugin layers because they allow model routing. In his view the output depends on the context and evals, not the raw model. Developers are moving from building UI to building plugins: skill instructions, domain context, evals and MCP connectivity. His advice to builders is to pick one painful problem in one domain, design it as a harness plugin from the start, and use AgentExchange for distribution.
• Models get most of the way; instructions and evals must finish. Carlson says people are so impressed that models reach 80% that they forget the last 20%. He admits Salesforce has "scars" from early skills that behaved unpredictably. Its fix is domain "taste", skills that tell the harness which tools to use, and testing on each surface: Claude, OpenAI's Codex and Cursor. Its "headless experience layer" turns UI primitives into each harness's native format, to stop generated HTML artifacts drifting from good layouts. He likens the moment to 2007, just after the iPhone and App Store launched.

2026-11-06 · open the original ↗

• This post includes paid content that is not available publicly. See the original source.

2026-11-06 · open the original ↗

• Workflows trade flexibility for accuracy and testability. A workflow is a predefined series of Claude calls for a known problem; because each call handles one small subtask, the lesson says accuracy is generally higher and every step can be evaluated, but the user must supply the exact inputs the flow expects.
• Agents trade reliability for flexibility. Given basic tools, Claude plans its own path, combines tools in unexpected ways and can ask the user for missing input; the cost is a lower task-completion rate and steps that are hard to instrument, test and evaluate because they are not known in advance.
• Default to workflows; use agents only when truly required. The lesson's recommendation is that users want a product that works 100% of the time, not a fancy agent, so agents are reserved for problems whose solution path cannot be predetermined.

2026-11-06 · open the original ↗

• Claude acts blindly unless it can observe its results. A click or keystroke changes the interface without Claude knowing how, which is why computer-use tools return a screenshot after every action so it can judge success and plan the next step.
• Read a file before modifying it. The example has Claude read the 31 lines of main.py before adding an "/items" route, so the edit fits the existing code; the lesson calls this a step many agent builders overlook.
• System prompts can tell an agent how to verify its output. For a video-posting agent, suggested instructions are to run whisper.cpp for timestamped captions to check dialog placement, use FFmpeg to extract frames to check visual quality, and check file sizes and formats before uploading.
• Every agent action should be followed by some verification. The lesson's rule is that inspection after each step lets the agent catch errors early and self-correct when results are unexpected.

2026-11-06 · open the original ↗

• Agents get a goal and tools, not a fixed sequence. That lets one agent handle many tasks once it works reasonably well, though the lesson flags significant drawbacks in reliability and cost to be covered later.
• Simple tools combine to cover diverse requests. With get_current_datetime, add_duration_to_datetime and set_reminder, Claude answers "What's the time?" with one call, chains two for "what day is it in 11 days", uses all three for a gym reminder next Wednesday, and asks the purchase date before computing when a 90-day warranty expires.
• Give agents reasonably abstract tools, not hyper-specialized ones. Claude Code has generic tools (bash, glob, grep, read, write, edit, webfetch) and no "Refactor", "Run Tests" or "Install Dependencies"; it installs dependencies by reading project config and then running commands through bash.
• The right tool abstraction lets agents work autonomously or collaboratively. A video agent with bash (for FFmpeg), generate_image, text_to_speech and post_media can either make and post a Python video end to end, or first generate a sample image for the user to approve before continuing.

2026-11-06 · open the original ↗

• One generic prompt yields mediocre output across different request types. A video-script tool should write an educational, definition-led script for "programming" but a high-energy, hook-driven one for "surfing"; the same prompt for both suits neither.
• Routing uses two Claude calls: categorize, then process. The first call classifies the input into a defined category (examples: entertainment, educational, comedy, personal vlog, reviews, storytelling), so "Python functions" comes back "Educational"; the second call uses that category's specialized prompt.
• Each input goes to exactly one specialized pipeline. Pipelines can carry their own prompts, tools, APIs or processing steps, new categories can be added without touching existing ones, and only the needed processing runs.
• Routing fits distinctly different request types with clear categories. The lesson puts the useful range at 3–10 meaningful categories, and argues the upfront cost of building several pipelines pays off in significantly better results when quality matters more than simplicity.

2026-11-06 · open the original ↗

• Chaining splits one large task into sequential, focused subtasks. The example video-marketing pipeline finds trending Twitter topics, has Claude pick one, research it and write a script, then makes an avatar video and posts it, with optional non-LLM processing between steps.
• Adding more "DO NOT" constraints doesn't stop violations. The lesson's scenario is an article prompt that accumulates rules against emojis, mentioning being an AI and a cringey tone, yet Claude still sometimes breaks them.
• Accept an imperfect draft, then fix it in a focused revision call. The second prompt lists specific steps — remove self-identification as an AI, remove all emojis, replace cringey writing with technical-writer prose — which works because Claude handles one aspect at a time.
• Chaining suits complex, many-constraint tasks Claude follows inconsistently. It also fits when outputs need processing or validation between steps; the lesson claims it is often more reliable than one complex prompt.

2026-11-06 · open the original ↗

• One giant prompt juggling many analyses confuses Claude. In a material-designer app choosing among metal, polymer, ceramic, composite, elastomer or wood, adding detailed criteria for every material to one request leaves the model distracted weighing all pros and cons at once.
• Run specialized sub-tasks in parallel, then aggregate. The same part image goes out in separate requests, each with criteria for one material; a final aggregator call compares those analyses and recommends a material rather than evaluating from scratch.
• Parallel sub-tasks need not be identical. Each can have its own prompt, tools or approach, and each can be tested and optimized independently; adding a material doesn't complicate the others, and parallel execution is often faster than sequential.
• Use it for tasks that decompose into independent sub-problems. The lesson points to cases weighing multiple options or several kinds of analysis where each benefits from specialized prompting.

2026-11-06 · open the original ↗

• How well you understand the task decides workflow versus agent. Use a workflow when you can picture the exact steps or the UX constrains users to set tasks; use an agent when you don't know what task or parameters Claude will get.
• Image-to-CAD is a textbook workflow. The app has Claude describe an uploaded image of a metal part, model it with the CadQuery library, render the model, then grade the render against the image and loop to fix issues, producing a STEP file.
• The evaluator-optimizer pattern loops a producer and a grader. The producer creates output, the grader checks it against criteria and sends feedback on rejection, and the cycle repeats until the grader accepts.
• Named workflow patterns are reusable recipes, not implementations. The lesson says they save time and avoid pitfalls others have hit, but you still write the code yourself.

2026-11-06 · open the original ↗

• MCP primitives differ by who controls them. Tools are model-controlled, resources app-controlled and prompts user-controlled; the summary line is that tools serve the model, resources serve your app and prompts serve your users.
• Use tools to extend what Claude can do. Claude decides when to call them, as when it picks a JavaScript execution tool to compute the square root of 3 accurately.
• Use resources to get data into your app. Examples are autocomplete options, context added to messages before sending, and document lists; in claude.ai, "Add from Google Drive" fetching your documents is resource behavior.
• Use prompts for workflows users trigger on demand. Triggered by buttons, menus or slash commands, they suit conversation starters, task templates and specialized workflows, like the starter buttons below the claude.ai chat input.

2026-11-06 · open the original ↗

• The client lists prompts and fetches them with arguments interpolated. list_prompts returns the session's prompts; get_prompt passes a name and an args dict (such as doc_id for the "format" prompt) and returns messages ready to send to Claude.
• Prompt function parameters become interpolation variables. The server substitutes the supplied argument values into the prompt text, so the client never builds the prompt itself.
• In the CLI, prompts appear as slash commands. Choosing "format" asks for its arguments (a document), then the client retrieves the filled prompt, sends it to Claude, Claude runs any tool calls, and the result comes back.
• Prompts separate prompt logic on the server from execution in the client. The lesson frames them as pre-built, well-tested workflows combining the server's tools and resources that users trigger with a simple command.

2026-11-06 · open the original ↗

• Server-authored prompts beat what users write themselves. A user typing "convert report.pdf to markdown" gets decent output, but the lesson argues a prompt engineered and tested by the MCP server's authors gives superior results.
• An MCP prompt returns user and assistant messages ready for Claude. It is defined with the @mcp.prompt decorator (name "format", a description) on a function whose Field-described doc_id parameter is interpolated into instructions to rewrite the document in markdown using the edit_document tool; base.UserMessage comes from mcp.server.fastmcp.prompts.
• The MCP Inspector's Prompts tab shows exactly what gets sent. Supplying a doc_id such as "outlook.pdf" displays the interpolated message.
• Prompts should be high quality and fit the server's purpose. Cited benefits are quality control, consistency, domain specialization and reuse across clients; formatting prompts fit a document-management server.

2026-11-06 · open the original ↗

• Resources put data straight into prompts, skipping tool calls. When a user types "@report.pdf", the client sends a ReadResourceRequest and the ReadResourceResult's content can be inserted into the prompt, so Claude has the document immediately.
• The client's read_resource must parse by MIME type. It calls session().read_resource(AnyUrl(uri)), takes contents[0], and for TextResourceContents returns json.loads of the text when mimeType is "application/json", otherwise the plain text.
• Resources suit stable, frequently referenced content; tools suit dynamic operations. Resources reduce API calls and make content immediately available; tools fit when the model should decide from the conversation whether to fetch information.

2026-11-06 · open the original ↗

• Resources are read-only data endpoints, like HTTP GET handlers. Clients request a URI with ReadResourceRequest and get a ReadResourceResult; a mime_type hints at the data type, which can be strings, JSON or binary.
• Resources are either direct or templated. Direct ones have static URIs ("docs://documents"); templated ones carry parameters ("docs://documents/{doc_id}") that the Python SDK parses and passes as keyword arguments, so URI parameter names must match function parameter names exactly.
• The SDK serializes return values automatically. list_docs returns a Python list with mime_type "application/json" and fetch_doc returns a string as "text/plain", raising ValueError for unknown IDs, with no manual JSON conversion.
• The MCP Inspector shows exactly what clients will receive. Started with "uv run mcp dev mcp_server.py", it shows direct resources and resource templates separately and displays the response structure, including MIME type and serialized data.
• @-mentions pair a direct list with a templated fetch. The direct resource feeds autocomplete with document names and the templated one fetches a mentioned document's content, injecting it into the prompt without the AI needing tools.

2026-11-06 · open the original ↗

• Real projects usually build a client or a server, not both. This course builds both only to show how they work together.
• A custom MCPClient class wraps the SDK's ClientSession. The session is the actual server connection and needs resource cleanup, which the wrapper handles along with connection management.
• The CLI needs only list_tools and call_tool. list_tools returns session().list_tools().tools; call_tool forwards the tool name and Claude-supplied input to session().call_tool and returns the result.
• Test the client directly, then end to end. Running "uv run mcp_client.py" lists read_doc_contents and edit_document with schemas; asking the app about report.pdf should have Claude choose read_doc_contents, the client call it, and Claude answer from the returned contents.

2026-11-06 · open the original ↗

• The Python MCP SDK's browser inspector tests a server without an application. Running "mcp dev mcp_server.py" starts it; the screenshot shows a proxy on port 6277 and the inspector at 127.0.0.1:6274, and the lesson warns the UI is still changing.
• The Tools tab lets you run tools individually and in sequence. After "List Tools", you select read_doc_contents, enter an ID like "deposition.md" and run it; editing with edit_document and re-reading confirms the change applied.
• The inspector gives a fast edit-test-debug loop. The lesson's claim is that it catches issues before integrating with Claude or other apps.

2026-11-06 · open the original ↗

• The Python SDK replaces hand-written JSON schemas with decorators. A server is one line, FastMCP("DocumentMCP", log_level="ERROR"), and @mcp.tool with a name, description and Field-described parameters generates the schema Claude needs.
• The example server has read and edit tools over in-memory documents. Documents live in a dictionary of ID to content; read_doc_contents returns a document's text and raises ValueError for unknown IDs.
• edit_document does an exact-match find-and-replace. It takes doc_id, old_str and new_str and uses Python's str.replace, so old_str must match exactly, including whitespace.
• SDK tools are plain, testable Python functions. Cited benefits are type-hint validation, Field descriptions that guide Claude, errors via ordinary exceptions, and automatic registration.

2026-11-06 · open the original ↗

• The project is a CLI chatbot over documents, with client and server. The MCP server exposes tools to read and update in-memory documents (document.pdf, spreadsheet.xlsx, report.txt, spec.md); the client handles users and talks to Claude.
• Real projects usually build only one side. You'd build a server to expose your service to AI models, or a client to use others' servers; this one builds both purely for teaching.
• Setup is an API key, dependencies, then one run command. Put ANTHROPIC_API_KEY in .env, install with uv (recommended) or pip, run "uv run main.py" (or "python main.py"), and check the chat by asking "what's 1+1?"; the starter cli_project.zip has basic chat, and cli_project_COMPLETE.zip is the finished version.

2026-11-06 · open the original ↗

• MCP is transport agnostic. The common setup runs client and server on one machine over standard input/output, but they can also connect over HTTP, WebSockets or other protocols.
• Two request/result pairs carry most of the work. ListToolsRequest/ListToolsResult asks what tools the server offers; CallToolRequest/CallToolResult runs a named tool with arguments and returns the result.
• A single question triggers a long relay through the client. For "What repositories do I have?", your server gets the tool list via the client, sends query plus tools to Claude, receives a tool-use request, has the client send CallToolRequest to the GitHub MCP server (which calls GitHub), then returns the result to Claude in a user message for the final answer.

2026-11-06 · open the original ↗

• MCP moves tool-writing work from your server to MCP servers. Your server becomes an MCP client connecting to servers that hold tools, prompts and resources and wrap outside services like GitHub, AWS or databases.
• Covering a large service yourself means many tools to maintain. Answering "what open pull requests are there across my repositories?" in full generality would require schemas and functions such as get_repos, search_issues, update_issue, create_issue and create_file.
• Anyone can write an MCP server, often the provider itself. The lesson gives AWS releasing an official server as a possible example, and you can wrap any service you need.
• MCP complements tool use rather than replacing it. MCP is about who builds and maintains the tool schemas and functions; tool use is how Claude calls them, and calling an API directly means writing those definitions yourself.

2026-11-06 · open the original ↗

• Cache tool schemas by marking a copy of the last tool. Clone the tools list and its last schema, add cache_control {"type": "ephemeral"} to the clone, and pass that, so the original definitions aren't mutated and later reordering doesn't break.
• Cache the system prompt by sending it as a text-block list. The system parameter becomes a list holding one text block with the cache_control field.
• Usage fields show whether the cache was written or read. The first request reports cache_creation_input_tokens, identical repeats report cache_read_input_tokens, and changing only the system prompt can show both — but only if the tools alone reach the minimum length, since a breakpoint below it writes nothing.
• A single changed character invalidates the cache entry. That makes stable tool schemas and system prompts ideal candidates, and the lesson recommends building caching into chat functions by default.

2026-11-06 · open the original ↗

• Caching requires a manual breakpoint on a block. Everything before and including the breakpoint is cached and reused only if identical up to that point; adding cache_control {"type": "ephemeral"} requires the longhand content-block form, not the shorthand string.
• Breakpoints can go on system prompts and tool definitions. These are the most common opportunities because they rarely change, and breakpoints also span messages, including assistant messages.
• Tools, system prompt and messages are joined in that order. A breakpoint on the last tool caches the tools but not the system prompt or messages; up to four breakpoints are allowed.
• Content below a model-specific minimum silently isn't cached. For Claude Haiku 4.5, the course's model, the minimum is 4,096 tokens summed across the cached content; no error returns, and both cache_creation_input_tokens and cache_read_input_tokens read 0.

2026-11-06 · open the original ↗

• Without caching, Claude discards its input-processing work after each request. The lesson describes tokenizing, creating embeddings and adding context before generating, all thrown away once the response is sent.
• Conversations force reprocessing of identical earlier content. A follow-up includes the original message and Claude's reply, so the same text gets processed again moments later.
• Prompt caching saves that work for reuse on matching content. The first request writes it to a cache acting as a lookup table and follow-ups read it, making requests faster and cheaper.
• The cache is short-lived and needs exact matches. It lives 5 minutes, but the lesson says repeated content is still extremely common, in conversations, repeated document references and iterated prompts.

2026-11-06 · open the original ↗

• Citations show users answers came from their documents, not memory. Without them users can't verify information or tell it came from supplied sources.
• Enable citations with a title and citations flag. Add "title" (e.g. "earth.pdf") and "citations": {"enabled": True} to the document block; responses then carry cited_text, document_index, document_title, start_page_number and end_page_number.
• Plain-text documents get character locations instead of pages. A text source with media_type "text/plain" returns CitationCharLocation objects, allowing exact sentences or paragraphs to be highlighted.
• Citations pay off in interfaces that display them. Numbered references users can hover or click to see the document and pages let them verify claims, which the lesson calls essential for sensitive documents or users who want the original source.

2026-11-06 · open the original ↗

• Images go in as base64 blocks under hard size and count limits. The lesson lists up to 100 images per request, 10MB per image after base64 encoding, 8000px max side for a single image and 2000px when sending several. Each image costs tokens of ⌈width/28⌉ × ⌈height/28⌉, and the image block sits in the user message beside the text block.
• Simple vision prompts give poor results even on clear images. Asked plainly how many marbles were in a photo of 12, Claude answered 13. The lesson's claim is that the usual prompt-engineering techniques (detailed steps, examples, breaking the task down) apply to images just as they do to text.
• Giving a counting method or a worked example fixes the error. A prompt that numbers each marble and then re-counts row by row from the bottom-left produced the correct 12. So did a one-shot setup: an image labelled as 11 marbles, followed by the target image.
• Real-world vision tasks need a full analysis framework, not a one-line ask. For insurance wildfire assessment from satellite images, the prompt walks through finding the residence, tree overhang (in 0-25/25-50/50-75/75%+ bands), fire vulnerability, and defensible space, then a 1-4 rating. On a heavily wooded property Claude returned "3 (High Risk)", which the lesson reports as correct.

2026-11-06 · open the original ↗

• Extended thinking trades cost and latency for accuracy on hard tasks. You pay for every thinking token and wait longer for the reply. The lesson says to turn it on only after evaluations show that prompt optimization alone still falls short.
• With thinking on, responses carry a thinking block before the text. Each thinking block has a cryptographic signature, so the reasoning cannot be edited when you send it back in later turns; changing it makes signature validation fail. The lesson's reason is that Claude relies heavily on that content to generate its response.
• Flagged reasoning arrives as an encrypted redacted thinking block. You cannot read it, but you should still pass it back in later turns so Claude keeps the context of its earlier reasoning. During development, a special trigger string in the message forces a redacted response so you can test how your code handles one.
• The thinking budget has a floor and must sit below max_tokens. The minimum budget is 1024 tokens, and max_tokens must be larger (at least 1025 for that budget). In the example, a 1024 budget with max_tokens of 4000 leaves up to 2976 tokens for the answer, set through params["thinking"] = {"type": "enabled", "budget_tokens": ...}.

2026-11-06 · open the original ↗

• Chunking cuts each piece off from the document around it. The lesson's argument is that a chunk that no longer knows where it came from, or how it relates to other sections, is harder to retrieve accurately.
• Have Claude write a short context snippet for each chunk before indexing. Claude is sent each chunk with the source document and asked for a brief snippet placing the chunk in the whole. The snippet is prepended to the chunk, and the result goes into both the vector and BM25 indexes. In the example, the snippet ties a Software Engineering section to an incident ID that also appears in the Cybersecurity Analysis section.
• For documents too large for the context window, send a reduced context. Instead of the whole document, send a few chunks from the start, where summaries or abstracts often sit, plus the chunks just before the target. The sample code uses 2 of each.
• The technique pays off where sections depend on each other. It suits technical documents, reports and papers whose chunks refer to concepts defined elsewhere. The cost is an extra API call per chunk, which the lesson considers worth it when context matters.

2026-11-06 · open the original ↗

• Hybrid search can still rank the wrong section first. For "what did the eng team do with INC-2023-Q4-011?", the Cybersecurity section came out ahead of Software Engineering, even though the query is specifically about the engineering team.
• Re-ranking passes the merged hybrid results through Claude for reordering. The prompt gives Claude the user's question and the candidate documents, and asks for the k most relevant in order of decreasing relevance, returned as JSON. The re-ranker plugs into the Retriever as a reranker_fn parameter.
• Ask for document IDs, not text, to keep re-ranking fast. Giving each chunk a unique ID in advance and asking Claude to return only the IDs avoids waiting while it copies out long passages.
• Re-ranking fixed the example at the price of an extra LLM call. With the re-ranker, Software Engineering ranked first, because Claude picked up that the question was about the engineering team. The cost is added latency and an API charge on every search, which the lesson judges worthwhile when precise retrieval matters.

2026-11-06 · open the original ↗

• A single Retriever class can wrap both search indexes. Because VectorIndex and BM25Index share the same add_document() and search() API, the Retriever simply forwards documents and queries to each and merges what comes back.
• Reciprocal Rank Fusion merges results by rank, not raw score. Cosine similarity and BM25 scores aren't comparable, so each document scores Σ 1/(k + rank) across the indexes. k is usually 60; the lesson uses 1 for readability. In the example, sections ranked (2,7,6) by vector and (6,2,7) by BM25 score 0.833, 0.75 and 0.583, giving the final order 2, 6, 7.
• The hybrid search beat vector search alone on the incident query. For "what happened with INC-2023-Q4-011?" it returned Cybersecurity Analysis (the incident report) first, then Software Engineering, then Legal Developments.
• The shared interface makes adding more indexes easy. Any new index that implements search() and add_document(), such as one for named entities, is folded into the RRF ranking automatically, whatever the number of indexes.

2026-11-06 · open the original ↗

• Semantic search can miss exact terms like incident IDs. A query for "INC-2023-Q4-011" returned Cybersecurity and Financial Analysis, when the right sections were Cybersecurity and Software Engineering. The lesson's explanation is that embeddings match on meaning, not exact strings.
• BM25 weights query terms by rarity across the documents. It splits the query into terms, counts how often each appears, and gives rare terms more weight. Chunks with more of the high-weight terms rank higher, so the incident ID counts for far more than a word like "a".
• Run lexical and semantic search side by side, then merge. BM25Index has the same add_document()/search() API as the vector index. Run alone, it put the sections that actually contain the ID first. The lesson sets up merging the two result sets as the next step.

2026-11-06 · open the original ↗

• The basic RAG pipeline runs in five steps. Chunk the text by section, embed each chunk, store the vectors in a VectorIndex, embed the user's query, then search for the nearest chunks by cosine distance.
• Store each chunk's text alongside its embedding. A vector is meaningless to people, so search results are useless without the content they stand for. Some setups store an ID pointing back to the text instead; the lesson stores the text directly for simplicity.
• The example query returned relevant sections with close distances. "What did the software engineering dept do last year?" returned Section 2, Software Engineering – Project Phoenix (distance 0.71), and the Methodology section (0.72); lower distance means more similar. The lesson says later sections will cover cases where this basic approach falls short.

2026-11-06 · open the original ↗

• Chunking, embedding and storage all happen before any user query. Using an imaginary two-number model (medicine, software), the medical section embeds as [0.97, 0.34] because of the word "bug", and the software section as [0.30, 0.97]. Normalized to unit length, these become [0.944, 0.331] and [0.295, 0.955] and are stored in the vector database.
• The query is embedded by the same model and matched by cosine similarity. The software-engineering question embeds to [0.1, 0.89], normalized to [0.112, 0.993]. It scores 0.983 against Software Engineering and 0.398 against Medical Research, so the software section is returned.
• Cosine distance is one minus similarity, so smaller means closer. Similarity runs from 1 (same direction) through 0 (perpendicular) to −1 (opposite). Distance therefore runs from 0 (very similar) to 2 (opposite), and vector database documentation often reports distance.
• The final prompt combines the question with the retrieved chunk. The software-engineering section goes into <report> tags beside the <user_question>. That lets Claude answer from your own documents rather than only from its training.

2026-11-06 · open the original ↗

• Finding relevant chunks is a search problem, usually solved semantically. Semantic search compares embeddings of the question and of each chunk, so it can find related content even when the words differ.
• An embedding is a list of numbers whose features nobody can interpret. Each value runs from −1 to +1 and scores some quality of the text. Labels like "how happy" are only illustrations: the model learns its features in training, and they are not labelled, yet they still allow texts to be compared mathematically.
• Claude can't produce embeddings, so Vertex AI supplies a separate model. The lesson uses text-embedding-005 through the google-genai SDK, calling client.models.embed_content with vertexai=True and returning each embedding's values.

2026-11-06 · open the original ↗

• Bad chunking puts the wrong context in the prompt. In the lesson's example, "How many bugs did engineers fix this year?" can retrieve a medical-research section that calls a pathogen a "bug", rather than the software-engineering section. The result is a wrong answer.
• Size-based chunking is simple but needs overlap to keep context. Equal-length cuts split words (a 325-character document cut into three chunks of about 108 characters breaks "signific/ant") and drop section headers. The sample chunk_by_char uses 150-character chunks with 20 characters of overlap.
• Structure-based chunking is cleanest, but only for reliably structured documents. Splitting markdown on \n## headers gives tidy sections. Plain text, PDFs and user uploads often have no markers to split on.
• Semantic chunking gives the best chunks at the highest cost. It groups sentences by measured similarity, which the lesson says is expensive and more than most applications need. Sentence-based chunking (5 sentences, 1 sentence of overlap in the example) is offered as a middle ground.
• Choose the strategy by document type, then iterate on real data. The lesson recommends structure-based for consistent structure, sentence-based for mixed types, and character-based for code or unknown formats. Start simple and refine after testing.

2026-11-06 · open the original ↗

• Putting a whole large document in the prompt is a poor default. For an 800+ page financial report, the lesson gives three reasons: the text may exceed the hard input limit, Claude gets less effective with very long prompts, and big prompts cost more and run slower.
• RAG chunks the document and sends only the relevant pieces. A question about risks pulls in only the Risk Factors chunk. That keeps Claude focused, scales to large or multiple documents, and makes prompts cheaper and faster.
• RAG adds engineering work and can drop needed context. It needs a preprocessing step, a way to search for "relevant" chunks, and a choice among many chunking methods. Retrieved chunks can also miss context: Risk Factors alone leaves out the Strategy Outlook section on how the company plans to handle those risks.

2026-11-06 · open the original ↗

• Web search is built into Claude; you only supply a schema. The schema has type web_search_20250305, name web_search, and max_uses (5 in the example), which caps how many follow-up searches Claude can run. Claude then decides for itself when to search.
• allowed_domains restricts searches to trusted sources. The example limits searches to nih.gov, so health answers come from government sites rather than random fitness blogs.
• The structured response is designed for rendering with citations. It contains text blocks, the exact search query used, the search results with titles and URLs, and citations tying statements to source text. The lesson suggests showing the results as a reference list, citations inline, and the cited text highlighted, so users can check Claude's sources.

2026-11-06 · open the original ↗

• Claude knows the text editor tool's schema, but you write the implementation. Claude can ask to view files, directories or line ranges, replace text, create files, and insert lines. Your code has to perform each of those operations.
• A small, model-specific schema stub turns the tool on. For Haiku 4.5 the stub is type text_editor_20250728 with name str_replace_based_edit_tool, and Claude expands it into the full specification. Version strings for other models are in Anthropic's text editor tool docs.
• The tool lets your own app work like an AI code editor. In the example, Claude views main.py, rewrites it with a function that calculates pi to the 5th digit, and creates test.py with unit tests. The lesson pitches it for apps that edit files programmatically or run without a full-featured editor.

2026-11-06 · open the original ↗

• A forced tool call extracts structured data more reliably than prompting. You write a schema for the data you want and force Claude to call it, then read the result from response.content[0].input. No follow-up message is needed. The lesson contrasts this with the simpler prefill-and-stop-sequence approach, which is easier to set up but less reliable.
• tool_choice decides whether Claude must call a tool. auto (the default) lets the model decide, any requires some tool, and {"type": "tool", "name": ...} requires a specific one. Extraction uses the last option to guarantee the schema tool is called.
• Use prompting for quick jobs and tools for guaranteed structure. The lesson's article example extracts title, author and a list of key insights. It recommends tools whenever reliability matters more than the extra setup.

2026-11-06 · open the original ↗

• Claude often makes parallelizable tool calls one at a time. Asked to set two reminders for the same date, it typically calls the tool once, waits for the result, then calls it again, rather than sending two tool use blocks in one message.
• A batch tool nudges Claude into grouping its calls. The batch_tool schema takes a list of invocations, each with a tool name and arguments. run_batch runs each one through the normal run_tool router and returns the results together. The lesson openly calls it a workaround that "tricks" Claude.
• Batching cuts the round trips to one call and one reply. With the batch tool, both reminders went out in a single call and the results came back in one follow-up, which the lesson says reduces latency.

2026-11-06 · open the original ↗

• Once the tool plumbing exists, adding a tool takes three steps. Add its schema to the tools list in run_conversation, add a branch for it in run_tool, and write the function. The reminder system gets three tools: get the current datetime, add a duration (because Claude isn't reliable at date arithmetic), and a placeholder set_reminder.
• Claude chains tools across turns to finish a compound request. For "a reminder 177 days after Jan 1st, 2050", it first called add_duration_to_datetime to get June 27, 2050, then set_reminder. Each assistant message pairs a text block explaining the step with a tool use block.

2026-11-06 · open the original ↗

• Keep looping until Claude stops asking for tools. run_conversation calls Claude, appends the reply, and stops when stop_reason is anything other than "tool_use". Otherwise it runs the requested tools and sends the results back as a user message.
• Every tool use block needs a matching tool result block. run_tools picks out every tool_use block in the reply and builds a result for each, with the same ID in tool_use_id and the output as JSON in content.
• Return failed tool calls as results, not as exceptions. If a tool raises, the code still sends back a tool result with "Error: …" as the content and is_error: True, so Claude sees what went wrong.
• Route tool names through a separate run_tool function. A dispatcher that maps names to functions lets you add tools without touching the conversation loop.

2026-11-06 · open the original ↗

• One question can need several tool calls in sequence. "What day is 103 days from today?" makes Claude call get_current_datetime, then add_duration_to_datetime, before it answers. The application must handle that back-and-forth automatically.
• Helper functions must handle whole messages, not just text. add_user_message/add_assistant_message now accept a string, a list of blocks, or a full Message. chat takes a tools list and returns the full message, and text_from_message joins the text blocks for display. The point is to keep every block Claude returns, not just the text.

2026-11-06 · open the original ↗

• Call your function with the tool block's input, then return the output. The tool use block's input dict is unpacked with ** into the function. The output goes back in a tool_result block with the matching tool_use_id, the output as a string in content, and an is_error flag.
• Matching IDs pair each result with its request, whatever the order. When Claude asks for 10 + 10 and 30 + 30 in separate tool use blocks, the results can come back in either order, because each result carries its request's ID.
• Send the tool schema again in the follow-up request. The follow-up carries the full history plus the tool result. Even if Claude won't call the tool again, it needs the schema to understand the tool references in that history.

2026-11-06 · open the original ↗

• A tool-enabled request returns an assistant message with several blocks. Passing schemas in tools can produce a reply with a text block explaining the step and a tool use block. The tool use block holds an ID, the function name, and inputs matching the schema.
• Append the entire response content to history, not only the text. Claude keeps no history between calls, so messages.append({"role": "assistant", "content": response.content}) is needed to keep the tool use block for later calls. Helpers that only handle a single text block have to be updated.

2026-11-06 · open the original ↗

• A tool spec is a name, a description and a JSON Schema. JSON Schema is an existing data-validation standard that the AI field adopted. The lesson advises descriptions of 3-4 sentences covering what the tool does, when to use it and what it returns, plus a detailed description of each argument.
• Have Claude write the schema for you. Paste the function into Claude with Anthropic's tool-use docs attached and ask for a valid schema that follows their best practices. Store it under a function_name_schema variable, optionally wrapped in ToolParam to avoid type errors later.