Claude Academy

2026-11-06 · open the original ↗

• The course's throughline is delegating real work, not chatting. The recap ties its four modules together: meeting Cowork, making it yours (global instructions, projects, skills, plugins), using it in Chrome and Microsoft 365, and sharing and safety.
• Pick one concrete next step to do this week. The options are a five-sentence global instructions block or a project, scheduling a recurring deliverable or starting a task from the phone app, installing the role plugin from Customize → Plugins, trying Claude in Chrome or M365 on one task, or sharing a skill or workflow with the team.
• Further courses are recommended for going deeper. The lesson points to AI Fluency: Framework & Foundations, AI Capabilities and Limitations, Claude 101, and the Claude use-case library filtered to Cowork.

2026-11-06 · open the original ↗

• Sharing a plugin in a company is a hand-off, not a setup. The recommended channel is the organization's private, admin-managed marketplace; you bring the plugin to its owner (a team lead, enablement or operations, or IT) and they publish it.
• The publisher chooses how hard the plugin lands on everyone. The levels are Available (in the Directory, optional), Installed by default (on, but can be switched off), Required (on and locked, for compliance-type work) and Hidden (for staging or restricted rollouts); teammates see it labeled as from their company and can't edit it, since updates flow from the maintainer.
• Your next step depends on how your org is set up. If the marketplace exists, hand the plugin to its owner; if you don't know, ask whoever manages Claude whether it is on, and meanwhile export the plugin folder and share it manually; if you are the admin, create the marketplace under Organization settings → Plugins, by upload or by syncing a GitHub repo.
• Shared plugins go stale without a few standing habits. The lesson asks for one named owner per plugin, evals as the gate before every publish, specific names ("sales-customer-renewal-prep", not "meeting-prep") to avoid collisions, and a review rhythm, with quarterly suggested as a starting point for retiring unused plugins.

2026-11-06 · open the original ↗

• A skill that works for its author can still fail teammates. The author knows how to phrase requests and what inputs to give; a colleague phrases things differently or hits an edge case, and won't know why the skill stumbled.
• An eval compares the skill's output against Claude without it. Skill-creator generates two or more realistic prompts and, for each, one output with the skill and one without, so the question becomes whether the skill beats Claude's baseline, not merely whether the output is acceptable.
• Feedback has to be specific enough for Claude to act on. "The tone is too formal" or "it skipped the executive summary" works; "this isn't quite right" doesn't. Claude then revises the skill from that plain-English feedback.
• Iterate one change at a time, and stop when it's good enough. Fixing one issue per round shows what moved the needle; most skills are ready after one or two rounds, and the shipping bar is that the cases you care about beat the baseline meaningfully and the unhandled cases are named.
• The mock exercise judges recaps against explicit house rules. Three meeting-recap cases (typical, messy notes, an exec who reads three lines) are checked for leading with decisions, an owner and date on every action, open questions surfaced, and staying under 150 words; the without-skill versions fail by burying items in prose or inventing an owner.

2026-11-06 · open the original ↗

• The working folder is the highest-leverage safety choice. It bounds what Claude can read, write and (with confirmation) delete, so the lesson says to use a dedicated folder rather than Documents, Downloads or Desktop.
• Protect what can't be regenerated before Claude ever touches it. Keep irreplaceable files backed up somewhere Cowork can't reach, and run new workflows, such as a weekly scheduled task, against a copy first; the stated risk is clicking through the wrong confirmation.
• Prompts should leave no room for a destructive misreading. Spell out ambiguous verbs ("remove the section from the draft, but keep the file"), name bounds ("only contracts that closed in Q3", "draft only"), and have scheduled tasks draft for review rather than send until they are proven.
• Three in-the-moment checks catch most remaining mistakes. Read the plan in the progress tab, stop the task if it touches files or sites you didn't mention, and read confirmation prompts deliberately while staying in "Ask before acting" for anything that sends, posts or shares; the lesson says most mistakes come from clicking through, not failed safeguards.
• Some work shouldn't go to Cowork at all. Cowork activity isn't in audit logs or data exports (the Compliance API returns session transcripts only for Claude Enterprise), so regulated workflows needing an audit trail are out, as is shipping anything external unsupervised or handling sensitive personal data outside IT-approved bounds.

2026-11-06 · open the original ↗

• In Microsoft 365, Claude works inside the open document. It runs as an add-in in Word, Excel, PowerPoint and Outlook; the lesson's video is a screen demonstration with no narration, so the substance is in the page text.
• Each app gets its own in-place capabilities. In Excel it writes formulas, debugs #REF! and circular references, and runs scenarios; in PowerPoint it follows the slide master and builds native editable charts; in Word it drafts and works with comments and tracked changes; in Outlook it triages and drafts replies using prior threads and calendar context.
• One conversation carries context from app to app. The worked chain goes Outlook brief → Word memo from the firm template → Excel market-sizing model using the brief's assumptions → PowerPoint steering-committee deck → an Outlook invite that waits for you to click Send.
• Use Cowork for many-source deliverables, M365 for refining files. Cowork suits pulling from many sources, such as twenty files or a CRM plus three Slack channels, or running on a schedule; the add-in suits editing in place, and the lesson says most real work uses both on the same file.
• Outlook is a separate beta from the other add-ins. It has its own listing, and where IT manages add-ins, installation goes through them.

2026-11-06 · open the original ↗

• Claude in Chrome bridges tools that have no connector. The examples are internal BI dashboards (Tableau, Looker), vendor portals without an API, CRMs behind single sign-on, internal web apps, and multi-tab web research that ends in a brief.
• Chrome and Cowork split one delegation between browser and deliverable. In the worked example, Claude filters a login-only customer health dashboard to yellow and red accounts, exports them, then pulls 30 days of Drive activity and #customer-success Slack threads and builds a one-page summary in the folder.
• Claude works only in sessions you are already signed into. It can't log in for you, and because it sees whatever you can see on the web, the lesson says to narrow what it can act on for sensitive sites and review actions before approving.
• The video presents the extension as safety-first by design. Anthropic's promo, set around organizing a home-renovation budget, describes Sonnet 4.5 doing the browsing, granular permissions, prompt-injection protections, website restrictions, and always asking before sensitive actions like purchases.

2026-11-06 · open the original ↗

• A plugin packages a job's skills, connectors and subagents. A skill is one playbook; a plugin bundles several plus what they depend on, so the team's expertise "travels with the install, not the person." A subagent is a purpose-built helper that runs one part of the work in its own context.
• Plugins take one of two shapes. One is an end-to-end pipeline of sequential steps, such as a monthly close or an A/B-test readout running from warehouse pull to decision memo; the other is a function's toolkit of independent, most-used skills, such as a legal plugin for NDA redlines, clause fallbacks and jurisdiction checks.
• Marketplace plugins are a starting default, then customized. Anthropic publishes role plugins (finance, legal, sales, marketing, support, product and more) under Customize → Plugins; clicking Customize opens a task where you supply examples, such as your last three red-lined NDAs, and Claude adapts the plugin in place.
• Build your own plugin by growing skills one at a time. The lesson says most teams start with one skill for the most repetitive task, and by three or four skills plus their connectors it is worth sharing; check the Directory first in case the admin already published one.
• The /setup-claude skill interviews you and recommends a plugin. It asks about your work, suggests a plugin you can add and test from chat, and the lesson adds that output from any plugin is still yours to review.

2026-11-06 · open the original ↗

• A skill is a reusable playbook Claude loads when tasks match. It is a folder of files and resources teaching Claude how to do one kind of work your way; Claude picks it up automatically when a task fits, or you can name it explicitly.
• A skill can hold four kinds of files. SKILL.md holds the instructions, written like a runbook for a new colleague; assets are templates, logos and slide masters; references are examples of good past work that show the bar; scripts are small code for the parts that must run identically every time.
• What goes in a skill should follow the work, nothing more. The lesson's examples run from a meeting recap that is just a SKILL.md, to a memo skill adding templates and two prior memos, to a variance skill whose Python script "owns the math" while Cowork drafts the write-up.
• The fastest way to build a skill is to ask Claude. Claude interviews you on what it should do, when it triggers, and what good output looks like, then produces the folder; later corrections, such as flagging any deal over $100K that slipped two stages, are applied to the skill in place.
• Skills apply in any conversation, inside projects or not. A variance-analysis skill shows up whenever that is the task, in the default Cowork session or in a finance project.

2026-11-06 · open the original ↗

• Deliberate standing context carries between tasks more reliably than memory. Claude's own memory from conversations does apply in Cowork, but the lesson says the dependable layers are global instructions, which apply to every session, and projects, which build memory from the conversations held inside them.
• Global instructions should state who you are, your shorthand, and output preferences. They are written once in Settings (sometimes labeled "Instructions for Claude"); the finance example sets a 5% variance materiality threshold, a fixed Variance/Forecast/Risks/Asks memo order, and always showing the calculation.
• Corrections you keep repeating belong in global instructions. They needn't be complete on day one; recurring corrections like "bottom line up front" or "no Oxford commas" are the candidates to add.
• A project scopes one stream of work and accumulates memory. It holds project instructions, scheduled tasks that run with its context, folders or links as context, and a memory Claude builds itself, so the next task opens with last week's decisions in hand; good fits are a client account, a recurring deliverable, or a launch.
• A project can start from scratch, a folder, or an existing project. Starting from a local folder makes it the working directory; starting from an existing project carries its instructions and knowledge over, and folder, instructions and connectors can be changed later.

2026-11-06 · open the original ↗

• Four independent building blocks compound to make Cowork more capable. Global instructions teach who you are, projects the context of one stream of work, skills how a specific process is done, and plugins the expertise of a role, turning Cowork from generalist to specialist.
• Adopt each block when your work reveals the need. The lesson's sequence: global instructions as you see what applies everywhere, projects as recurring workstreams emerge, skills when you explain the same workflow repeatedly, and plugins once a process is worth sharing.

2026-11-06 · open the original ↗

• A good Cowork prompt names deliverable, inputs and nuance. Format and length avoid a regenerate, the named folder, channels or date range set what Claude reads, and the nuance carries what only you know, such as accounting for 3 new locations opened in Q3 last year.
• Clarifying questions move the back-and-forth upfront. Because Claude goes away and returns with a finished artifact, it closes format, scope, audience and rigor gaps before starting; a skipped question means Claude guesses, which may only surface at the end.
• Steer mid-task instead of waiting to regenerate. Interrupting when Claude picks the wrong source, format or tone is cheap: in the example, switching templates mid-draft reuses the analysis already done rather than restarting.
• Review the deliverable like a draft from an unproven colleague. Check it meets the objective, verify figures against the sources Claude names, and treat any untraceable date, name or quote as a red flag; fix a mostly-right draft by asking for edits, and a load-bearing miss by supplying the missing context.
• The video's core loop is plan, approve, then execute. In its Downloads-cleanup example, Claude proposes categories and naming rules, flags four likely duplicates, and the user redirects two to a review folder before Claude moves files; the video adds that sessions are stored locally and the desktop app must stay open while Claude works.

2026-11-06 · open the original ↗

• Three patterns mark a task as right for Cowork. It is multi-step (gather, compare, draft, format in one prompt), it lives in real files read and saved back in your folder, or it spans several tools via connectors; the difference from chat is that Cowork plans across them as one delegation.
• Scheduled tasks turn a proven one-off into a recurring run. You can type /schedule and describe it fresh, but the lesson calls it more natural to do the task once, confirm the output, then /schedule that exact process at an hourly, daily, weekday or manual cadence.
• Where a scheduled task runs depends on what it needs. Connector-only tasks run remotely with the computer off; tasks needing local files or apps run on your machine with the desktop app open, and if it is asleep or off, Claude runs the task on return and reports the delay.
• Tasks started from phone or web reach connectors, not local folders. They run remotely, so nothing needs to stay on, and a task stays on the surface where it started; admins may control whether this is enabled.
• The judgment stays with you while Claude does the work. Claude plans, executes and asks; you decide what gets sent, shared or shipped.

2026-11-06 · open the original ↗

• Pick the smallest folder that holds what the task needs. The folder grants read and write access to everything inside it, which is what distinguishes it from attaching files; the exercise shows a home folder exposing all 24,000 files, personal ones included, versus the single project folder.
• Cloud connectors often can't edit, so documents get built locally. Many, including the default Google Drive and M365 connectors, are read-and-search only, so the working folder is where files get edited; tasks started from web or phone reach connectors but not local folders.
• Connectors are set up once and toggled per task. Common first ones are email and calendar, Slack or Teams, cloud storage, and CRM or project tools; reach determines what Claude can draft and what it must ask you for, and broader access is weighed against how far you trust each connector.
• Two permission modes govern outside actions; deletion always asks. "Ask before acting", the default, pauses before sending, posting or sharing, while "Act without asking" is for trusted, supervised work; in both, permanent deletion requires confirmation that can't be skipped, and admins can switch off web search and limit Chrome's sites.
• Test the setup on real material, not toy files. The suggested first task is pointing Claude at a real project folder (or a copy), connecting one app, asking for a brief on what's in the folder, and checking it against what you know.

2026-11-06 · open the original ↗

• Cowork is for delegating work, not chatting about it. You describe an outcome and Claude plans, executes and returns a finished deliverable; the lesson calls this the biggest shift for new users, whose chat habit is to ask, read and iterate.
• Chat is turn-by-turn; Cowork sustains a whole piece of work. Chat can pull from tools, but you stitch the steps together; Cowork pulls from many tools at once and runs multi-step plans, which the lesson says uploads to chat can't fully close.
• Cowork's kind of work combines four traits. The sample prompt about last quarter's pricing decision shows them: local files read and written directly, several tools in one run, multiple steps, and a real deliverable such as a .docx rather than a reply.
• Chat is for thinking, Cowork for delegating, Code for software. Claude Code works inside a repo with tests and git; the lesson notes Cowork can read source files but isn't built to run test suites or manage git.
• A deliverable, not a connector, is what signals a Cowork task. Asking for themes in a Slack channel is still chat, because the answer is the conversation; a brief built from a Desktop spreadsheet and saved to a Reports folder is Cowork, because of the real file and save location.

2026-11-06 · open the original ↗

• Most rollout decisions carry over when a new product arrives. Organization boundary, groups and roles, governance posture, caps and visibility usually hold because they reflect objectives rather than products. They should still be re-checked, and a genuinely new kind of product can raise questions of its own, as agent surfaces added task-scoping to spend guidance.
• Each new product gets three questions. Who gets it (the surface decision again, with phasing)? What does it carry (its own settings or connectors)? Does it move risk (new data, new autonomy or new people in front of Claude)? If it moves risk, the risk owner is consulted.
• Claude Tag works under its own identity with the channel's access. In channels, Claude Tag (Claude inside Slack, in beta on Team and Enterprise) gives everyone the same capability, with results visible to the whole channel. In DMs and the assistant panel it uses the member's own account and seat limits, though group DMs and some DMs from members without accounts bill to the organization.
• Pluto restricted Claude Tag by role and set fresh spend limits. By default anyone in the Slack workspace can use it, so Pluto turned on role restriction and enabled it only in channels of units already working in Slack threads. Channel usage bills to the organization with no upper bound until a limit is set, so the spend owner set limits alongside the existing caps.
• Claude Tag's channel-wide access moved risk, so the risk owner signed off. Pluto kept the default "Restrict" setting that blocks Claude in channels with guests, which also excludes Slack Connect channels shared with other companies. Claude Tag stays off entirely for Payments & Trust.

2026-11-06 · open the original ↗

• Each decision should trace back to the rollout objective. The lesson sets Pluto's five answers beside the learner's, each tied to Pluto's goal of weekly use in every unit with no Payments & Trust escalation. A difference from Pluto's answer that can't be explained against one's own objective deserves a second look before going to stakeholders.
• A change's reach depends on its place in the decision map. Moving a member into payments-eng changes their role, surfaces, connectors, posture and cap, the widest effect. A new write connector, a looser posture or a lower cap stays contained to itself plus its record, and turning on the Compliance API changes nothing because Visibility only reads the other decisions.
• Adding a group means configuring it across several decisions before go-live. At Pluto a new group needs a surface grant, a connector scope, a cap and a dashboard filter before anyone in it can use Claude.
• A regulated function should be one posture, not five exceptions. Payments & Trust is handled through the ordinary system: its own group, the same surfaces with Claude Code held and connectors read-only, approve-first governance, an ordinary cap with each increase reviewed, and the organization's shorter retention plus a named Compliance API reader. The lesson says this is why the arrangement holds.
• Every open item needs a blocker, unblock step and deadline. Each item should name what is blocking it, what it takes to unblock it, and a decide-by date. The pre-kickoff steps are confirming the four hard-to-undo settings, closing or dating open items, and sequencing structure, access, governance, spend and visibility before go-live by group. The lesson says an owner's name alone is not a plan.

2026-11-06 · open the original ↗

• Adoption numbers show that Claude is used, not what that use produces. The lesson treats breadth and depth as leading indicators to be paired with the outcomes of the work. A high count can be one keen team and a low one a team never enabled, so a number shows where to look, not what will be found.
• Breadth and depth signals point to different causes. Low active members by group or low week-over-week return (breadth) point to access, awareness or onboarding. Low chats per member, skills or projects in use, or connector use (depth) point to fit with surfaces and connectors, governance posture or connector scope.
• Never turn an adoption signal into a quota. The lesson warns that members then optimize for the number instead of the work. Group reads should include usage reported under "Chat and Cowork unified" before concluding a group's depth is low.
• Pluto's flat Ops number was an enablement gap, not a failed rollout. Four weeks in, Ops sat at about 10% of members active. Treating it as a breadth signal, Pluto asked the Ops lead and found the field staff hadn't had their enablement session; the fix was a workshop replay or targeted session, not a settings change.
• Set a concrete pace goal against a signal you can actually read. "Every granted group returning weekly within eight weeks" is a pace; "good adoption soon" is a wish. The lesson says to pick the group most likely to lag, decide the first response to a flat number in advance, and agree checkpoints with unit leaders.

2026-11-06 · open the original ↗

• Turn on recording before access, because gaps can't be filled later. Activity feed events and local Cowork and Claude Code session transcripts are captured only while the Compliance API is on. Any period before it is switched on leaves questions with no record to answer them.
• The Compliance API is the record of conversation content. It covers chat, file content, activity events and Cowork and Claude Code sessions, and includes audit-log events; audit logs on their own are metadata only. The Primary Owner enables it, and the lesson stresses routing it to an existing SIEM or security review with a named reader, since "a record no one reviews isn't actually a control".
• OpenTelemetry shows how the surfaces are running and is optional. Claude Code logs prompts only by opt-in, and current Claude Desktop sends only Cowork metadata unless the otlpContentCapture policy is set. That metadata always includes members' email addresses and connected folder paths, so the lesson advises filtering them in the collector where policy requires.
• Shortening retention permanently deletes content. The default keeps content indefinitely; custom windows start at 30 days, with no zero option. The setting applies organization-wide, so a regulated group's shorter window applies to everyone; activity feed and remote session transcripts are kept six years regardless, and HIPAA-ready organizations keep local transcripts for 30 days.
• Pluto routes its record into an existing review. Pluto's Primary Owner enabled the Compliance API before general rollout and routed it into the security review Pluto already runs. Retention is set to the shorter window Payments & Trust requires, and the reviewer archives anything Pluto must keep longer before it is deleted.

2026-11-06 · open the original ↗

• Usage, not headcount, drives the bill, from one shared pool. A typical agreement charges a per-member platform fee plus pooled token consumption, billed monthly in arrears on sales-assisted contracts or prepaid as credits on self-serve. Agentic surfaces (Cowork, Claude Code) use more per task, one group's heavy month draws from everyone's pool, and any level left uncapped is unlimited.
• The default model and effort level move more spend than caps do. Most members never touch the model picker, so a top-model, high-effort default is the most expensive configuration. Organization instructions (short answers, only the needed files), reusable skills, and member habits such as deleting unused scheduled Cowork tasks are softer levers.
• Treat each cap-increase request as a reason to investigate first. Repeated raises may mean real growth, or a cap set below need; the review should adjust settings when usage is the problem and re-base the cap when the cap is. Caps should also be reviewed on a schedule for groups that are under-using them.
• Pluto cut spend by changing a default model, not raising a cap. In month two, Platform's increase request turned out to be mostly the most capable model running routine pull-request summaries. Pluto lowered the Engineering role's default model, left the cap alone, and Platform ran under its cap the next month at the same volume of work.
• Review spend monthly, and more often in the early months. Weekly or biweekly reviews suit the first months, a new surface or a budget with no headroom; a regulated group may need its own review and owners. The dashboard, Analytics chat and Analytics API serve regular reviews, one-off questions and finance chargeback respectively.

2026-11-06 · open the original ↗

• Spend caps sit at three levels, and the organization ceiling is absolute. The levels are a monthly organization ceiling, group caps (a per-member limit each member inherits, not a pooled budget), and per-member overrides, with a seat default underneath. When a member is in two capped groups, the "Member limit from groups" setting picks the higher or lower cap, unlike permissions, where the union always wins.
• Hitting a cap pauses the member until reset or approval. Usage stays paused until the month resets or an increase request is approved. Requests land on the Usage page for Owners, Primary Owners or roles with Billing "Can manage". Because approvers often aren't the budget owner, requests can wait days, and large organizations often route them through their own ticketing using the Spend Limits API (in public beta).
• Size group caps to the typical member, and use overrides for exceptions. A growing list of overrides signals that those members need their own group. Pluto gave a handful of heavy Claude Code users on Platform overrides after the first month, rather than raising the cap for every Platform engineer.
• Start from light, standard and power tiers, and adjust against real usage. The lesson cites the consumption guide's tier structure. With no usage history, start tight and re-base on evidence after a month; set temporary headroom for spiky work. If credits are prepaid, usage pauses organization-wide when they reach zero.
• Decide who approves cap increases when the caps are set. Routine requests go to named approvers within a range agreed with the budget owner, and anything that would move a group cap or the ceiling is the budget owner's decision. Caps themselves can be changed freely at any time.

2026-11-06 · open the original ↗

• Governance decides how far one member's customizations can spread. It covers skills and plugins (packaged, reusable workflows), project sharing, and organization instructions (always-on context in every conversation). The stated risk is sprawl: near-duplicate skills, unreviewed workflows that others assume were reviewed, and sensitive projects shared organization-wide.
• Skills don't work unless code execution is on. Members can use skills only after an admin enables "Cloud code execution and file creation" and Skills in Organization settings. Whether skills are allowed at all is an organization-wide setting, while a custom role's Create skills and sharing capabilities decide who can build and share.
• Four distribution controls make up the governance posture. They are Owner provisioning to everyone, direct skill sharing (on by default), sharing with groups (off by default), and publishing to the organization library as "Off", "Requires review" or "Open". Under "Requires review" no one can approve their own submission, and the publishing default varies by organization, so it should be checked.
• Match the posture to how the company already handles internally built tools. "Open build, reviewed spread" needs a CoE or champions to review, "Centralized" means a staffed team builds everything, and "Fully open" suits small, high-trust organizations. Pluto uses reviewed spread for most groups and approve-first for Payments & Trust, enforced through a reviewer and policy.
• Two tightening moves behave in opposite ways. Turning off "Public projects" makes existing public projects private, and they stay private if it is turned back on. A stricter Publishing setting removes nothing already published, so skills in heavy use have to be reviewed and removed by hand.

2026-11-06 · open the original ↗

• A connector works only when three gates are open. The gates are the organization (an Owner makes it available), the role (an Owner grants it per group), and the member (who connects their own account). Claude inherits the member's own permissions in the source system, and the lesson calls enabling a first connector one of a rollout's higher-leverage adoption moves.
• Check existing roles' connector settings, because older roles default to open. Custom roles that already existed were set to "Always allow" on every connector, while new roles start at "Needs approval". Write and delete tools can each be set to Always allow, Needs approval or Blocked, and blocking them keeps a connector read-only.
• Enterprise-managed authorization replaces the member's own connection step. With EMA, access is provisioned through the IdP, so everyone in scope gets the connector at first login with permissions taken from IdP groups. It works only for connectors whose provider supports it.
• Start read-only; add write access only with risk-owner sign-off. Write access lets Claude change or overwrite data as the member, so the lesson advises having the data-risk owner approve once a workflow has shown the need. Pluto gave every group its drive and wiki read-only, gave Engineering its ticket tracker read-write with sign-off, and kept payments-eng read-only.
• Connector settings are reversible, but narrowing them breaks workflows. Widening access costs members nothing, while revoking write access or removing a connector breaks what members built on it. The lesson advises announcing each change and routing requests through the access owner.

2026-11-06 · open the original ↗

• Using a surface needs both an organization toggle and a role grant. The organization-wide switch is the ceiling, and under it a surface reaches only the Custom-role members whose group's role includes it. Built-in-role members get every surface that is switched on.
• Claude Code needs extra boundary settings owned by the platform lead. The admin decides which groups get Claude Code; the platform or engineering lead uses its managed settings to set the files, commands and network destinations each group can reach. Those settings can pin its default model, but which models are available is still set on the Models page.
• The default model steers most spend, because most members never change it. Defaults can be set for the organization or per custom role, alongside a default effort level. Organization-wide model toggles and per-model effort caps can't be exceeded by any role; roles can narrow further, though Haiku models can't be turned off.
• Grant broad surfaces first, and specialized ones only where work needs them. Other options are a pilot with one team, or phasing in a surface once a review clears. Pluto gave chat and Cowork to every group and Claude Code to Engineering and Platform, and held Claude Code back from payments-eng until visibility reporting was in place.
• Granting a surface later is cheap; revoking one is costly. A group that has built workflows on a surface loses a tool mid-work, so taking it away is a change to manage with members.

2026-11-06 · open the original ↗

• Nearly every later control attaches to a group. One group structure covers every surface, and a few settings are organization-wide ceilings instead. The lesson says that wanting to scope a control to "just these three members" is a sign the organization needs another group.
• Access is set by role, and roles attach to groups. Admin roles (Primary Owner, Owner, Admin) govern settings; billing and editing caps are Owner-and-above, and data export and handing over the Primary Owner role are reserved to the Primary Owner. Custom roles set capabilities, model access, connector permissions and admin permissions, but only members on a custom role are restricted; built-in roles keep everything enabled organization-wide.
• Membership in several groups gives the union of their permissions. A narrower group can't remove what a broader one grants, so a tight boundary needs its own group, with those members kept out of the broad group that carries the sensitive permission.
• The hybrid group pattern suits companies with a risk boundary. Mirroring the org chart fits controls that vary by department, tiering by risk fits boundaries that cut across departments, and the hybrid pattern uses department groups plus a carved-out group. Pluto put its payments engineers in a dedicated payments-eng group, outside Engineering, so they don't inherit its broad connector access.
• Groups are cheap to change, but live IdP-to-role mappings are not. Adding, renaming or re-roling a group is low stakes. Changing a live mapping shifts access for everyone it covers, and reversing it is a second mass change.

2026-11-06 · open the original ↗

• An organization is a hard boundary for content and settings. Projects, conversations, artifacts, custom skills and settings don't cross between organizations. Several organizations can share sign-in (IdP, domain verification, SSO, provisioning) under a parent organization, while each keeps its own billing and usage tracking.
• Run one organization unless one of three triggers applies. The triggers are a separate contract with Anthropic, an identity provider that can't join the main sign-in, or a regulatory or contractual wall around data. Separate caps, connectors or a stricter posture for one unit are group-and-role work, not reasons to split; each split repeats all five decisions.
• Splitting or merging organizations later means a full rebuild. It involves standing up or retiring an organization, sorting out domain verification and re-provisioning members who move. The lesson calls adding a separate organization later cheaper than pulling apart one that was over-consolidated.
• Pluto runs one organization despite its regulated unit. It has one contract, one IdP and no requirement to isolate data, so Payments & Trust gets its tighter controls through groups and permissions.
• Directory sync (SCIM) beats just-in-time provisioning for keeping groups accurate. JIT creates a member at first sign-in but doesn't sync groups, which then have to be maintained by hand. SCIM pushes members and group memberships so Claude follows team changes, and any control is only as accurate as the membership underneath it.

2026-11-06 · open the original ↗

• Claude Enterprise is run from three separate places. Organization settings change what a group may do, the identity provider changes who is in a group, and Claude Console handles API keys as a separate organization. Claude Code managed settings are a fourth place, owned by the platform lead.
• Four of six prerequisites must be in place before group setup. The four are: at least two directly assigned Owners, a verified domain, an IdP connection with SSO enforced, and the provisioning app in the IdP. A group naming convention and a named billing owner can run in parallel.
• Two directly assigned Owners protect against locking yourself out. With IdP role mappings, those Owners must be in the group mapped to Owner before the mapping is saved, because afterwards only the Primary Owner, who is never auto-removed, can restore access. The lesson advises keeping the Primary Owner out of day-to-day admin.
• Domain claiming is optional, irreversible, and needs advance warning to members. It requires a verified domain, "Restrict organization creation", enforced SSO and live provisioning. Personal accounts on the domain then get a 30-day window to migrate or start fresh, and custom skills and connected-app authorizations don't carry over; under HIPAA readiness or customer-managed keys nothing moves.
• Pluto's one real hurdle was domain claiming, and it worked. About forty members, mostly engineers, were already on Pluto's domain; the IT lead sent notice two weeks before the claim and all had migrated when the 30-day window closed. The Primary Owner role stays with the CIO, deliberately out of daily use.

2026-11-06 · open the original ↗

• A decision without an owner stalls the rollout. The lesson says to choose owners by what they are accountable for and can commit, not by title, since roles like a "Claude spend owner" may never have existed before.
• Spend and Visibility usually belong to someone other than the admin. Spend goes to whoever commits the budget, and Visibility to whoever answers for data risk (security, legal or compliance). Structure, Access and Governance pair the Owner with the IdP team, team leads plus a data-risk sign-off, and change-management or AI Center of Excellence staff respectively.
• Pluto adds co-signers wherever risk enters. The IT lead owns Structure and Access, but the Payments & Trust risk lead co-signs any connector grant that writes and owns Visibility. The CoE lead owns Governance and a CFO's delegate owns Spend.
• An intake questionnaire flags which decisions need extra care. Several contracts or IdPs complicate Structure; regulated work needs a boundary narrower than a department; four or more first-wave functions mean surfaces get set per group. A missing data-risk or budget owner leaves Governance, Visibility or Spend with nobody to sign off.

2026-11-06 · open the original ↗

• Five rollout decisions must be made in a fixed order. The course names them as Structure & Identity, Access, Governance, Spend and Visibility; each scopes the ones after it, because Access, Governance and Spend attach to the groups Structure defines, and Visibility reports on all four while nothing depends on it.
• Four settings are costly or impossible to reverse. Domain claiming can never be turned off; changing organization topology means re-provisioning every affected member; changing a live IdP-group-to-role mapping is a second mass change, not an undo; and shortening data retention permanently loses conversations already deleted.
• Every configuration lesson uses the same three-step frame. Lessons 4 to 11 each set out "Your decision", "The choices you can make", and "If you change this later". The course is aimed at the Owner-level admin and covers judgment, not mechanics, linking to help-center articles for setup steps.
• Start from a rollout objective, not from settings. A useful objective pairs one specific company-wide ambition with the constraint that must hold. Differences between units come in later through phasing and measurement, not through separate goals per unit.
• The fictional company Pluto illustrates every decision. Pluto has five business units (Retail, B2B, Payments & Trust, Platform, Ops), and its objective is weekly active usage in every unit by quarter-end with no security escalation from the regulated Payments & Trust. When speed and that constraint conflict, Pluto takes the slower path.

2026-11-06 · open the original ↗

• AI can now transform the whole lifecycle, not just coding. That is the course's closing claim, and it says this can be done while keeping human judgment central and meeting large-enterprise governance and regulatory requirements. It presents the playbook as the practices Anthropic's Applied AI team uses with customers every day.
• Platform teams should start with the admin decision map, then layer controls. The resources are listed in roughly the order to roll them out. They begin with organization setup, the settings reference and precedence (including managed-only keys) and server-managed settings. Next come permissions, sandboxing, hooks, skills, plugins and private marketplaces, and managed MCP. The list ends with enterprise deployment (Bedrock, Vertex AI, Foundry), network configuration, OpenTelemetry monitoring and analytics, the Compliance API and the security model.

2026-11-06 · open the original ↗

• Maintenance runs autonomously, started by triggers rather than people. A control-band breach, a ticket, a channel message or a schedule invokes Claude headless. Claude diagnoses, acts only through gated routes, and writes an intent.md that moves through the earlier stages. Between stages, a confidence gate (a deterministic check or an adversarial reviewing agent) lets the work continue or escalates it to a human. People triage and review the work but no longer have to start it.
• Detection stays deterministic, and control bands set how far Claude may act. A script with no model takes the mean and σ of 30 days of hourly readings. On a bell curve, about 1 in 6 readings lands above 1σ, 1 in 44 above 2σ and 1 in 740 above 3σ. At 720 readings a month, chance alone gives about four a day, 16 a month and one a month. So 1σ only logs, 2σ runs a read-only diagnosis, and 3σ may act only by opening a PR or running a pre-approved runbook. The Western Electric drift rules (1956) count as 2σ: four of the last five readings above 1σ, or eight in a row above the mean.
• In the worked incident, the agent rolled back unprompted. Release 4f2c9e1 at 13:52 cut the status panel's cache from 60 seconds to 0, which pushed traffic past claims-core's limit of 50 requests a second. At 14:00 the 5xx rate read 1.9% against a 0.2% mean (σ 0.02). The agent ran the rollback-deploy runbook at 14:02, version 8c41d07 was live again at 14:04, and the agent wrote an intent.md citing spec requirement R4. The incident then became the eval status-panel-keeps-its-cache.
• Owners triage the findings, and dismissals tune the bands. Each finding is fixed now, scheduled or dismissed, and product-facing ones go to the product owner. The measures are the time from breach to intent.md (against the old time from incident to post-mortem action), the share of findings that become merged fixes, and repeat incidents. The same setup works for process metrics: a drift in PR cycle time produces a report for leadership.
• Claude Tag puts Claude in incident channels as a first responder. It is in public beta for Slack and joins channels under its own identity, where anyone in the channel can guide it. It checks over MCP that the metric is back at baseline and writes the post-mortem to a version-controlled lessons file. Small fixes go out as PRs, and larger work is written up as intent.md, so the loop keeps feeding itself.

2026-11-06 · open the original ↗

• Claude takes over the pipeline steps that need judgment, starting read-only. The first jobs are triaging a failed build, summarizing a flaky test or drafting the changelog with claude -p. Write steps come next (fixing lint, updating docs, addressing @claude review comments), and everything the agent writes arrives as a PR through branch protection, with no route to push to main. PR review and approval-gate hooks are prerequisites because the gates must exist before automation speeds work through them.
• Agent jobs run sandboxed, with no standing production credentials. They run in containers under a network policy with short-lived scoped tokens. Each non-interactive run acts under the agent's own identity, so the logs separate what the agent did from what the engineer who triggered it did.
• Expose deployment through a separate MCP server for each environment. An MCP allow rule names the server and tool but not the tool's arguments, so separate deploy-dev, deploy-staging and deploy-prod servers are what let an allowlist tell environments apart. Each server offers release, status (each endpoint's 5xx rate over the five minutes after the last release) and rollback. The staging job holds only the staging token, allows only its three tools and runs in dontAsk mode. It rolls back if any endpoint's 5xx rate is over 1%.
• In production the agent prepares the release and a human authorizes it. release is left off the production allowlist, so in dontAsk mode the only way through is the approval hook's allow. If the hook fails to run, the release is denied. rollback stays on the allowlist because it is a runbook approved in advance. Dev deploys freely and staging sits between the two.
• Rollback should be the most rehearsed path in the pipeline. It should be a single command the agent can run, exercised regularly in staging, because the Stage 6 loop calls it automatically when a control band is breached. The measures are the share of pipeline failures triaged without paging anyone, plus the DORA metrics.

2026-11-06 · open the original ↗

• Hooks turn the human approvals a process requires into enforced gates. A PreToolUse hook can allow, ask or block. When the approver is someone else, such as a release manager, the hook looks for their recorded approval and blocks until it exists. Engineering leadership, change management and compliance list which gates must survive, and a platform engineer writes each one as a hook. Hooks run wherever Claude acts, so they also fit earlier stages, for example blocking migrations without a change ticket.
• Non-negotiable hooks belong in managed settings that engineers can't turn off. Team hooks live in .claude/settings.json in Git. A block should explain itself and name the route to approval. The reason on a deny is shown to Claude so it can pass it on, and the reason on an ask is shown to the person.
• The example release gate gets stricter at each environment. Dev is allowed. Staging asks, or is allowed from the pipeline on main, because a non-interactive run denies any ask and the approved merge counts as approval. Production needs a CHG- ticket approved for that exact version, checked through the change system's CLI, or the release is denied. The gate depends on the agent having no way to write to the records it reads. The course admits one gap: an engineer could set GITHUB_REF by hand, though that only skips a prompt they would have answered themselves.
• Managed settings lock down the agent for a regulated enterprise. The settings are deployed by MDM or the admin console. They deny reads of .env and secrets and block WebFetch, curl and wget. They pre-approve git and the make build/test/lint commands to avoid prompt fatigue. Other keys stop anyone widening the rules, require a sandbox with a domain allowlist and credential stripping, allow only managed hooks and MCP servers, accept plugins only from an approved marketplace, and set requiredMinimumVersion to 2.1.193. Under allowManagedHooksOnly, the project-level release gate must move into the managed file.
• Permissions and the sandbox enforce the same goal at different layers. A tool-level deny on WebFetch doesn't stop a shell command reaching the network, but the OS-level domain allowlist does. permissions.deny covers Claude's file tools, while a sandboxed shell could still read ~/.ssh unless the credentials block denies it. Every deny rule removes some capability, so the right balance depends on the repo's data classification.

2026-11-06 · open the original ↗

• AI review passes leave humans to judge only intent and risk. Every PR gets the same set of review passes with findings ranked by severity, instead of quality depending on how busy the reviewer is. The managed Code Review service, enabled by an Owner of the Claude organization, is the fastest start. The claude-code-action in your own CI gives control of the pipeline and can route calls through Amazon Bedrock, Vertex AI or Microsoft Foundry.
• REVIEW.md sets the passes, the severity scale and what to skip. The passes are bugs, security, and compliance against spec.md, plan.md and design principles. "Important" is kept for findings that break behavior, leak data or breach policy. Nits are capped at five per review, and generated files under src/gen/ and anything CI already enforces are skipped. In the example, the compliance pass flags a status panel that fetches on every render, which is caught only because the pass reads plan.md and its caching requirement.
• Findings inform the decision; a code owner still approves. Branch protection requires code-owner approval, and the agent that wrote the code can't approve it, so separation of duties holds. For teams that want to gate merges on findings, the check run publishes a machine-readable count by severity.
• Claude also acts on review comments and shepherds its own PRs. Tagging @claude on a comment through the claude-code-action gets the fix pushed; in the managed service, @claude review requests a fresh review instead. A custom slash command can work through unresolved comments and failing checks until the PR is waiting only on owner approval. A mistake flagged a second time goes into CLAUDE.md. Once a month the tech lead rates findings and adjusts the nit cap.
• Time to first review should drop to minutes. The other leading indicator is the share of comments resolved without a human touching the branch. The lagging indicator is defects caught before merge compared with those that reach production.

2026-11-06 · open the original ↗

• Agent configuration needs regression testing just like code. Evals stand in for stage-gate QA. They run on a schedule and whenever CLAUDE.md, skills, hooks or the model change. Build the suite from 20 to 50 real recent tasks with accepted outcomes, each one a prompt plus the checks that define an acceptable result. Configuration changes that lower the pass rate are held for review before merging.
• Every production incident becomes a permanent eval. The team that owned the incident writes it. The suite has to keep evolving: as models improve, old cases stop telling good runs from bad, and new ones come from monitoring. The measures are pass rate over time, how long an incident takes to become an eval, and regressions caught in CI compared with those found in production.
• Isolate each run so the agent can't game the checks. The workflow checks out the eval's from commit in a scratch worktree, deletes evals/ from it, and copies in the branch's CLAUDE.md and .claude/. It grades from a copy of the checks made before any run, and fails any run that changes files outside may_change. The course warns against --bare, which skips exactly the CLAUDE.md, skills and hooks being tested.
• Checks on behavior catch what policy scripts miss. In the worked example, a PR trims CLAUDE.md and drops the line against logging request and response bodies, assuming a skill and hook already cover it. Claude then logs the whole response. check-endpoints.sh still passes because none of the fields is tagged pii, but the free-text next_step field holds a customer's name and phone number, so log_bodies.py fails (4/5 checks). The merge is blocked and the line goes back in. The course notes the check catches only whole-body logging.

2026-11-06 · open the original ↗

• Always give Claude a way to check its own work. Late signals (CI after minutes, a tester after days, production after weeks) make the person checking agent output the bottleneck. Instead the session runs the tests, the build or a screenshot and keeps going until the check passes. This loop runs throughout the task. A verifier subagent is different: it is a single final check in a fresh context.
• Make each check one command with a measurable target. Wrap verification in a single target such as make test that exits non-zero on failure, and list each command in CLAUDE.md with an example of healthy output. Targets should be concrete, such as "all tests in test_status.py pass". For UI work, give Claude a browser or screenshot tool and the mock. Two or three rounds of comparing and adjusting is normal.
• For bug fixes, commit a failing test before the fix. Claude writes a test that reproduces the bug and confirms it fails for the expected reason, and that test is committed. Only then does Claude make it pass without touching the test. The course argues that a test which existed before the fix, and which the agent couldn't rewrite, is proof the bug is gone.
• Protect the loop so the agent can't weaken its own checks. A hook blocks edits to test files during a fix task. The alternative is to reject any diff that touches a test in review. CLAUDE.md makes verification part of "done": run build, test and lint, paste the output, and "fix the code, not the test". The pasted toolchain output is the evidence attached to the PR.
• Expect first-pass CI success to rise and review time to fall. The leading indicator is first-pass CI success for agent-written changes. The lagging indicators are review time per PR and the change failure rate. Reviewers can then focus on intent and risk.

2026-11-06 · open the original ↗

• The engineer's job shifts from doing one task to orchestrating several. A parallel session is a separate Claude Code instance in its own Git worktree (e.g. claude --worktree feature-auth), and the sessions know nothing about each other. A subagent is a helper inside one session, with its own context window and tool limits, for jobs that come up again and again.
• Parallelize only independent tasks, and only as many as review allows. Use the plan to find which pieces are independent. Tasks that share files run one after another in a single session. Start with two or three sessions and add more only while review is keeping up. Tune permissions so sessions don't sit waiting on prompts for commands the organization already considers safe.
• Turn recurring jobs into subagent definitions checked into Git. Each file in .claude/agents/ gives a name, a description of when to use it, and the tools it may use. Suggested examples are a code simplifier, a verifier and a researcher. The sample verifier gets only Bash and Read: it runs make run, exercises the change and the two nearest flows, and reports anything that doesn't match plan.md without fixing it.
• More output means the controls have to live in repo configuration. Hooks and permission settings in the repo apply to every session, and each session's actions are attributed to the engineer who ran it. The measures are concurrent sessions per engineer while review quality holds (from the OpenTelemetry export), and changes merged per week read alongside the rework rate.

2026-11-06 · open the original ↗

• Skills encode institutional knowledge that must be applied consistently. They are version controlled and updated centrally when policy changes. Material that belongs in CLAUDE.md or a prompt should not become a skill. The course suggests starting with one policy that is enforced unevenly today and has a named owner and a written source. The steps: write it as a SKILL.md whose frontmatter says when it triggers, keep it in .claude/skills/<name>/ or ship it through a plugin, test that it triggers however the task is phrased, and have the policy owner sign off every change.
• Skills are advisory; policies that must always hold need hooks. The skill makes violations rare and the hook makes them close to impossible. In the example, the secure-api-review skill has four rules: gateway JWT on every endpoint, schema validation that rejects unknown fields, audit events, and pii-tagged fields never logged. Rule 4 is backed by a PostToolUse hook on Edit|Write that runs scripts/check-endpoints.sh on files in claims-api/routes/. A post-edit hook can't undo the edit, so it exits with code 2 to show its message to Claude, which then fixes the line.
• Edit hooks miss shell rewrites, so recheck at the PR. The same script runs as a required pull-request check under branch protection. Build-phase hooks should be fast and limited to the changed file. Heavier checks such as the full test suite belong at the commit or the PR.
• Human-approval hooks don't belong in the build phase. An approval prompt during the build puts a person back on the critical path of every parallel session. Those gates belong with the deploy stage.
• Review findings that cite the policy should fall toward zero. If they don't, either the skill isn't triggering or its text has drifted from the official policy. The leading indicator is the time from a policy owner approving a change to the updated skill merging.

2026-11-06 · open the original ↗

• CLAUDE.md is the new-joiner briefing Claude reads every session. It holds conventions, commands, architecture and the team's most common mistakes, knowledge that used to live in people's heads and on wikis. Start with /init, then cut the generated file down to what a new joiner would need on day one.
• Keep it under a page, because stale lines waste context. Claude reads the whole file at the start of every session. The insurer example fits in a few lines: make targets for build, test, integration test, lint and run; Python 3.12/FastAPI and TypeScript/React; ISO 8601 dates; only claims-api talks to claims-core, which allows 50 requests a second; never log request bodies (PII); never bump dependency versions.
• Repeated mistakes get written into the file. The working rule is that a correction goes into CLAUDE.md the second time Claude makes the same mistake. The file sits at the repo root, and code owners review changes to it in PRs like any other code. Success is measured by how often Claude repeats a mistake the file should have caught, and by how long a new team member takes to merge a first PR.

2026-11-06 · open the original ↗

• Engineering work starts with a reviewed plan written in plan mode. Claude reads the codebase without changing it and proposes the files to change, the order of work and the tests that prove it. The engineer presses on what could break, which step is riskiest and which options were rejected, and stops when someone who never saw the conversation could build from the plan alone. Plan mode enforces design review on its own, since Claude can't edit files until the plan is accepted.
• The committed plan.md cites the spec so each step can be traced. In the example, the plan's steps map to spec requirements R1–R4, and its risk section points to spec concern 3 (claims-core's 50 rps limit). PR review later checks the diff against plan.md. When implementation departs from the plan, plan.md is updated in the same commit, optionally enforced by a hook. The course says that with a solid plan, implementation is often a single pass.
• Auto mode becomes the default once the guardrails mature. The conditions are a tuned CLAUDE.md, skills that encode policy, hooks that block unsafe actions and a test suite Claude can run. It is meant for routine work with a tight spec, a small blast radius and existing test coverage. The engineer's role shifts from watching each edit to reviewing artifacts after longer autonomous sessions, which also allows parallel work across worktrees.
• Each artifact needs one named source of truth alongside legacy tools. Jira, requirements tools, Figma and change boards are hard to replace because auditors and other teams already rely on them. The course offers three setups. The repo can be the record, or the legacy system can be, with Claude reading it and writing back over MCP. The minimum is linkage, where artifacts carry record IDs and records carry commit SHAs, which it recommends as a starting point.

2026-11-06 · open the original ↗

• Requirements and design merge into one agent session. Claude turns the approved intent.md into a spec.md constrained by the organization's brand, security, compliance and UX skills. The product owner reviews the spec but doesn't write it. The course calls the old split between analyst and designer phases slow and lossy.
• The prompt must demand flagged concerns, especially clashes between policies. In the insurer claims-status example, the spec numbers requirements R1–R4 (four states, three fields only, at most 60 seconds stale) and flags three concerns. Loss adjusters have no portal account, so giving them access would break "existing authentication only" (owner: security). The portal-ux and brand-voice skills conflict on showing dates, with "Estimated date" proposed as the label (owner: compliance). The claims-core limit of 50 requests a second hasn't been load tested against the cache (owner: claims-core team).
• Automate the spec pass in stages until it fires itself. At the last step, accepting an intent.md fires a non-interactive job that commits spec.md as a pull request, so the product owner's first involvement is the review. Flagged concerns are settled with their policy owners before engineering sees the spec. A human decides whether the work goes to build, with a tech lead consulted for anything classed as higher risk.
• Policy gets applied while the spec is written, not found weeks later. The spec, the prompt that produced it and the skill versions in force are all logged in version control. Speed is measured as the gap between the intent.md and spec.md commits. Rework is measured as the number of spec.md commits made after the first plan.md.

2026-11-06 · open the original ↗

• The person with the idea writes the proto-spec, not a product intermediary. Traditionally an idea passes through backlog entries, user stories and refinement meetings, and ownership changes hands at each step. Here the originator brainstorms with Claude, which asks what an analyst would ask (scope, users, constraints, what success looks like), and the result is written as intent.md from the organization's template, which can be encoded as a skill.
• Intent lives in version control next to the code. The simplest home is an intent/ folder in the product repo. A separate intent repo is only worth it when intent spans many repositories. A technical team member sets up the home and its write access once, and after that non-engineers commit through a version-control connector (e.g. GitHub) from claude.ai or Cowork without touching Git.
• A product owner reviews every intent.md before it is committed. This applies whether the intent came from a person, a ticket or an alert. The merge or the closed review records the accept or reject decision, and the Git history holds the author, timestamp and revisions as governance evidence.
• Measure time to a committed intent and how many survive. The course expects time from first conversation to committed intent.md to drop from a multi-week elicitation cycle to hours. The lagging indicators are the share of intents the product owner accepts into design, and the number of intent.md edits made after the first spec.md commit.

2026-11-06 · open the original ↗

• AI has sped up coding, but the surrounding process hasn't. The course treats the SDLC as six stages (plan, design, build, test, deploy, maintain) and sets traditional practice against an AI-native version at each one. It says most organizations sit somewhere between the two.
• Each stage's output becomes a versioned, machine-readable artifact. In the AI-native version, planning produces an intent.md, requirements and design happen in one agent session guided by skills, build knowledge lives in CLAUDE.md and skills, testing becomes continuous evals, deployment uses layers of agentic review with hooks as approval gates, and production breaches get written back as new intent.md files. Humans stay accountable for every decision that needs judgment, and human review is kept for regulated and critical code.
• The plays are modular, ordered only by their dependencies. Each play covers what changes, getting started, steps, governance and measurement. Six have no prerequisites (capture intent, plan mode, CLAUDE.md, skills, feedback loop, hooks). Later plays depend on earlier ones: CI/CD needs PR review and hooks, and closing the loop needs CI/CD and capture intent.

2026-11-06 · open the original ↗

• A personal fluency plan starts with self-assessment against the 4Ds. Learners rate each competency as novice, developing or confident, note which of automation, augmentation and agency they use well or poorly, and pick one or two competencies to work on. They then set activities, a practice schedule and signs of progress, using Claude as a thinking partner.
• A prompt and pattern library turns recurring tasks into templates. Learners pick 5–10 regular AI tasks and write a template prompt with placeholders for each. They also record which Description techniques and Discernment checks work, keep examples of good outputs, and set a way to update the library.
• Puzzles are offered as practice in steering an AI's thinking. Puzzles have precise rules and are deliberately tricky, which makes them good for practicing exact Description and for Discernment. Suggested formats are riddle swaps (have Claude explain its reasoning and nudge it rather than reveal the answer), cooperative crosswords ("Remember, it's only 5 letters"), and finding links among 12–20 random words. Other options are Twenty Questions, alternating storytelling, role-playing games, tight-constraint explanations, and Project Euler problems for programmers.

2026-11-06 · open the original ↗

• Human expertise and judgment remain the foundation of delegation. Rick Dakan says the strongest outcomes come where human and AI build on each other's strengths through iterative collaboration, producing results neither could reach alone.
• The best instructions are often conversations rather than elaborate prompts. Clear description bridges intention and capability through context, examples and feedback, across its product, process and performance dimensions.
• Critically evaluating AI output is described as non-negotiable. Discernment of products, processes and interactions is presented as the user's protection against AI's limitations.
• You remain accountable for AI-assisted work and its effects. Diligence spans choosing systems carefully, being transparent about AI's role (which builds trust), and taking responsibility for the final product.
• Fluency grows through practice, and AI is no silver bullet. The competencies "aren't mastered overnight", and the goal is continuing awareness rather than perfection. The systems are "only as useful and safe as we enable them to be." The framework is meant to apply across AI assistants and stay relevant as they evolve.

2026-11-06 · open the original ↗

• Diligence covers the ethics and safety the other three neglect. Delegation, Description and Discernment mainly serve effectiveness and efficiency. Diligence asks who could be affected by the work or by missed inaccuracies, and who has access to the data. The lesson's analogy is driving, where safety and other road users matter as well as arriving.
• Creation diligence means scrutinizing which systems you use and how. The questions are how the system was trained, who owns and can see what you input, how privacy is protected, and whether the use fits your values and your organization's policies. Example: check the data-protection terms and your employer's rules before pasting in sensitive company information.
• Transparency diligence means telling everyone who needs to know. Disclosure expectations differ across personal, academic, creative and professional settings, and the lesson puts the onus on each user to learn and meet them. It frames this as trust rather than rule-following: people have a right to know when AI played a significant role in work or decisions that affect them.
• Deployment diligence makes you, not the AI, responsible for output. Before sharing, you verify facts, check for bias, and confirm accuracy and usage rights. A journalist drafting with AI must meet the same standards as if they had written the piece alone.
• Standards are still unsettled, so build personal guidelines and stay informed. The lesson notes that legal and regulatory frameworks for AI are still emerging. Its exercise has learners write a diligence statement naming the AI systems used, what they contributed, the review process, and the author's acceptance of responsibility.

2026-11-06 · open the original ↗

• Set the terms of the collaboration before executing. The learner reviews the earlier delegation plan, revising it if needed, then agrees with Claude in advance on outputs (format, style, length, detail), method, and collaborative behavior, such as concise or detailed, challenging or supportive.
• Each task runs through repeated describe-discern-refine cycles. The learner describes the product, process and performance wanted; judges the output, the approach and Claude's behavior on the same three axes; then gives feedback, adjusts the description and asks for further iterations.
• The human makes the final calls and owns the result. The learner adds their own perspective and domain knowledge, decides what to keep, change or discard, and takes responsibility for the final output.

2026-11-06 · open the original ↗

• Discernment is the evaluating flip side of Description. It requires both enough domain expertise to judge quality and an understanding of how AI typically fails. The lesson calls it an essential safeguard because even the most advanced systems make reasoning errors, factual mistakes and unexpected moves.
• Product discernment judges whether the output itself holds up. The questions are whether it is accurate, suits the audience and purpose, is coherent and well structured, meets the requirements, and actually solves the problem.
• Process discernment watches how the AI reached its output. Warning signs include logical errors, lapses of attention, inappropriate steps, fixation on one interpretation, and circular reasoning. In the lesson's example, ideas rejected in earlier rounds quietly reappear. This matters most on complex tasks where the right answer isn't obvious.
• Performance discernment judges the interaction rather than the work. The lesson separates process (the work the AI does) from performance (how well it works with you). For example, is it asking too many questions when you need concise answers, or too brief when you need depth, and does it respond to feedback?
• A flagged problem usually calls for better description, sometimes for re-delegation. Good feedback names the problem, explains why it is one, offers concrete fixes, and revises the instructions or examples. Sometimes the real issue is the wrong tool or the wrong approach, which sends you back to Delegation.

2026-11-06 · open the original ↗

• Give context about what you want, why, and who you are. "Tell me about climate change" becomes a request for three impacts on tropical agriculture with examples from the past decade. Adding that the asker has an ecology degree and an interview at an agricultural research lab in Indonesia tailors the answer further. The lesson notes that people supply this background naturally to humans but forget it with AI.
• Examples and explicit constraints pin down hard-to-describe outputs. Few-shot (or "n-shot") prompting shows the pattern, as with two jargon-to-plain-language pairs. The lesson advises trying without examples first and, when using them, covering varied cases. Constraints are shown in a portfolio-site spec: named sections, a sticky responsive menu, a sunset palette and a dark/light toggle.
• Thinking only improves the answer if it comes first. Breaking a task into steps (chain-of-thought) lets you impose your own process, as in a quarterly sales analysis, and matters more the more the task depends on domain expertise. Asking the model to think before answering, rather than explain afterwards, improves quality and shows where it goes astray. Reasoning models now do much of this by default.
• Assigning a role or tone shapes both interaction and result. Examples include a science teacher explaining rainbows to a bright 10-year-old, a Richard Feynman persona for physics, and a UX expert reviewing a wireframe.
• Ask the AI to improve your prompt, then iterate. This is called the "secret weapon", and the lesson says models vary most here. When results miss, it suggests adding specificity, asking for three versions or a different format, asking how confident the model is, or starting a fresh conversation. Mistakes to avoid are assuming the model reads minds, loading one prompt with unrelated tasks, leaving success vague, and not giving feedback.

2026-11-06 · open the original ↗

• Description is broader than writing clever prompts. It covers explaining tasks, asking questions, giving context, steering a conversation that is going wrong, and guiding the AI's reasoning. The lesson calls this building a thinking environment where both sides do their best work.
• Output quality depends on spelling out exactly what you want. "AI can't read your mind." The lesson compares asking someone to make dinner with handing them a recipe. Product description sets out the context, the task, the format, the audience and the style.
• How the AI works can matter as much as the goal. Process description can take the form of general guidance (like a manual), step-by-step instructions (like a cookbook), or worked examples. It specifies which data to use, which issues to cover and in what order, and the style of analysis or workflow wanted.
• AI tools are interactive systems, not databases or vending machines. The lesson calls this the one thing to take from the course. Performance description sets how the AI should behave: exploring or narrowing, challenging assumptions or following your lead, detailed or concise, explaining its answers or just giving them.

2026-11-06 · open the original ↗

• The course project should be multi-step but roughly an hour's work. It must involve several types of task and be something the learner actually wants to do. The lesson suggests communication, research, creative and learning projects, such as a presentation, a product comparison, a short-story outline or a study plan.
• Use Claude to sharpen the vision before splitting the work. The learner shares the idea and invites Claude to ask questions until it is clear what success looks like and what would make the project meaningful.
• Delegation is decided task by task, through real back-and-forth. For each major task, the learner and Claude discuss the skills and knowledge needed, which parts call for human strengths, which suit AI, and where collaboration would help most. They are told to challenge assumptions rather than trade statements, and to save the plan for the later Description, Discernment and Diligence exercises.

2026-11-06 · open the original ↗

• Good delegation rests on your own expertise, not on AI. "Problem awareness" means defining the goal and what success looks like, and sorting the work into types: simple but time-consuming, uncertain (where a thinking partner helps), ignorance (where more data is needed), and critical judgment. The lesson's line is that the best collaborators "are experts in their fields first and AI delegators second."
• Platform awareness comes from hands-on comparison of AI systems. No single system is ideal. They differ on trade-offs such as speed versus depth and accuracy versus creativity, and the landscape changes almost daily, so the lesson recommends experimenting often and building first-hand judgment.
• Task delegation assigns each piece of work to a mode. Each part goes to automation, human-AI collaboration, human-only work, or AI agents acting on your behalf, and some critical judgment should not be delegated at all. The lesson frames delegation as serving effectiveness and efficiency, not as "handing over the wheel and calling it a day."

2026-11-06 · open the original ↗

• LLMs switch across language tasks without retraining. The same system drafts emails in your voice, summarizes reports, translates, and explains subjects from microbiology to marketing. It also holds the thread of a conversation, and connections to web search, files and other applications extend what it can reach.
• Knowledge stops at a training cutoff, and training doesn't verify facts. A model with a November 2024 cutoff has no innate knowledge of later events, like someone on a retreat without internet. Because it generates from statistical patterns rather than retrieving documents, it can repeat errors from its training data or invent plausible but false claims, known as hallucinations.
• Context limits and non-determinism undercut consistency. Information beyond the context window is dropped, usually first-in, first-out, which limits work on long documents and conversations. The same question can get different answers; that variability helps brainstorming, but when consistency matters some interfaces expose a "temperature" setting to control it.
• Multi-step reasoning and missing data access remain constraints. Models have historically struggled with multi-step math and logic, though newer reasoning or extended-thinking models are described as making strong progress. A model without access to a needed data source or tool can't answer, "like a brilliant colleague who can't access your company's internal database."
• The best uses combine human and AI strengths. Humans supply critical thinking, judgment, creativity and ethical oversight, and AI supplies speed, scale, pattern recognition and volume. The lesson predicts that retrieval-augmented generation, tool use and better reasoning will reduce some limits, while some will likely remain for the foreseeable future.

2026-11-06 · open the original ↗

• Generative AI creates new content rather than classifying existing data. Drew Bent (Anthropic) contrasts traditional AI sorting email into spam or not with generative AI writing a new email. LLMs are "large" because they hold billions of parameters, which he likens loosely to synaptic connections.
• Three developments converged to make modern LLMs possible. These were the transformer architecture of 2017, which keeps relationships between words across long passages; the explosion of digital text used as training data; and large increases in compute from GPUs, TPUs and distributed clusters.
• Scale improved performance predictably and produced capabilities nobody programmed. The scaling laws are described as empirical findings that bigger models trained on more data with more compute improve in predictable ways. Emergent abilities, such as step-by-step reasoning and adapting to new tasks with minimal instruction, appeared with size and sometimes surprised the models' creators.
• Models learn by predicting text, then are fine-tuned for behavior. Pre-training on billions of examples builds a statistical "map" of language and knowledge. Fine-tuning then teaches instruction-following and harm avoidance, using human feedback and reinforcement learning; for Anthropic's models the target is helpful, honest and harmless.
• Responses are generated rather than retrieved, within a finite context window. The model continues your prompt from learned patterns rather than pulling pre-written answers from a database. The context window is its working memory of prompts, replies and shared material, and anything outside it is unavailable without tools such as web search. In-context learning lets the model adapt to a new task from instructions or examples alone.

2026-11-06 · open the original ↗

• Delegation starts from a clear goal, not from the tool. Rick Dakan's three steps are to understand the goal, know what AI can and can't do, and divide the work deliberately. In his research example, AI reviews documents and data and discusses the findings, while the critical analysis and final conclusions stay with the human.
• Description is context-rich conversation, not just prompt writing. He contrasts "make me a logo" with a brief covering company values, audience, colors and style references, and gives a tutoring instruction: "don't tell me the answer." Description covers the goal and output format, the approach, the context needed, and the tone of the interaction.
• Discernment applies your own domain expertise to judging output. For an AI-suggested marketing strategy, ask whether the facts are accurate, the reasoning holds, the recommendations fit the brand, and the output actually moves you forward. Most interactions are small loops of describing, evaluating and refining.
• Diligence means owning AI-assisted work and standing behind it. Using AI to write job descriptions or review applications, for example, raises fairness and bias controls, verification, protection of sensitive data, transparency about AI's involvement, and accountability for the result.
• The competencies claim durability because they are tool-independent. They apply across automation, augmentation and agency, and are presented as fundamentals that won't date the way specific tools and techniques do.

2026-11-06 · open the original ↗

• Having access to AI is not the same as being fluent. The lesson points to familiar gaps: an unexpected response you don't know how to handle, struggling to explain what you need, or not knowing whether the information you share is protected.
• Fluency is a set of skills, knowledge, insights and values. The lesson says it is not technical expertise or memorizing "the 10 best prompts", and that these elements reinforce each other and adapt as the technology changes. It glosses the four criteria as getting the most out of AI without wasting time, honestly, and while protecting your own and others' privacy and security.
• Automation fits tasks whose outcome you can already define. The AI executes a specific instruction, such as summarizing a document, drafting an email or planning an itinerary. The lesson says this gets harder when you aren't yet sure what you're looking for.
• Augmentation makes AI a partner for open-ended thinking. Examples include developing a stuck story character, working through an app's architecture, or forming views on a research topic. The AI "doesn't do work for you, but helps you do your work better", which suits problems that need room to explore.
• Agency means configuring AI's knowledge and behavior to act independently. Examples include triaging and drafting replies to email, a dynamic website experience, or a game character. The user becomes "less like a script writer… more like a director setting a vision." No mode is inherently better, but the presenters' view is that augmentation and agency make best use of AI's distinctive capabilities.

2026-11-06 · open the original ↗

• The course is about human-AI collaboration, not the technology. The presenters are Joe Feller (Cork University Business School), Drew Bent and Maggie Vo (Anthropic) and Rick Dakan (Ringling College of Art and Design). They frame AI as a trusted partner for creative problem-solving rather than "some sort of next level spell checker."
• AI Fluency is engaging with AI effectively, efficiently, ethically and safely. The course offers this as a lasting framework rather than tactical prompting tips or settings that "may be outdated next month." Its stated aim is to change how people think about AI so they can learn to think with it.
• Adoption is outrunning understanding, and the course targets that gap. The presenters report organizations adopting AI without clear strategies and people frustrated by systems they don't fully understand. They describe a widening gap between what is possible and what feels comfortable and intuitive.
• The framework rests on four competencies, the "4Ds". Delegation asks when humans should do the work and when AI should. Description asks how to communicate clearly, Discernment how to evaluate what AI returns, and Diligence how to keep the interaction responsible, transparent and accountable. Each gets videos paired with hands-on exercises.

2026-11-06 · open the original ↗

• Claude Code can write the API integration from a stub. The demo is a TypeScript weather file with two stubs, getWeather and a run function meant to use the tool runner. From one prompt, Claude Code filled both in against the types (including a Zod tool), added a call at the end, ran the script, reported the output and fixed errors in place.
• A built-in Claude API skill supplies the SDK knowledge. Claude Code invokes it automatically when it detects the TypeScript SDK, or you can call it with /claude-api.
• A good prompt names the file, pattern and end state. The lesson gives these as the three things that let a single prompt produce working code: which file to change, which pattern to use (here, the tool runner), and what the result should be.
• Most Claude API code has one shape: tool, runner, result. So the lesson recommends not typing it from memory each time, but stubbing the file, handing it to Claude Code and reviewing the diff.

2026-11-06 · open the original ↗

• Delegate the loop when it runs long or must survive interruptions. The lesson says a hand-written loop is often right, but runs of minutes or hours with many tools, state, files and recovery after network drops belong on Anthropic's infrastructure. Managed agents are on by default for every API account.
• Four primitives, in order: agent, environment, session, events. The agent (model, system prompt, toolset) is reusable; the environment is the sandbox (cloud or self-hosted, networking); the session is one run, "the unit of work"; events carry everything in and out. You don't write a while loop; you send and read events.
• Limited networking reaches only listed hosts. The demo creates an agent with the bundled agent_toolset_20260401 (file, bash and web tools), a cloud environment with limited networking and no allowed_hosts, and a session. The lesson advises unrestricted only when the agent must reach sites you can't list ahead of time. Each session gets its own sandbox.
• Open the event stream before sending the kickoff message. The stream only delivers events that happen after it opens. The events to watch are agent.message, agent.tool_use and session.status_idle. On idle, check stop_reason.type: end_turn means the turn finished or was interrupted, and requires_action means a tool call is waiting on you.
• Server-side event history makes sessions resumable. After a dropped connection, you open a new stream, list past events and skip live ones already seen. The lesson's production example is a file-share cleanup that sorts thousands of files into project folders, archives duplicates and zero-byte files, and flags anything it can't place.

2026-11-06 · open the original ↗

• Managed Agents hosts the agent loop on Anthropic's infrastructure. You define agents (tools, personas, capabilities) and sandbox environments (packages, network controls), then start sessions from your own app. Claude works in an isolated container with full filesystem access, bash and web search.
• Rubrics and a separate grader drive Claude toward a defined "done." In the Kanban example, dragging an "optimize website performance" ticket starts a session in an environment with Lighthouse and Puppeteer and the GitHub repo mounted. The rubric is a Lighthouse score above 90, no render-blocking resources and all images lazy-loaded. A grader in its own context window scores the work, Claude fixes what it missed, and the demo reached 96. A second ticket runs in parallel in its own container.
• A memory store lets recurring agents report changes since last time. The weekly SaaS-pricing agent checks last week's findings, searches pricing pages, runs a cost analysis in Python, uses an Excel skill for the report and posts to Slack and Asana through MCP. That lets it say, for example, "compute costs are 15% lower since last week."
• Multi-agent coordination with permission gates handles incident response. An alert payload starts a session in which a coordinator delegates to three specialists, each with its own context window over a shared filesystem, then combines their findings. A permission policy holds the Slack summary until a human approves. Memory matched the incident to a DNS issue two weeks earlier caused by a misconfigured TTL.
• The building blocks are agents, sessions, environments and five more. The rest are tools (including custom back-end tools), MCP, memory, outcomes (rubrics and graders) and multi-agent coordination. Sessions stream every tool call back to your app in real time.

2026-11-06 · open the original ↗

• Context is finite and costly, so include only the right things. Context covers the system prompt, message history, tool definitions and results, attached files and skills, and thinking blocks. You pay for it on every call, and the lesson says a million-token window runs out quickly in a real agent, after which requests fail.
• Just-in-time context: load only what's needed, pull the rest. This is the one design pattern of the four, not an API feature. The compliance agent calls lookup_building_code for a section instead of putting the whole code book in its system prompt.
• Server-side compaction summarizes old turns automatically. You opt in with a context_management key holding a compact_20260112 edit, under the compact-2026-01-12 beta. The API summarizes once input crosses a trigger threshold, so you don't track conversation length yourself.
• Prompt caching reuses stable request parts at a fraction of cost. Cache the system prompt, tool definitions or a long document. The lesson's example: with a 4,000-token system prompt called 100 times an hour, caching separates "a usable bill" from "a phone call from finance."
• The memory tool carries context across sessions; you own storage. Claude reads and writes a memory directory through tool calls, you provide the backend (filesystem, database, encrypted store), and Anthropic injects an instruction to check memory first. The lesson says each pattern fixes a different failure (cost, window size, statelessness), production apps usually layer them, and managed agents ship with caching and compaction on by default.

2026-11-06 · open the original ↗

• MCP's point is who maintains the integration code. With custom tools, an agent using Asana, Google Calendar and Slack means writing three wrappers and updating them whenever those APIs change. With MCP, each provider publishes a server with tools, schemas and auth over a standard protocol, and updates it themselves.
• Use tools for your systems, Skills for processes, MCP for others'. Tools connect to internal systems whose code you own and maintain; Skills teach a procedure; MCP connects third-party services maintained by the provider. The lesson's phrasing: "MCP is for everyone else's stuff."
• Claude discovers an MCP server's tools without schemas from you. A request declares the connection in mcp_servers (type, URL, name, optional auth token) and grants access with an mcp_toolset entry in tools. Claude introspects the server, here Linear at https://mcp.linear.app/mcp, lists its tools and picks one. The connector is in beta and needs the mcp-client-2025-11-20 header.
• Restrict servers to the tools you need, such as read-only. Setting default_config: {"enabled": False} and enabling only named tools in configs lets Claude run search_messages and list_channels on Slack but not post or delete. It also keeps unused tool definitions out of context.

2026-11-06 · open the original ↗

• Skills teach Claude how you want a task done. A Skill is a folder of instructions, scripts and resources built around a SKILL.md file, such as a status-report format, review checklist or release-notes style. The lesson's contrast: tools are about what Claude can do, Skills about how you want it done.
• Skills load progressively, keeping context lean. Only each Skill's name and description load at startup, and the full Skill loads when the agent decides it is relevant, so many Skills can be available at low context cost.
• Upload a Skill once, then reference it by ID. You upload in the Claude Platform or with client.skills.create (display_name, files from a folder containing SKILL.md), and attach it through a container.skills list entry with type: "custom", the skill_id and a version such as "latest". Because it is a list, several Skills can be layered on one call.
• Skills are GA but need the code execution tool. No beta header is needed now; the old skills-2025-10-02 header still works. On the API, Skills run inside the code execution tool's container, which is what lets them run bundled scripts.
• Skills standardize output across a whole feature. In the daily status report demo, the user prompt is one line plus the activity log, and the Skill supplies the sections, tone and blocker handling, so every PM gets the same structure without pasting a template into a prompt.

2026-11-06 · open the original ↗

• Server tools are declared by you and run by Anthropic. Web search (results with citations), code execution (Python in a sandbox) and web fetch (full URL content) run on Anthropic's infrastructure, so you write no tool code and host no sandbox.
• Server tools need no agent loop. Results arrive in the same response, so there is no stop_reason switch and nothing to push back. Code just reads the new block types: server_tool_use, a code execution result block such as bash_code_execution_tool_result with its stdout, and ordinary text. The demo declares web_search_20260209 and code_execution_20260120 in two calls.
• Client tools have built-in schemas but run on your side. Anthropic publishes the schemas and trains Claude on them, so you don't define them, but your code executes them. Memory reads and writes across sessions, with a helper in four of the SDKs that works against storage you provide; bash gives a persistent shell that your application runs.
• Built-in tools turn weeks of work into a declaration. The example is a fact-check endpoint that checks every numeric and regulatory claim in a draft proposal against the live web. The lesson adds that a claim backed by the web is not necessarily true, so Claude's work still needs checking.
• Managed agents host the whole agent, not one tool. The lesson presents them as the same "hosted by Anthropic" idea taken all the way up.

2026-11-06 · open the original ↗

• Extended thinking prevents confident wrong answers on multi-step problems. Claude produces internal reasoning tokens before its final answer; the opening example shows an instant reply wrongly giving "6.5 apples" on a multi-step question.
• On Opus 5, thinking is adaptive and on by default. There is no token budget to set, because Claude decides when to think and how much. The reasoning stays hidden unless the request sets "display": "summarized", which returns a summary alongside the answer.
• Effort controls thinking depth and goes inside output_config. The lesson flags this placement, not next to the thinking block, as a gotcha. The levels are low, medium, high (the default), xhigh and max.
• Use thinking for trade-offs; skip it for simple tasks. It helps with math, multi-step logic, debugging, regulatory analysis and comparing options. For classification, extraction or boilerplate it only adds latency and cost. The road-trip demo (two stops out of San Francisco, weighing weather against drive time) returns thinking blocks, then tool calls, then the recommendation.
• Thinking lets an agent connect problems instead of finding them singly. With adaptive thinking turned on, the compliance review agent can catch a wind-load spec in section three that conflicts with a material spec elsewhere in the report.

2026-11-06 · open the original ↗

• Claude requests tool calls; your code runs them. A tool is a function you define and expose; Claude decides when to call it, and the result goes back to Claude as a tool_result block in a user message, tied to the call's id, after a stop_reason: "tool_use" response.
• Vague tool descriptions are the main reason agents misfire. A tool is a JSON schema with a name, a description and an input schema, sent in a tools array, and the description is what Claude reads when deciding whether to call it.
• With several tools, Claude picks from their descriptions. In a Denver packing demo with get_weather and get_forecast, Claude matched "today" and "the next few days" to the right tools, sometimes in one turn and sometimes in sequence. A tool is added by extending the array and adding a case to the runTool switch.
• The SDK tool runner removes the loop and handwritten schemas. It is in beta across the TypeScript, Python, Ruby, C#, Go, Java and PHP SDKs. In TypeScript, betaZodTool() (Zod 3.25.0 or later) defines each tool once with a Zod schema that also validates Claude's input, and awaiting client.beta.messages.toolRunner returns the final message.
• Real tools are thin wrappers around functions you already have. The compliance agent wraps existing lookup_building_code and search_building_code functions and cites specific code sections in each finding. The lesson places this on a spectrum from running the loop yourself, to delegating it to the runner, to delegating the whole agent with managed agents.

2026-11-06 · open the original ↗

• An agent is Claude running both sides of the loop. It takes a task, picks a tool and keeps acting until it decides the task is done; the lesson describes this as "observe, decide, act, repeat," with no human in between.
• The basic loop repeats until stop_reason is end_turn. You send messages with tools, Claude answers or requests a tool, your code runs the tool, and you send back the assistant turn plus a tool_result tied to the tool_use_id.
• The weather demo takes two API calls and one tool run. Asked what to wear in Austin, Claude stops with tool_use to call a mock get_weather (95F, sunny), then stops with end_turn and recommends light, breathable clothing. The lesson says everything you build on the API will look similar.
• You own the loop and tools; Claude owns the reasoning. A production compliance agent uses the same loop and changes only the plumbing: real building-code lookup tools, server-sent events streaming to the UI, and findings saved to a risk-finding table, across dozens of tool calls.
• Managed agents run the same loop for you. The lesson offers this as the alternative when you don't want to own the loop, running on Anthropic's infrastructure.

2026-11-06 · open the original ↗

• Each of the four tiers trades capability against cost and speed. Fable (claude-fable-5-1, generally available since September 1, 2026) sits above Opus at higher cost; Opus (claude-opus-5-5) is for deep reasoning and complex coding; Sonnet (claude-sonnet-5) is the balanced default for most production work; Haiku (claude-haiku-4-5) is for high-volume classification, extraction and routing. The lesson notes its video and tier graphic predate Fable 5.1 and were recorded on Opus 4.7 and Sonnet 4.6.
• Choose the model with a small eval before writing production code. The lesson says 20 or 30 representative examples from your real workload, scored against what good output means for you, is enough to start.
• Start with Haiku and move up only when quality fails. The rule: "the right model is the cheapest one whose output you'd actually ship." In a side-by-side demo of one prompt across three tiers, Opus was slowest and most polished, which was wasted on a two-sentence definition, while Haiku often answered in under a second; a regulatory response would probably end up on Opus.
• response.usage returns the token counts you are billed on. The comparison loop changes only the model field and prints input and output tokens for each call.
• In production, route each task to its own model. The example is a document-processing route on an operations dashboard: Haiku classifies every incoming file, Sonnet drafts client updates, and only RFP responses go to Opus, all in one queue.

2026-11-06 · open the original ↗

• Keep the API key in an environment file, not source. The key comes from platform.claude.com and needs credit on the Console's Billing page first; it goes in .env.local, because hardcoded keys are how they leak on GitHub. The TypeScript SDK installs with npm install @anthropic-ai/sdk.
• Every call is messages.create with three required parts. You pass a model, a max_tokens cap and a list of messages with user or assistant roles; the example uses claude-sonnet-5 with 2048 max tokens.
• The system prompt sets the persona. In the roughly 20-line code-review demo, "You are a terse senior code reviewer. Give feedback in one paragraph" is enough for Claude to report in one paragraph that add returns a - b.
• Response content is an array of blocks, never a plain string. A plain reply is usually one text block, but text, tool calls and thinking can all come back, so code should loop over the blocks and check each one's type.
• The same call shape drives real product endpoints. A summarize endpoint pulls a meeting transcript from the database, sends it with an "extract insights and risks" system prompt, saves the result to the row and returns it to the UI; the lesson says everything later in the course builds on this pattern.

2026-11-06 · open the original ↗

• The platform is programmatic access to Claude, not a chat window. Requests and responses are structured, and your code controls the model, token spend, tools and system instructions; it comes as a REST API, SDKs, CLIs and a console for API keys, usage, managed agents and prompt testing.
• Picture it as three stacked layers: primitives, infrastructure, controls. Primitives are what your code calls (Messages API, tool use, files, web search, code execution, MCP servers, skills); infrastructure is managed agents, retries, queues and observability for scaling past a prototype; controls are dashboards and evals for production. The lesson's shorthand: "build with primitives, scale on infrastructure, run with control."
• One messages.create call can add Claude to an existing feature. The worked example drafts help desk replies from a ticket behind a UI button, using Haiku because drafting is a simple task, max_tokens 1024, the team's tone guidelines in system, and the ticket text as the user message.
• The aim is making Claude part of your product. The lesson stresses that the example adds Claude to an existing app rather than building a chatbot, and says that once a product needs agents, managed agents will run them for you.

2026-11-06 · open the original ↗

• The course reduces to a few core practices. The recap lists them as prompting with context, action and rules; treating first responses as starting points; the four AI Fluency competencies (Delegation, Description, Discernment, Diligence); organizing work with projects, artifacts and skills; and extending reach with connectors, Enterprise Search and Research.
• Start with one recurring task this week and iterate. The lesson suggests drafting an email, summarizing meeting notes or analyzing a spreadsheet, then learning what works for the specific need.
• Claude is framed as a collaborator, not a replacement. The lesson argues the best results come when the user brings their own expertise, context and judgment, and points to follow-on courses including Claude Code in Action, Introduction to Claude Cowork and AI Capabilities and Limitations.

2026-11-06 · open the original ↗

• Claude is one intelligence delivered into the tools where work happens. Claude Code works in the terminal, IDE, browser or Slack to write code, run tests and create commits; Claude Tag brings Claude into Slack threads and can spin up a Claude Code session straight from a bug report or feature discussion.
• Claude Design turns briefs, sketches or screenshots into editable prototypes. It works in any conversation and at claude.ai/design, can use a team's design system so the handoff matches what engineering builds, and is available on every plan including Free, with admin controls on Team and Enterprise.
• Claude for Excel works inside the model rather than around it. In the video's inherited HR headcount plan, Claude explained the tab flow (assumptions feeding headcount, compensation, then summary), traced and fixed a #REF! error in E15 so the fix cascaded, raised attrition from 10% to 15% and walked through what recalculated, built a pivot table and stacked bar chart, and added a fully loaded cost column using formulas that reference the assumptions tab rather than pasted numbers.
• The PowerPoint, Word and Outlook sidebars edit documents in place. PowerPoint keeps the existing template and brand styling, Word works through tracked changes and comments and can ground drafts in connected sources, and Outlook is in beta and installed separately from the other Microsoft 365 add-ins.
• Claude in Chrome acts in the browser under deliberate restrictions. It is on paid plans only; admins can switch it off or limit sites, Anthropic recommends it for low-risk tasks on trusted sites, it asks before high-risk actions such as purchases, and financial-services and adult sites are blocked by default. The video adds granular action permissions and prompt-injection protections.

2026-11-06 · open the original ↗

• Claude's use cases span every function, each with a step-by-step guide. The lesson is a pointer list into the Use Case Gallery: status reports, feedback analysis and a brand-guidelines skill for anyone; battle cards, deal prep and sales reports for sales; campaign analysis and cross-platform content for marketing; financial models, investment memos and inherited spreadsheets for finance; onboarding guides for HR; discovery timelines for legal; and literature-review planning and verifying statistics from raw data for research.

2026-11-06 · open the original ↗

• Research turns Claude into an agentic, multi-search investigator. Claude plans with Thinking, runs many searches that build on each other (sometimes across hundreds of sources), synthesizes the web with connected integrations, and cites every claim; a run takes a few minutes or more, needs web search enabled, and is on paid plans only.
• Route a question by what answering it requires, not its stakes. Multi-source comparison goes to Research; a single fact, such as a competitor's stock price even for an investor update, goes to web search; pure reasoning like a SQL duplicate-rows bug goes to Thinking; company policy goes to enterprise search.
• Scope the prompt to the decision, not the topic. The lesson's example: asking about the payroll market yields an industry overview, while "payroll providers that could serve our 200-person company" judged on pricing, implementation time and support quality aims the report at the actual choice. Specifying sections and constraints like budget or geography also steers it.
• Constrain sources and timeframe instead of adding breadth. Telling Research to prioritize vendor pricing pages and reviews from the last twelve months beats adding company history and leadership, which the lesson says dilutes the report: "More sections isn't more signal."
• Connected tools let Research mix internal context with the web. Examples include summarizing Project X across email and Slack then researching best practices, or researching each company on next week's calendar.

2026-11-06 · open the original ↗

• Enterprise Search is a pre-built org-wide project for finding internal knowledge. It appears as "Ask {Org Name}" in the sidebar on Team and Enterprise plans, uses custom instructions configured by Anthropic, searches sources such as SharePoint, Slack, Gmail and Google Drive, and cites what it draws on.
• It suits questions that span many internal sources. The lesson's examples cover catching up ("What happened yesterday while I was out?"), policy and process, competitive reasons customers cite, onboarding to systems and people, and recapping leadership decisions.
• Setup takes an Owner first, then each user authenticates. The Owner must connect a Documents source (Drive or SharePoint) and a Chat source (Slack or Teams), with email optional, and names the project; users then sign in to each service, and more connectors give more complete results.
• It only surfaces what the user can already access. The lesson states that conversations stay private and connected data is not indexed or stored separately.

2026-11-06 · open the original ↗

• Connectors let Claude work with the real file, not a pasted copy. Once connected, Claude can search, read and, where permissions allow, act in a tool; connecting usually takes a sign-in and a permissions check and can be undone at any time.
• MCP is the open standard underneath every connector. The lesson likens the Model Context Protocol to USB-C for AI: one consistent interface any developer can build a connector against.
• Web connectors reach cloud services; desktop extensions reach local tools. Desktop extensions need the Claude Desktop app (Settings > Extensions); the directory lists connectors rather than apps, so Atlassian covers both Jira and Confluence; on Team and Enterprise an Owner must add a connector first, and custom connectors fill gaps.
• A connection extends what you can ask, not what Claude seeks. The lesson's exercise adds a sentence to a request for each source switched on, making the point that the user writes every clause and each connection only gives the request somewhere to point.
• Claude's access is capped at the user's own permissions. Connecting your work email does not reach your CEO's inbox; permissions can be toggled per app and revoked, and custom connectors should come only from trusted sources.

2026-11-06 · open the original ↗

• Skills are reusable expertise packages Claude loads automatically. They are folders of instructions, scripts and resources; Anthropic's built-in ones power Excel, Word, PowerPoint and PDF creation, while custom ones can codify workflows such as a quarterly variance analysis or a compliance checklist.
• Skills need code execution because they run in a sandbox. They are on all plans once Code execution and file creation is enabled; Enterprise Owners must enable it and Skills, Team has it on by default. Uploaded files come back as new versions rather than edits to the original, and external data needs "Allow limited network access."
• The easiest way to build a skill is a Claude interview. Describe the workflow, answer its questions, upload templates or examples, then use Save skill; it is invoked automatically afterwards and can be revised by asking Claude.
• Executable code makes a skill's source a security question. Install custom skills only from trusted sources and review external ones before use; custom skills stay invisible to colleagues until shared.
• Projects store knowledge; skills perform tasks. A project supplies the what and a skill the how, and they combine: a customer-call-prep skill can draw on profiles stored in a project.

2026-11-06 · open the original ↗

• Artifacts are standalone outputs that outlive the conversation that made them. They are saved in the Artifacts tab and shared by link, unlike file creation, which hands over a Word, Excel, PowerPoint or PDF file to download; asking "Create this as an artifact" forces one.
• Design, Slides and Docs each cover one common deliverable. Design gives an editable canvas that can use your design system, Slides drafts and presents decks with export to .pptx, Google Slides or .pdf, and Docs are co-edited living documents whose connected-tool charts are snapshots that need a refresh request. All three are on every plan including Free, with admin control on Team and Enterprise.
• Edit directly, comment for Claude, or just ask, in any mix. Fixing a typo yourself avoids describing it and waiting for a rewrite; @-mentioning Claude in a doc comment gets a reply explaining the change.
• Sharing is private by default and its reach depends on plan. Pro and Max choose private or anyone-with-link; Team and Enterprise links stay inside the organization unless an Owner turns on External sharing; recipients need a Claude account and the conversation itself stays private.
• Ask for the deliverable, not just the content. "Summarize our Q3 results" yields a chat reply, while asking for a one-page doc for leadership yields an artifact; naming the end user and building at the end of a conversation also improve results.

2026-11-06 · open the original ↗

• Projects are self-contained workspaces for ongoing, not one-off, work. Each has its own chats, knowledge base and instructions; the lesson recommends one when there are reference materials reused repeatedly, consistent response requirements, or a team working from the same foundation.
• Project instructions act as standing programming for every chat. Good ones give context, process, tone and specific requirements, and can automate a workflow such as "When I upload a meeting transcript, create a structured summary using this template." The project description, by contrast, is not seen by Claude.
• Large knowledge bases switch to retrieval automatically. Near the context limit Claude searches project files and pulls only what is relevant (RAG), which the lesson says expands capacity up to 10x; descriptive file names aid retrieval, chats do not share context except through the knowledge base, and files uploaded mid-chat stay out of it.
• Sharing on Claude for Work uses three permission levels. Can view allows reading and chatting, Can edit allows changing instructions, knowledge and members, and the Owner controls visibility, including sharing with the whole organization.
• Keep each project focused and its knowledge current. Outdated documents produce outdated answers, and naming a document in a question ("Based on our Q3 report…") helps Claude focus. The lesson also notes the "selected style" in its video is deprecated, with Skills now doing that job.

2026-11-06 · open the original ↗

• Desktop work comes in three shapes, and recognizing which is the skill. Turn-by-turn work lives in Chat, handed-off work in Cowork and software building in the Code tab; in the new Claude experience Chat and Cowork merge into any conversation.
• Work turn by turn when each answer shapes your next question. Brainstorming, drafting and quick questions belong here; the desktop adds quick entry (double-tap Option), screenshots or window sharing, and dictation on Mac.
• Hand work off when it is multi-step, spans tools, or recurs. Cowork saves finished files back into a local folder (Chat returns downloads), runs scheduled tasks remotely even with the computer asleep, splits big jobs across subagents, and adds browser use, plugins and computer use (research preview on Pro and Max). It is on Pro, Max, Team and Enterprise.
• Handing off does not mean giving up control. Claude may ask scoping questions and shows its plan, progress can be watched and steered, and when set to ask before acting it stops for approval on actions like sending an email.
• Claude Code runs locally or in the cloud with adjustable autonomy. Local sessions work on a folder on your machine; cloud sessions on a GitHub repo keep going after the app closes; modes include Manually approve, Accept edits and Plan. Non-developers are told they can skip it.

2026-11-06 · open the original ↗

• Most weak responses come from missing context or unstated preferences. Generic output needs audience, role and constraints; wrong length needs an explicit target such as "under 100 words"; wrong format needs an example; wrong tone needs a plain description or sample.
• Confident-sounding errors call for independent checks on high-stakes work. The lesson says Claude occasionally produces plausible but incorrect facts, especially on niche topics, and advises asking for sources or confidence levels and enabling web search.
• A first prompt opens a conversation; it is not a one-shot request. Effective users treat drafts as starting points, give specific feedback ("Cut the first two paragraphs…"), and start a fresh chat when a conversation has gone off track.
• AI Fluency rests on four competencies. The 4D Framework from Professors Rick Dakan (Ringling College of Art and Design) and Joseph Feller (University College Cork) names Delegation, Description, Discernment and Diligence.
• Test Claude on work you already did before delegating it. The suggested eval uses 5–10 past examples; in the video, Rio of Valley Veterans Services found AI caught the attendance–placement correlation but missed the combined housing-and-job program until told to consider program type, and inferred enrollment dates it lacked. If several refinements cannot match known results, the task should not be delegated, and validation never removes accountability.

2026-11-06 · open the original ↗

• Good prompts set the stage, define the task, and specify rules. The worked example is a marketing lead at an indie streaming startup asking for cited market research structured as a report of up to 5 pages for Series A investors; the framework is adapted from the 4D AI Fluency framework.
• Uploads and tools tailor responses to your actual situation. Claude reads text and visuals in PDF, DOCX, CSV, TXT, PNG and JPEG files, and web search or connected sources like Google Drive pull in current information as needed.
• Match the model and thinking mode to the task. The video recommends Opus for the most complex work and Sonnet as the everyday default, notes extended thinking adds latency, and says changing model starts a new chat; it also describes multi-source cited research reports taking five to 45 minutes.
• Iterate instead of expecting a perfect first answer. Options are follow-up questions, explicit feedback, redirecting, restarting in a new chat, or editing and resubmitting a message with the pencil icon.
• Memory and preferences carry context across conversations. Memory is on by default on Free, Pro and Max and off on Team and Enterprise until an Owner allows it, and is reviewable in Settings > Memory; standing preferences go in Settings > Account > 'Instructions for Claude', and skills encode reusable ways of working.

2026-11-06 · open the original ↗

• Claude is positioned as a thinking partner, not a chatbot. The lesson attributes its behavior to Constitutional AI principles and stresses that it is steerable on personality, tone and behavior.
• Whether a request needs Claude depends on your situation, not its topic. In the sorting exercise, a currency rate or a definition is search-box work, while "best structure for a quarterly business review" becomes thinking-partner work once last quarter's deck and leadership's pushback are attached: "A search box takes a question. Claude takes the situation."
• A large context window lets Claude reason over extensive material at once. The lesson cites 200K+ tokens (about 500 pages), up to 1M on Pro, Max, Team and Enterprise with supported models, and calls coding one of Claude's greatest strengths alongside Thinking and Learning mode.
• The same intelligence runs across several interfaces. Claude.ai and its web, desktop and mobile apps are on every plan and sync across devices; Claude Code, Claude Tag in Slack, Claude Design and Claude for Microsoft 365 cover other environments, while the course focuses on Claude.ai.

2026-11-06 · open the original ↗

• The course delivers a structure for explaining AI behavior yourself. Kristen recaps: two training stages (pretraining builds a document completer, fine-tuning layers an assistant on top), four properties each running from a capability zone to a limitation zone, and failures diagnosed by asking "which two things collided?" rather than "what broke?"
• The four properties and the 4Ds are two sides of one system. The 4Ds are what you do and the properties are what you're responding to: next token prediction sharpens Discernment (fluency and accuracy are independent), working memory sharpens Description (context is leverage), and steerability sharpens Delegation (you know where control is high).
• Calibrated trust is a habit, not an attitude. Before handing off a task, check whether it's well-worn or sparse, recent or stable, comfortably inside the window, and concrete or open to a gap between words and intent; then add verification, context or checkpoints to match.
• The edges will move while the properties stay the same. She predicts AI will remain a predictor whose fluency can outrun its accuracy, with uneven knowledge and a cutoff, a finite window, and a gap between words and intent; the recommended next steps are practising on real work, testing the edges, and taking the AI Fluency Framework & Foundations course.

2026-11-06 · open the original ↗

• Most real AI failures are two properties interacting. The lesson argues that naming which pair is at play points straight to the fix, while jumping to "how do I fix my prompt?" is guessing; similar-looking outputs from a knowledge problem and a working-memory problem need completely different responses.
• Hallucinated citations come from prediction meeting a knowledge gap. The model generates citation-shaped text (real-sounding journals, names that fit the field) and can't tell knowing from generating; the fix is to verify specifics independently or use source grounding so it retrieves real documents.
• Long-conversation drift comes from working memory meeting steerability. Constraints set early fade, and because steerability follows whatever instruction is most salient, later messages quietly override them; in the example, Claude is ignoring half of the early constraints 20 messages later. Re-supply critical context or start fresh with the essentials up front.
• Other pairings produce their own failures with targeted fixes. The interactive widget lists confidently wrong reasoning (fix with visible reasoning or code execution), context-poisoned generation (curate what's in the window), agreeable bad premises (explicitly invite pushback), and a supplied document conflicting with training (say which source takes priority).
• Diagnosing the pair is Discernment, and recurring pairs guide Delegation. Naming the failure turns "that wasn't quite right" into "I need to reground this in a source," and the same compound failure recurring on one kind of task shows which tasks to restructure, split up, or keep for yourself.

2026-11-06 · open the original ↗

• "Make it shorter" can trim words without surfacing the ask. Cutting a roadmap email from 6 sentences to 4 followed the instruction, but the sign-off request stayed in sentence three for a skimming skip-level exec; once the goal was stated, the result opens with "Need your sign-off on the Q2 roadmap by Friday," and the subject line says so too.
• "Make it more professional" can mean audience and channel, not tone. A Slack note about a finished migration got its typo fixed, joke removed and contractions expanded, yet still read like "a Slack message in a suit"; because it was going to a client, it needed a subject line, a greeting by name, context and a sign-off.
• "Add more detail" often calls for targeting, not more words. Expanding every status heading padded Progress and Blockers with noise; the version written for a stakeholder deciding on escalation kept those terse and expanded only Risks, with figures (p95 vendor API latency at 3s) and a recommendation.
• The model only sees the words, so state the goal. The exercise's closing point is that each vague instruction left a gap between letter and spirit, and saying the goal outright closed it.

2026-11-06 · open the original ↗

• Models follow instructions by pattern completion, not understanding. Matt of Anthropic's user research team says fine-tuning taught the model to treat text as a request and follow rules, but there is always a gap between the words typed and the intent, and many interesting limitations live there.
• Short, concrete, checkable instructions are where control is strongest. "Respond as a table," "under 100 words," or an exact schema are easy to match and to verify at a glance; personas, multi-step processes and iterative refinement also land reliably, while long reasoning chains and abstract asks like "be insightful" thin the control out.
• Letter-over-spirit failures honor the instruction and miss the point. His example: "Summarize this report in under 100 words. And make it punchy" produced a punchy 100 words that cut the one qualified finding he needed; other failures are reasoning drift, where an error in step two carries through steps three to five, and prompt injection from instructions hidden in documents.
• When an instruction lands uselessly, restate the goal, not the instruction. Saying "be concise" more forcefully won't fix what was really an intent problem; he advises stating the goal with the steps, adding checkpoints for intermediate results, and keeping verifiable instructions near the task.
• System prompts, visible reasoning and structured outputs narrow the gap. Standing instructions don't dilute over a long conversation, visible reasoning catches drift early, and JSON schemas or function calling limit wandering; tasks needing long chains or native numeric precision call for tighter human checkpoints or another tool.

2026-11-06 · open the original ↗

• More context can make answers worse. The piece opens by challenging the instinct to paste in everything: attention is finite, and every addition pushes other material toward the middle, which it calls the attention dead zone.
• Humans and LLMs share the same U-shaped recall curve. A 15-word memory test shows the serial position effect, primacy and recency favoring the ends of a list; the piece cites Stanford researchers' 2023 "Lost in the Middle" study (Liu et al.) finding accuracy fell by more than 30% when a key fact sat mid-context, and calls this structural to transformer attention, not a quirk.
• State critical instructions early and repeat them at the end. A key instruction buried among chat messages is marked the dangerous pattern; the safer one states it up front and restates it after the latest message, and a question about page 11 of a 20-page document is likelier to miss than one about page 1 or 20.
• Context engineering means choosing placement and cuts, not just contents. The takeaway is "curate ruthlessly, place strategically, and repeat what matters."

2026-11-06 · open the original ↗

• The model can only attend to what sits in its context window. Matt of Anthropic's user research team says instructions, prior responses, uploaded documents and the whole conversation share one fixed-size container; past its limit the oldest material usually drops off silently, and by default the window starts empty each session unless memory or a CLAUDE.md file carries something forward.
• Working memory has a cliff, not a gradual slope. Next token prediction and knowledge degrade gradually, but this property "tends to work right up until it doesn't," often with no warning; the model also doesn't learn from your corrections, it only responds to what's currently in context.
• Inside the window, context is real leverage. A short style guide, glossary or voice sample takes effect at once with no retraining, and the more relevant context supplied, the more tailored the output; but attention isn't uniform, and research finds a lost-in-the-middle effect where material deep in a long input carries less weight.
• Product features push the cliff further out. He lists memory across sessions, compaction or summarization of long histories, projects that keep standing documents in context, skills that load instructions only when needed, multi-agent workflows with separate windows, and larger context windows.
• Front-load, chunk, and start fresh when quality slips. Put key material at the top instead of "on page 12," process big documents in sections, and restart with a short summary when a long chat degrades, since that is often a context limit rather than a capability limit; the lesson calls working memory what Description acts on.

2026-11-06 · open the original ↗

• Embeddings replaced keyword matching by treating meaning as a location. String search for "car" misses "automobile" or "my Civic needs new brakes," and Google bridged that by hand with synonym dictionaries, stemming and click mining; embeddings learn the mapping from training data, so similar concepts land near each other.
• Similarity search places the query among the sources and retrieves its neighbors. It plots the query in the same space and takes the nearest k; the exercise scores a children's dinosaur book, the Velocicoaster web page and an encyclopedia on "dinosaurs" and "roller coasters" axes, then places "What's the best dinosaur-themed roller coaster?" among them to retrieve its neighbors.
• Real embedding spaces have far more dimensions, none of them named. Real embedding models use around a thousand dimensions. Each added axis is one more coordinate and one more squared term in the distance formula, so the math works past 3D even though nobody can picture it; nobody chooses the axes either, they emerge in training, so you can't call dimension 847 "the dinosaur axis."
• An embedding model maps any text to a fixed-length vector. The example uses VoyageAI's model, which outputs 1,024 values whether the input is three words or three paragraphs; closeness is measured by cosine similarity, the direction vectors point, on a scale from -1 (opposite) through 0 (unrelated) to 1 (identical).

2026-11-06 · open the original ↗

• Everything the model knows comes from training, frozen at a cutoff. David of Anthropic's safety team says the model has no experiences and doesn't browse unless a product gives it search; whatever happened after the knowledge cutoff "simply isn't there."
• Ask how well-represented a topic was, not whether the AI knows it. Photosynthesis, frequent and consistent in training data and unchanged, gets a deep, accurate answer; "Who's the current mayor of Toledo?" may get the person who held the job two years ago, and the model can't tell the difference.
• Training gives broad, connected knowledge with predictable failure modes. Embeddings put related concepts near each other, so a biology question can pull in chemistry, history and economics; the same process brings staleness, uneven coverage (minority languages, niche and local domains), inherited bias in what counts as "default," and source amnesia.
• Runtime tools patch the gaps; without them you rely on training alone. Web search routes around the cutoff, MCPs and retrieval connect documents the model never saw, tools call live calculators and databases, and explicit cutoff disclosure tells you what to double-check.
• Verify time-sensitive claims and test before trusting a new domain. He says strength in one domain doesn't carry over to the next one, and gaps are likeliest for current events, recent research, who holds a position, prices, and niche or local topics; for Delegation, that decides whether you must supply the knowledge yourself.

2026-11-06 · open the original ↗

• A next-word predictor can be built just by counting word pairs. The interactive piece starts from the phone game of writing a text using only suggested words, then "trains" on five messages by tallying which word follows which, producing a transition matrix whose normalized rows are probability distributions over the next word.
• Sampling strategies formalize the gut feel of picking a word. Always taking the top word maps to temperature → 0 or top-k with k = 1; sampling faithfully is temperature = 1; boosting likely words is temperature < 1; top-k keeps the N best; top-p keeps the smallest set summing to a threshold and, unlike top-k, adapts to how confident the model is.
• LLMs sample the same way but compute the distribution differently. A Markov chain reads one row of a table keyed on the last word; an LLM runs a forward pass over the whole conversation through billions of parameters, giving up the table's explainability for far more context and capability.
• The technique is over a century old. Markov published the idea in 1906; n-gram models drove phone prediction around 2010 (SwiftKey, then Apple's QuickType); RNNs from around 2015 and transformers in 2017 replaced table lookup with a learned function.

2026-11-06 · open the original ↗

• Generative AI composes answers; it does not look them up. David of Anthropic's safety team calls it closer to "an extraordinarily sophisticated autocomplete than a search engine," so a citation-shaped string satisfies the pattern just as well as a citation to a paper that actually exists.
• How well-worn the path is decides how reliable the output is. Summarizing a well-known essay lands cleanly because the model has seen the task thousands of times; asked for three papers with publication years by a mid-level researcher in a niche subfield, it answers in the same confident tone while some results may be fabricated.
• Fluency and hallucination are the same property. Listed strengths are fluent text in any register, synthesis across fields and coherent continuation; failures are hallucination, confabulation (filling gaps instead of flagging them), inconsistency from sampling, and misplaced confidence.
• Fabrication concentrates in specifics, and tone says nothing about accuracy. Names, dates, statistics, citations, quotes and URLs need checking, more so when stakes are high or the domain is unfamiliar; "smoothness and correctness are independent variables."
• Product features exist because the underlying behavior is always generative. Citations and source grounding, trained uncertainty signaling, constrained generation and skills, and generator-verifier loops are presented as ways to push the limit out; the lesson ties this property mainly to Discernment, and secondarily to Delegation.

2026-11-06 · open the original ↗

• Pretraining alone produces a document completer, not an assistant. Maggie, who leads Anthropic's education team, says a pretrained-only model asked "What is the capital of France?" may just continue the pattern ("Paris. What's the capital of Germany? Berlin…") because it has seen quizzes, and has no concept of helping anyone.
• Fine-tuning layers trained assistant behavior on top. Curated examples and reward signals from human preferences teach the model to treat input as a request, answer instead of rambling, and decline harmful asks; politeness and caution are presented as trained results, not emergent ones.
• Human-preference training leaves four predictable shadow traits. These are sycophancy (validating and backing down under light pushback), verbosity (thoroughness scored well), over-caution (conservative safety training refusing safe requests) and loose confidence calibration, which she singles out as genuinely hard to train.
• These traits appear in all models but vary with fine-tuning. She says how they show up depends on each lab's fine-tuning, and points to Claude's published constitution as Anthropic's account of how it shapes Claude's personality.
• Naming the trait tells you how to read the output. A model that caves when you push back is showing sycophancy, essays where you wanted bullets are verbosity, and heavy caveats on a harmless question are over-caution; the exercise tests each by priming a wrong assumption or asking for a one-sentence answer.

2026-11-06 · open the original ↗

• Most AI isn't generative; this course covers only the kind that is. Spam filters, recommendation engines, fraud models and call routing sort, rank and classify existing content; generative AI produces new text, images, code, audio or video, and is built by pre-training on large data followed by fine-tuning for safety and helpfulness.
• AI's strengths and weaknesses come from the same mechanism. The lesson argues a model writes compellingly and hallucinates for the same reason, being a prediction engine; the mechanism doesn't change, only where a given task lands between the capability and limitation zones.
• Four properties each answer one question about the machine. Next token prediction: where answers come from, since without an external source the model writes rather than looks up. Knowledge: what it knows, broad but uneven and frozen at a cutoff. Working memory: what it attends to, which is only what's in the context window. Steerability: how much control you have, with a gap between intent and result.
• The goal is calibrated trust, not distrust or full delegation. Learners are to ask where a task sits on each continuum, whether it's well-trodden or near an edge, and what the stakes are if the output is wrong.

2026-11-06 · open the original ↗

• This course is the machine-side companion to the 4D Framework. Kristen of Anthropic's education team presents Delegation, Description, Discernment and Diligence as human competencies, and this course as an explanation of the machine properties they respond to; you can't delegate without knowing where the model is weak, or judge output without knowing how it was produced.
• Generative AI has four core properties, each a continuum. The properties are next token prediction, knowledge, working memory and steerability; for each, the learner is taught to judge whether a task sits in the capability zone or drifts toward the edge, after first covering the two training stages (pre-training, fine-tuning) that give a model its character.
• Most real-world failures are two properties meeting. Her examples: a hallucinated citation is next token prediction meeting a knowledge gap, and drift over a long conversation is working memory meeting steerability; naming the combination tells you the cause and the fix.
• The mental model is meant to outlast model releases. Context windows grow and hallucination rates drop, but the course argues the properties themselves stay put: there will still be a knowledge cutoff and the context window will still have an edge, even as the boundaries move.
• The exercises only work on your own expert domain. Learners are told to bring real tasks, listing 4–6 things they used AI for in the past two weeks, because they need to be able to tell when an output is off; that list is reused in every later lesson.

2026-11-06 · open the original ↗

• Hooks run every time; instructions in a prompt only usually do. The lesson's example is a CLAUDE.md line telling Claude to run Prettier after each edit, which it follows most of the time, against a hook that fires without exception. Listed uses are auto-formatting after edits, logging every command for compliance, blocking dangerous operations and notifying you when Claude finishes.
• A hook pairs a lifecycle event, an optional matcher and a command. Hooks are configured by editing settings.json directly; /hooks only shows a read-only list to confirm a new one registered. Common events named are PreToolUse, PostToolUse, UserPromptSubmit, Stop and Notification, with more in the hooks reference; the standard example is a PostToolUse hook matching "Edit|Write" that runs the formatter for the file's extension (Prettier for TypeScript, gofmt for Go).
• Pre-tool hooks can veto an action, and the exit code decides. A PreToolUse hook gets the tool name and input as JSON on stdin: exit 0 proceeds, exit 2 blocks and feeds stderr back to Claude so it can adjust, and any other code is a non-blocking error shown only to you. This is presented as the way to guarantee rules such as no writes to a production config directory, no rm -rf, no commits to main.
• Project-level hooks travel with the repo to the whole team. Hooks in .claude/settings.json can be checked in so everyone gets them automatically. Commands should reference project scripts through the CLAUDE_PROJECT_DIR environment variable so they work whatever Claude's current working directory is.

2026-11-06 · open the original ↗

• MCP brings in context that lives outside your codebase. Model Context Protocol is an open standard that gives Claude Code tools — the ability to take actions rather than just return text — against databases, productivity apps and public repositories. Examples given are a Linear server for issue details and Context7 for up-to-date dependency docs.
• Servers are either remote over HTTP or local over stdio. HTTP servers are hosted by the provider; stdio servers are processes on your machine. Both are added with claude mcp add, and /mcp inside a session shows what is connected, its status, and lets you disable servers.
• Scope decides who gets a server. Local is this project for you only, user is all your projects, and project uses a .mcp.json checked into version control so everyone on the codebase gets identical servers.
• Every connected server costs context, even when unused. Each adds its tool names and instructions to the window, so the advice is to disable idle ones; tool search, on by default, keeps full tool definitions out until Claude needs them. Where a CLI equivalent exists (gh, aws), the lesson calls it more context-efficient because it adds no per-tool listing.
• Pairing a server with a skill teaches Claude to use it well. A skill puts only its name and description in context and loads the full contents when Claude decides it is needed.

2026-11-06 · open the original ↗

• Skills replace instructions you keep repeating to Claude. A skill is a markdown file — more broadly a folder of instructions, scripts and resources — that teaches Claude a task once, such as your coding standards, PR feedback structure or commit message format. The lesson's test: if you keep explaining the same thing, that is a skill waiting to be written.
• The description is what makes a skill fire. Claude compares each request against the descriptions of all available skills in their SKILL.md files and activates those that match, so a "review this PR" request finds a PR-review skill.
• Where a skill is stored decides who gets it. Personal skills in ~/.claude/skills follow you across projects and hold your own preferences; project skills in the repo's .claude/skills come with every clone and hold team standards such as brand guidelines, fonts and colors.
• Skills load on demand; CLAUDE.md loads into every conversation. Only a skill's name and description sit in context until it matches, so a PR checklist stays out while you debug. Always-on rules, such as TypeScript strict mode, belong in CLAUDE.md instead.
• Skills apply automatically, where slash commands must be typed. The lesson positions them for specialized, task-specific knowledge Claude should pick up when it recognizes the situation.

2026-11-06 · open the original ↗

• Subagents keep exploration work out of your main context. Each runs in its own window with two inputs — a custom system prompt from its configuration and a task description written by the parent — and its file reads, edits and tool calls never reach the main conversation. Only a summary returns, and the subagent's conversation is then discarded entirely.
• You get the answer without the journey, but lose the journey. The example is finding which service handles refunds in an unfamiliar payment system: unaided, Claude might read 15 files and trace several calls to learn one fact. The trade-off the lesson names is that the main window no longer sees how the subagent reached its conclusion or what else it found.
• Built-in subagents cover common exploration and planning work. The general-purpose subagent handles multi-step tasks needing exploration and action, explore does fast codebase search, and plan does research and analysis during plan mode.
• Custom subagents are Markdown files Claude can write for you. They use YAML frontmatter, and the easiest route is describing one, e.g. a read-only code reviewer in .claude/agents/; Claude generates the name, description and prompt, and the description governs when it gets called. .claude/agents/ is per-project, ~/.claude/agents/ is global, and a folder created mid-session needs a Claude Code restart.
• Subagents can keep memory and carry preloaded skills. Persistent memory lets one retain knowledge across conversations on the same projects. Skills listed under the skills key are loaded in full, unlike in the main conversation, where only their name and description load.

2026-11-06 · open the original ↗

• Without CLAUDE.md, every session rediscovers your project from scratch. Claude re-explores the codebase, dependencies and existing features, and its assumptions make it harder to steer. A CLAUDE.md in the project root is read automatically each session and appended to your prompt — the lesson calls it an onboarding script for the codebase.
• A useful file states the stack, the commands and the conventions. The example names a Next.js 15 App Router app with Tailwind and Drizzle, pnpm dev/test/lint, and rules such as 2-space indentation, named exports and server actions over API routes. With that, a request for a React component already follows those conventions.
• Project-level files are shared; user-level files are personal. The project CLAUDE.md lives in the repo root and should be committed so the team benefits; the user-level one lives in your configuration folder and applies across all your projects.
• Turn repeated corrections into saved rules. If you keep correcting Claude, ask it explicitly to save the rule to memory so the next session knows it. Project docs can be pulled in by reference with @ and a path, e.g. @README.md.
• Start without a CLAUDE.md so it captures only real corrections. The recommendation is to work first, note where you constantly course-correct, and keep the file compact; /init then has Claude generate one.