This is the full, in-depth reference for Level 2. For the short version, go back to the lesson.

Level 2 — Connect (MCP)

Connecting Claude to your real tools — your calendar, mail, files — so it looks things up itself instead of waiting for you to paste them in.

The first class that touches your world. Verb: Connect. Org-rung: Middle Manager. Same single conversation, same expert — but now you've handed it the keys to one real tool through MCP (Model Context Protocol, the standard that lets Claude plug into a tool), and it reaches your actual data itself instead of waiting for you to paste it in. You stop being the copy-paste bridge. In exchange, a mistake stops being words on a screen and starts being an action on a real system — which is why this class is, before anything else, the class where you learn to grant access narrowly and verify every action against the source.

Before you start — read these once

These get used on every page below. Read them now and the rest reads cleanly. If you've come up from Level 1, the shape is identical — only the reach, the dominant hat, and the new risk have moved.

Mini-glossary (plain definitions — read this BEFORE the boundary statement)

The single most important sentence in this module (the boundary, just below) uses three of these terms. So they come first, not last.

• MCP (Model Context Protocol): the open standard "plumbing" that lets Claude reach a tool — your calendar, your mail, a database — through a defined connection. You don't operate the protocol by hand; you just add a connector that speaks it. Think of MCP as the socket and a connector as the plug.
• Connector: the specific link to one tool (Google Drive, Gmail, Calendar, or a custom server). Adding a connector is the act of handing Claude the keys to that one tool. The site's "Add a connector" how-to walks the exact clicks; Sections 3 and 4 deepen it.
• Scope (permission): the fence around what a connector may do — which tool, look-only vs. look-and-do, sometimes which account. Scope is the most load-bearing idea at this level: a connector is only ever as dangerous as the scope you grant it. A read scope lets Claude look; a write/act scope lets it change something in your real world.
• In the loop: you review and approve each consequential action before it happens, rather than discovering it after. At this level you stay in the loop per action — that's the design, not training wheels.
• Acting / a write: anything that changes your real world — drafting or creating a file, creating or moving a calendar event, applying a label. Distinct from a read (fetching to look at), which changes nothing. The risk lives almost entirely in writes.
• Consequential action: a write whose effect you'd care about if it were wrong — a calendar event created on a real day, a draft addressed to a real person. Reads are rarely consequential; writes usually are.
• Custom MCP server: a connector you add by pasting a server URL rather than picking a pre-built one — the way you reach an internal or third-party tool that isn't on the default list. Same scope rules apply, plus you must trust whoever runs the server (vetting checklist in Section 3).
• Authorize / consent screen: the sign-in step where the tool itself (Google, etc.) — not Claude — confirms it's really you and shows you, in its own words, what access you're granting (e.g. lines like "See your calendar events" and "See, edit, create and delete your calendar events", then a blue Allow / Continue button). You can review and revoke this later from that tool's own account settings, independent of Claude.

You can undo this at any time. Before you grant anything: every connector can be removed in Claude's Settings → Connectors, and the access itself can be revoked at the provider (e.g. Google Account → Security → Third-party access). Nothing you authorize here is permanent. Knowing the exit exists is what makes it safe to walk in.

The boundary of the class — stated once, reused everywhere

This is the sentence to memorize. Every section below reuses it verbatim:

At Connect level Claude acts only within the scopes you grant — usually one tool and one action at a time, with you in the loop per consequential action. It can now READ your real data and take actions you authorize — but only what each connector's granted scope allows.

The four-level ladder (where you are)

This module is Level 2 of 4. The whole ascent:

The thesis of the whole Ascent is one sentence: the more you let Claude reach, the more you can hand over. Level 1 let it reach almost nothing of yours — only the window — so you handed over only the thinking. This level grants it reach into one real tool at a time, so you hand over the thinking and the looking-up. That is the entire trade you are about to make.

The three jobs (your hats)

Across the whole ladder you wear three hats. They never go away; what changes is which one does the heavy lifting.

At Connect level the Verifier hat dominates — and grows a second face: the scope/permission owner. The level's signature failure is no longer a wrong sentence; it's a wrong action on a real system, and a too-broad grant that let that action reach further than it should. So the Verifier now does two jobs: it decides what access to grant before the work (the narrowest scope that does this job), and it checks every action against the source after the work (did it touch the right record). You still wear all three: you Navigate when you choose which tool the task even needs, and you Conduct when you keep it to one fetch-or-act at a time, approving between. Later levels lean harder on Conductor and Navigator as more of the loop is handed over. Learn the scope-owner reflex here, on one tool with you in the loop, and Levels 3–4 inherit it for free.

Availability note: the connectors named here (Google Drive, Gmail, Calendar, custom MCP servers), the exact scope controls, and the per-action approval prompts can all vary by plan, by device (web / desktop / mobile), by personal vs. managed/work account, and by what an administrator has enabled. On a managed account some connectors may be pre-approved, restricted, or off. The connector tool-set itself is versioned and can change over time. If a connector, a scope toggle, or a button described here isn't present, that's why — not a mistake on your part.

0. Class Card — at a glance

In ten seconds: Connect is the class where Claude reaches your real tools itself, one tool and (usually) one action at a time, inside fences you draw. You trade a slice of control — it now touches your actual stuff — for reach you no longer broker by hand: ask "What does my week look like, and what should I prep for?" and it reads your real calendar, inbox, and Drive and answers from them, instead of you pasting three screenshots. The new cost is real: a mistake here is a wrong action on a live system — a draft to the wrong thread, an event on the wrong day — not just wrong words on a screen. That is exactly why the job is grant narrowly, stay in the loop, verify against the source.

1. What This Level Is — and the Thinking Behind It

The class in one line: Connect is the same single expert as Chat, but you've handed it the keys to one real tool, so it reaches your actual data itself instead of waiting for you to carry it in by hand.

The plain definition

At Chat level, you were the bridge: you read your calendar, copied the relevant bit, pasted it into the chat, got an answer, and carried it back out yourself. Connect removes the bridge. You add a connector — say, your calendar — and now when you ask "What does my week look like, and what should I prep for?", Claude reads the real schedule itself, cross-reads your Drive for the deck that meeting needs, scans your inbox for related threads, and answers from your actual world. It can also prepare actions in that world — draft a reply, propose an event — and, with your go-ahead, let them land. That is the whole mechanic. The class is built on one move: Connect.

It feels like the assistant finally has hands. The class is simple to start. Playing it safely is the skill.

The thinking that makes it work

Three practices separate someone who connects deliberately from someone who clicks Allow and hopes.

• You are now the scope owner — and most of your safety is what you decline to grant. Claude can only ever do what the connector's granted scope allows. So the load-bearing decision happens before you ask: which tool, and read-only or also act? A read-only calendar grant cannot move a meeting no matter how you phrase the prompt — the capability simply isn't there. Behavior: you grant the narrowest scope the task needs and can name out loud what you deliberately withheld. (How to do it: Section 4.)

• Verify against the source, not against the run. A connector that returns "done" tells you the call executed — not that it hit the right record with the right content. Claude will fluently summarize an inbox it half-read and confidently point at last quarter's deck. So you supply the doubt by opening the actual record. Behavior: after any consequential read or action, you open the real thing — the event, the file, the draft — and confirm it's the one you meant. (The procedure: Section 8.)

• Reach is the currency you spend. The more you let Claude reach, the more you can hand over. At Chat you let it reach only the window, so you handed over only the thinking. Here you've granted reach into one real tool, so you hand over the thinking and the looking-up — and, when you authorize it, the preparing of a single action. You still hold the irreversible verb. Behavior: you let it fetch and prepare; you keep the press-send.

The boundary of the class — and what it does NOT say

The boundary stated once above is the line. Note what it does not claim. It does not say "Claude does everything in your tools" — at this level the irreversible verbs stay with you (notably, Claude drafts email; it does not send it for you — see Section 3). It does not say "every write is silently safe because the platform always stops to ask" — pausing for approval is a posture you enforce (you instruct "propose, don't execute"), not a guarantee you can lean on blindly. What it says is narrower and true: Claude acts only within granted scopes, one consequential action at a time, with you in the loop. Concretely:

These are the boundary of the class — and that boundary is exactly what Level 3 moves.

Why this is the level where the reflex gets expensive

At Chat, a wrong answer cost you a worse paragraph. Here, the same wrong answer can become a real draft to the wrong client or an event on the wrong Tuesday. The verify-reflex you built on cheap mistakes is now load-bearing on expensive ones. So the promise of this level is precise:

Master scope-then-verify here, on one tool with you in the loop per action, and Levels 3–4 — where agents run unattended — inherit a reflex they cannot run safely without.

2. Skill-Point Allocation — the Judgment of When to Play This Class

If RPGs aren't your thing: a "class" is just a role with its own strengths; "skill points" are your limited time and attention, and your willingness to grant access. The lesson is to spend them where they pay off — not to wire up a connector every time you could have pasted a paragraph.

Connect is powerful precisely because it touches your real world — which is also exactly why it's the wrong spend for most questions. A connector is not free: it costs a grant (standing access to a real system), an audit (you now own a permission you must remember to review), and a slice of control (a mistake can now land on something real). Allocate well and you stop being the copy-paste bridge on the work where that bridge was the bottleneck. Allocate badly and you either under-spend (paste-and-ask would have done it in thirty seconds and you wired up OAuth instead) or over-grant (you hand Claude broad access to your mail to answer one question a read could have answered).

The master gate: the Reach Test

There is one spine to carry, and it has two halves. Before deciding to connect anything, ask:

(1) Does this task actually need live reach into a real tool — not general knowledge, not something I could paste? And (2) is the scope it needs safe to grant for this one job?

Half (1) decides whether to play this class at all. Half (2) decides how much power to hand over. Read the cost off this table:

Three sub-moves fall out of the gate:

• Reach necessity (half 1, sharpened). The honest test is "could I answer this by pasting?" If yes, you don't need a connector — you need a paste. New power invites over-use; resist wiring up Drive to reason over one paragraph.
• Least-scope (half 2). Grant the verb in your brief and nothing wider. A "tell me what's on Tuesday" job earns read; it does not earn a write grant held "just in case." You upgrade to act-scope on the specific run that acts, then audit it back off.
• In-the-loop calibration. Set the review weight to the wrong-action cost. A pure read is low cost — Step 5 is a glance. A write to a real system is high — Step 5 is an explicit go/no-go on a named record, and for irreversible verbs (an event others see, a message you'll send) you keep the keystroke.

The decision: paste it, connect it, or step up

Run the task through the gate, then read it off this table. (This is the actionable form — it encodes the judgment without a second checklist.)

Where Chat ends, Connect sits, and Delegate begins (the seam that matters here)

• Chat (Ask): you are the bridge. You paste context in, carry the answer out, take every action. Maximum control, minimum reach.
• Connect (this level): Claude reaches one tool, one action at a time, with you in the loop. You stop brokering the data by hand; you keep the grant and the per-action approval. You've traded a slice of control for reach you no longer carry yourself.
• Delegate (next level): Claude runs the whole multi-step job across a space you set up, and you review the result rather than approving each step. You're on the loop, not in it.

You don't need a connector to reason about your data — paste it and Chat handles it. You need one when fetching it yourself, every time, is the bottleneck. And you don't step up to Delegate until approving each action one at a time is the bottleneck. Stay in the cheapest class — and the narrowest scope — that does the job.

3. Equipment — the Tools You Equip at This Level

At Chat level your character had no hands on your private world — every piece of equipment was just you loading the workbench before you asked. At Connect level the equipment is different in kind: each connector is a hand that reaches into a real system on your behalf, and the cost is no longer "what data leaves my hands" but "what can it see, and what can it change." So read every piece with a two-part question: what does this let Claude SEE, and what does it let Claude DO — and is that the narrowest grant that does the job? Equipping is now an act of granting permission. That is the hat the whole level turns on (the scope/permission owner — your Verifier hat, extended).

Every row below is a slice of the boundary: Claude acts only within the scopes you grant, one tool/action at a time, with you in the loop per consequential action. The connector is what turns "what each scope allows" from an abstraction into a real button.

Where to click to start (one canonical path)

On the web it's Settings → Connectors. On desktop/mobile the wording may differ — look for Connectors, Tools, or a plug/puzzle-piece icon in settings. If you don't see it at all, your plan or your administrator may not have it enabled (Availability note). (The site's "Add a connector" how-to is the same five steps, deepened below.)

How a connector actually works (read once — it makes the table legible)

A connector is the MCP plumbing that lets Claude reach a tool you authorize. You add a connector to a specific tool (Calendar) and, during sign-in, the tool's own consent screen shows you what it's about to grant — lines in Google's wording like "See your calendar events" (read) and "Edit, create and delete your calendar events" (write) — then an Allow / Continue button. Three things follow that people miss:

• Read and write are different scopes. A read-only grant lets Claude tell you what's on Tuesday; it categorically cannot move a meeting, because that scope was never granted. Granting "read" does not silently grant "write." This is your main safety lever — under-grant on purpose.
• The consent screen is the tool's, and it's often coarse. You don't dial scopes on Claude's side; the provider defines what's on offer, and it is frequently all-or-nothing (you accept the bundle a connector asks for, or you don't connect). Where you can choose the narrower of two connector variants (e.g. a read-only option), take it. Where you can't, that breadth is a cost you're now accepting knowingly — note it and revoke after. If you don't see a per-permission toggle, that's normal, not a failure on your part. Your scoping then happens by choosing which connector to add, by what you ask Claude to do, and by revoking when done.
• A connector is standing, not per-question. Once authorized it stays connected across chats until you remove it or revoke at the provider. That's the convenience and the cost: the hand stays attached. Audit the connector list; don't set-and-forget.

The loadout

Real, current connectors. The DO column reflects what these connectors actually expose today — note what they conspicuously do not do.

Where does a custom MCP server URL come from? Your IT team or a tool's vendor gives it to you — it looks like a web address (https://…). If nobody handed you one, you don't need this connector. (For developers: the same server can be added to Claude Code from the terminal with claude mcp add — that's the Level 4 / Code surface, and you don't need it here.)

Vetting a custom MCP server (turn "trust the source" into a checklist)

"Trust the source" is not a procedure. Before you paste a URL, ask three concrete things:

1. Who operates and hosts it? First-party (the tool's own vendor) or org-internal (your IT) is a different risk than an unknown third party. If you can't name the operator, don't grant.
2. Can it offer a narrow / read-only scope at all? A server that only offers broad, all-or-nothing write access is a reason to hesitate, not a reason to grant broad. Granular or read-only on offer is a good sign.
3. Is it on your org's allow-list, and what can it reach once authorized? Prefer admin-approved servers. Picture the worst case: if this server misbehaved, what data could it touch with the scope you're about to grant? Grant only if that blast radius is acceptable.

The reconciling paragraph — "connected" is not "free rein"

Three things get conflated the moment a connector turns green. The gap between them is the safety model:

1. Connected ≠ acting. A live connector means Claude can reach the tool when a request calls for it — not that it's watching your inbox or changing things pre-emptively. It reaches when your ask requires it.
2. Read-scope ≠ write-scope. The lever you control. If you granted Calendar read-only, no phrasing makes it move a meeting — the capability isn't there. Most safety comes from what you decline to grant.
3. "In the loop" is a posture you enforce, not a guarantee you can skip. Consequential actions normally surface a confirmation, and you should explicitly instruct "propose, don't execute" so the pause is something you set, not something you assume. And "it paused / it ran" is never "it hit the right record" — that confirmation is Section 5's verify step, guarding the level's signature pitfall.

The loadout rule of thumb: equip the narrowest connector with the narrowest scope the task needs, prefer read and draft over write, treat every write grant as a decision you could name out loud — "I am letting Claude create a real event for this" — and notice the moment you start wishing it could run the whole multi-step job instead of one fetch-or-action at a time. That wish is the level-up signal (Section 13).

4. Preparation — Before You Engage

Nothing gets connected — and nothing gets typed — until this exists. At Chat level, Preparation was the Navigator's work: name the outcome, assemble context. At Connect level it is the Navigator's work plus the permission owner's — before you engage you decide not only what you want but what access you're willing to grant to get it. Engaging without that decision is exactly how broad grants get handed over by reflex. Four moves; the last two are new to this level.

1. Align with yourself — what outcome do you actually want? Name the outcome, not the question in your head. "I want to walk into Tuesday already knowing what I have to prep, with the deck and the unanswered emails surfaced" is an outcome. "What's on Tuesday?" is a fetch. The outcome decides which tools the job touches and what "done" looks like. If you can't state it in one sentence, the task isn't ready — that's a finding, not a failure.

2. Run a one-minute discovery on yourself. The self-interview, with the access dimension folded in:

• What's the real decision or deliverable this serves? (Tuesday's prep, not "tell me my calendar.")
• Which live tools does the answer genuinely require? — calendar, inbox, Drive, a custom system? If the honest answer is "none, I could paste it," this is still a Chat task (the Reach Test, Section 2).
• Does this run need to READ only, or also DO (write/change)? This sets your scopes. Most "what should I prep" runs are pure read.
• What's the Wrong-Action Cost? — plainly: how bad is it if this goes wrong on a real system? A wrong read costs you a re-check; a wrong write puts a real draft on the wrong thread or a real event on the wrong day. Set your effort and your review weight to that. (No prior level needed to grade this — it stands alone.)
• What do I know that the tools don't? (Which meeting actually matters; that "the deck" lives in a specific folder.)

3. Scope to the level's reach — write the access plan. This is the move that doesn't exist below this level. For each tool the run needs, decide and write down the minimum scope — knowing the consent screen may only offer a coarser bundle:

The rule: grant the least that completes the run, prefer read over write, and grant write only for the run that needs it (then audit it off, Section 3). If a connector's only available scope is broader than the run needs, that breadth is a cost you're now accepting knowingly — note it and revoke after.

4. Assemble the brief. Combine outcome + the tools-and-scopes plan + the context only you hold (which meeting is load-bearing, where the deck lives, what "prepped" means). This is the artifact this section produces.

Output of this section — shown, not asserted

Preparation is done when you can write this down. For the running work-week scenario:

OBJECTIVE (one line):
  Walk into Tuesday already prepped — surface what's on this week, flag the
  meeting that needs prep, and list the emails I still owe a reply, so I can
  act before Monday EOD.

WRONG-ACTION COST:  Low — this run only READS. (No event changed, no draft made.)

ACCESS PLAN (minimum scopes; coarser bundle accepted knowingly if that's all on offer):
  - Google Calendar — READ events            [no write this run]
  - Gmail           — READ + search threads   [no draft/label this run]
  - Google Drive    — READ files              [no create/copy]

CONTEXT ONLY I HOLD:
  - The Tuesday 2pm review is the one that matters; the rest are standing syncs.
  - "Prepped" = its deck is final, not a draft.
  - "Scope emails" = threads where a client is waiting on a yes/no from me.

WHAT I KEEP vs. HAND OVER (this run):
  - Claude: fetch + flag (read only).
  - Me: every reply, every calendar change, every decision.

That artifact — a one-line objective, an explicit minimum-scope access plan, and the human-only context — is what Section 5's workflow consumes at Step 1. The access plan is the new load-bearing line. A Level 1 brief that named no scopes was complete; a Level 2 brief that names no scopes is the over-granting pitfall already in motion.

5. The Workflow — Step by Step, Each Step Names Its OUTPUT

At Connect level the pipeline grows two new joints the Ask level never had: a scope grant at the front, and a verify-against-the-real-source check in the middle that now has teeth — because the thing being checked is no longer words on a screen, it's a read of, or an action on, a live system. The shape is otherwise the same discipline you carried up: each step produces an artifact the next one consumes.

The rule that makes it a workflow, not a vibe: no step without a named output. And one rule specific to this level — the grant is an artifact too. "I authorized Gmail" is not a finished step; "Gmail, read-only, revocable" is. If you can't name the scope you granted, you haven't scoped — you've just clicked Allow.

Recall the boundary, used identically everywhere: at Connect level Claude acts only within the scopes you grant, usually one tool/action at a time with you in the loop per consequential action; it can READ your real data and take actions you authorize — but only what each connector's granted scope allows. Steps 2 and 5 are where that boundary does its work.

The running example below is one task carried end to end: your work week. Claude is connected to your calendar, inbox, and Drive; you ask "What does my week look like, and what should I prep for?" — and it reads your real schedule, spots that Tuesday's 2pm review needs a deck still in draft, and flags two unanswered scope emails. (This mirrors the site's con-2 demo, where the connectors are labelled Calendar, Email, and Drive — "Email" is the demo's generic label for the Gmail connector. The demo answers "four meetings this week"; the module keeps that count and zooms in on Tuesday, the one that needs prep.)

Step 1 — Brief → a one-line brief naming the tools and the verb

Write one line for yourself first — now carrying two fields that decide everything downstream: which real tools it touches, and whether the job READS or also ACTS. That read-vs-act flag is the single most important word in the brief: it sets the scope you grant in Step 2 and whether Step 5 is a glance or a gate.

Bad:   "Help me prep for the week."
Good:  "Read my calendar, inbox, and Drive, and tell me what this week looks
        like and what to prep — especially Tuesday. READ-ONLY: I approve any
        reply or calendar change myself."

The "good" brief names exactly three tools (not "my Google account") and declares the job read-only. That declaration means a narrow grant next and a light review in Step 5 — there's nothing to approve because nothing writes. A brief that said "...and reply to the scope emails" would flip the verb to ACT, require a draft scope, and make Step 5 a hard gate. Decide the verb in the brief, not at the moment Claude offers to draft.

Step 2 — Connect (grant scope) → a scoped connector set (the grant ledger)

The step the Ask level never had, and where the dominant hat — Verifier-as-scope-owner — does its first job. Equip only the connectors the brief named, authorize the narrowest scope on offer, and write the grant down so you can later verify against it and revoke it.

The mechanics are the site's "Add a connector" flow, deepened: Settings → Connectors → pick a connector (Google Drive, Gmail, Calendar) or Add custom connector and paste an MCP server URL → sign in & authorize → review and (where the screen allows) scope down → save. Two clicks are load-bearing and most people skip them: read the scopes the connector requests (it often asks for more than your task needs), and take the narrower option where one exists — and where it doesn't, note the breadth you accepted so you remember to revoke it.

The output is not "three connectors are on." It's a grant ledger — the highest-weight artifact of this step, shown as the real thing:

Notice what the ledger refuses: draft on Gmail and create on Drive. The brief is read-only, so granting either would be over-scope — the signature pitfall, accepted for no benefit. The rule of thumb: grant the verb in your brief and nothing wider. (Custom MCP servers get the same treatment — scope to the single capability the job needs, and treat an unknown third-party server's request with more suspicion, because you're handing your data to whoever runs it. Vet it per Section 3.)

Step 3 — Fetch / act → Claude's fetched read, tagged to its source records

Now you ask — and Claude reaches the real data itself instead of waiting for a paste. This is the moment the bridge disappears.

Read my calendar for this week, plus any related threads in my inbox and
relevant docs in my Drive. Tell me what's on — especially Tuesday — and what
I need to prep; flag anything that isn't ready. READ-ONLY: don't draft, label,
or change anything. If something needs an action, propose it and stop for me.

The "stop for me" clause is not politeness — it's how you enforce staying in the loop per consequential action. Claude fetches across the three scoped tools and returns a read. The critical property of a good fetch: every claim is tagged to the real record it came from, so Step 4 has something to open. Here is the fetched read — one of the highest-weight artifacts, shown concretely:

THIS WEEK — 4 meetings. Tuesday is the one needing prep:
  Tue 09:30  Standup (15 min)
  Tue 14:00  Q3 Client Review (Acme)  ← the big one
  Wed 11:00  1:1 with Priya
  Thu 15:00  Vendor intro call
  (Thursday afternoon is otherwise open — your only real focus block.)

PREP FLAGS:
  ▸ The Tue 2pm Q3 Client Review needs a deck. The matching Drive file —
    "Q3 Review — Acme.gslides" (last edited Fri) — is still titled "DRAFT"
    with its last 3 slides empty.                         [Drive: Q3 Review — Acme]
  ▸ Two inbox threads look like they're waiting on YOU about scope, both
    unanswered:
      – "Re: Acme Q3 — scope change?"  (from Acme, 3 days)   [Gmail: thread #a1]
      – "Phase 2 — scope & SOW"        (2 days)              [Gmail: thread #b7]

PROPOSED (NOT done — read-only): I could draft replies to the two threads,
or propose a "Finish Q3 deck" hold. Approve to proceed.

Two things to read here. First, every flag carries a source tag in brackets — the hook Step 4 pulls on. (These bracketed tags are shorthand for "which specific email/file this came from." In real life Claude names the subject line, sender, or file title you can search for — you don't hunt for a literal "#a1"; you need enough to find and open the exact item.) Second, Claude proposed the writes and stopped — it did not draft or schedule, because the grant was read-only and you said stop. That stop is the boundary holding.

Step 4 — Verify against the real source → a source-checked result

The verify-reflex from Ask level, re-aimed at a higher-stakes target. At Ask you verified a fact against an external source. Here you verify that the read hit the right record — because the new failure isn't a wrong fact, it's Claude confidently pointing at the wrong object: yesterday's version of the deck, a same-titled thread, an event on the wrong day.

The procedure: for each tagged claim, open the actual record and confirm three things — right object, right state, right account. The output is a source-checked result — a highest-weight artifact, shown:

That last row is the catch this step exists for: a plausible, source-tagged claim that's wrong because the model's narration of your inbox drifted from your inbox. Asking Claude "are you sure?" would not have caught it — it was sure. Opening thread #b7 caught it. The same-titled deck in row 2 is the wrong-record trap defused early. (Verification of reads vs. actions in full: Section 8.)

Step 5 — Review / approve → an approved (or rejected) action + the executed result

For a read-only run, this step is light: you've confirmed the read, you act on it yourself. For any write, this is the hard gate the whole level is built around — the explicit go/no-go on a real-world action.

In the running example the brief was read-only, so review is a decision about what you now do, informed by Step 4:

• Finish the deck — yourself, today (the deck is real and yours to write; note Claude couldn't edit it in place anyway).
• Reply to thread #a1 — real and open; you'll answer before Monday.
• Thread #b7 — Step 4 showed it's an invoice, not a scope thread. You route it normally and drop it from the prep list. Had you let Claude "helpfully" draft a scope reply, you'd have answered a question nobody asked — the exact "trusting an action because it ran" failure.

Now suppose you do upgrade this run to act on #a1. You'd raise the Gmail grant to include draft (the connector cannot send — only draft), re-ask Claude to draft the reply, and the review becomes an artifact you approve before anything is created:

PROPOSED ACTION — Gmail draft (NOT sent — the connector only drafts; awaiting approval)
  Reply on:  "Re: Acme Q3 — scope change?"  [thread #a1 — verified genuine in Step 4]
  To:        the thread's existing participant (Acme), this thread only
  Draft:     "Hi — yes, we can absorb the added reporting view in Q3. It pushes
              the Phase-2 start by ~1 week; I'll confirm the date after Tuesday's
              review. — [you]"
  Scope used: Gmail create-draft (no send capability exists).

  [ Approve & create draft ]   [ Edit ]   [ Reject ]

That approval card is what an approval moment looks like in principle — the exact on-screen form varies by client. The point isn't the buttons: Claude shows you the draft and the target and waits; you don't approve something you can't see.

You approve create draft, then open your inbox and press send yourself — the irreversible verb is yours by design, not just by discipline, because the connector has no send. The output of this step is the approved action and its executed result (the draft now sitting in your Drafts), or the explicit rejection. Either is a finished step; "Claude probably handled it" is not.

Step 6 — Capture → a saved artifact + a deliberate scope decision

Capture has the same job as at Ask level — lift the durable part out of the transcript — plus one move unique to this level: right-size the grant you opened. A connector left wide open after the job is the latent version of the over-scope pitfall.

For the running example, capture three things:

• The prep list (finish the deck, answer #a1, route #b7 as the invoice it is) into your notes or task list — the walk-away artifact.
• The trust tags from Step 4 (every flag ✓ except #b7, which was a misread) — so you remember the verify caught something.
• The scope decision: Calendar/Gmail/Drive read scopes are useful weekly → keep; any temporary Gmail draft scope you opened → revoke now (re-grant on the next run that needs it). Write the decision; don't leave it implicit.

The pipeline in one breath: scoped brief → grant ledger → source-tagged fetch → source-checked result → approved action → saved artifact + right-sized grant. The two joints that make it Level 2 and not Level 1 are the grant at the front and the open-the-real-record check in the middle — everything between is the Ask discipline, now pointed at your live world.

6. Goals → Considerations Map

Three recurring goals bring people to Connect. They differ on one axis that bends the whole workflow: how far past READ the job goes. The scope you grant in Step 2 and the weight of the gate in Step 5 should follow the goal, not be set by reflex.

The tell that you've matched goal to variant: a read run that ends with you certain you saw the live record (not last week's), an act run that ends with exactly one real-world change you explicitly approved against the right object, and a standing-connection run that ends with a connector scoped so narrowly that even a misfire next month can only do the one small thing you allowed. In all three the boundary holds: Claude acted only within the scope you granted, with you in the loop on anything consequential.

7. Connect the Components — Patterns & Outliers

A Connect-level engagement is not one fetch and one answer. It's a chain: Claude reads your calendar, cross-reads your Drive, scans your inbox, and stitches a picture — and then, if you authorize it, prepares an action. Each link is a place where the real source and Claude's account of the real source can diverge. Reading the engagement as a whole means holding the whole chain in view, not grading the final paragraph.

At Chat level you tracked claims. Here you track two things, because the level does two: what Claude reports it found (reads) and what Claude proposes or did (actions). The artifact that holds both is the verified-actions ledger — the L2 evolution of L1's verified-claims list, with two new columns the new reach forces: which source/scope it came from, and checked against the real source — yes/no. Keep it as you go; it turns four tool calls into one coherent read you can defend.

Here is the ledger for the running scenario, captured mid-engagement, before you approve anything. Every row traces back to the Step 3 fetched-read artifact — nothing appears here that Step 5 didn't surface:

The discipline that makes it a ledger, not a vibe: no row leaves "checked vs. real source?" blank for anything load-bearing. A read you didn't open is a rumor; an action you didn't trace to a record is a hope. That column is the Verifier-as-scope-owner job in one box.

Patterns — promote them

A pattern is a finding that survives contact with the real source and recurs. Promote it two ways:

• Promote within the engagement. Rows 1 and 2 agree across two tools — the calendar says the review is real, the Drive says its deliverable is unfinished. Two independent sources pointing the same way is the strongest signal you get here. That converged finding becomes the spine of the plan (Section 9): the 2pm review is real and under-prepared.
• Promote across engagements. When the same shape recurs — "the meeting Claude flags as under-prepped is the one whose deck is still a draft" — capture it as a standing instruction so the next run starts already doing it. A pattern promoted into the brief is reach you don't have to re-request. (At this level a practical home for such a standing instruction is a Project's custom instructions — a reusable starting context you set once; availability varies by plan. If that's not available to you, the fallback is just as good: keep the instruction in your notes and paste it into the next run.)

Outliers — interrogate them

An outlier is anything that doesn't reconcile against the real source, or that reaches past the scope you granted. At Connect level the outliers are concrete and checkable, because there's a real record to check against. Five drift signals specific to this level:

1. The source-vs-summary gap. Claude's prose says one thing; the actual record says another. Row 3 is the live example: Claude reported "two scope threads," but opening them shows one is scope and one is a mis-tagged invoice. This is the single most common L2 outlier — the model's narration of your data drifting from your data. Catch it by opening the record, not re-reading the summary.
2. The silent-empty-result. A fetch returns nothing — no matching file, no events — and the model reasons forward as if it had. A smooth summary with no specifics you can click into is an outlier, not an answer.
3. The scope-reach attempt. Claude proposes something outside what you granted — "I'll send the client a note," "I'll move the meeting" — when you connected read-only calendar and no draft scope. Treat any action needing a scope you didn't grant as a red flag about the plan, not a permission to top up on reflex. (Boundary, reused: Claude acts only within the scopes you grant, one tool/action at a time, with you in the loop per consequential action.)
4. The stale-record drift. What Claude read is real but no longer current — an older indexed view, or the event moved after the fetch. True at fetch-time, false at act-time. The tell: a gap between when it read and when you're about to act; re-fetch before any consequential action.
5. The wrong-record match. Claude found a file/thread/event matching your words but not the one you meant — the same-titled "(old)" deck (row 2), last month's "scope" thread. Right shape, wrong identifier — verify the title, the date, the participant, not just that something matched.

How to track all this without ceremony: the ledger above is the tracking. Patterns get promoted out of it (into the plan, or the brief); outliers get a follow-up turn or a refusal-to-approve. Three turns of fetching become one coherent, defensible read.

8. Qualitative vs Quantitative — Results Vary by Case

Connect produces the same two output types as every level — a quantitative/factual half (what's on Tuesday, which file, which threads, what an action did) and a qualitative/judgment half (what to prep, which is the real priority, whether a draft reply is any good). They're verified in opposite ways, and misfiling one as the other is exactly how a wrong action lands on a real system.

The level adds a third surface the lower one didn't have: the action itself is a verifiable fact. "I created the draft," "I added the event," "I labeled the thread" — each is a claim about the world, checkable against the same real source you read from. This is the surface people skip.

Results vary by case — and now the variance has teeth. At Chat, a re-run that drifts costs you a worse paragraph. Here, the same prompt run twice can fetch different records (your inbox changed, the search ranked a different thread first) — and if you're acting, that's the difference between drafting to the right thread and the wrong one. A good result once is not a guarantee, which is why you verify by type, against the source, every consequential time.

The verification procedure — and the one principle to internalize

There is one principle this level turns on, stated once with full force:

The model cannot grade its own homework. Asking Claude "are you sure you got the right file?" or "is that really the scope thread?" is not a check — if it grabbed the wrong thing, "yes, I'm sure" is the most likely reply, and it will often re-cite the same wrong record to "prove" it. Verification must come from something that isn't the model: you open the real source. Everywhere else in this module that this matters — Step 4, the pitfalls — it's the same principle; don't re-argue it, just apply it.

Two corollaries follow:

• "It ran" verifies the plumbing, not the outcome. A tool call returning success means the call executed, not that it hit the right record with the right content. Calendar happily creates an event on the wrong Tuesday; Gmail happily drafts a flawless reply on the wrong thread. After any action, go read the thing — open the event, open the draft in your Drafts folder — and confirm the record, the target, the content.
• For a write you can't easily re-open, verify on the way in. Most writes at this level are re-openable (a draft sits in Drafts; an event sits on the calendar — go look). But where re-reading after the fact is awkward (a one-way action through a custom MCP server, say), shift the rigor forward: confirm the exact target in the proposal before you approve, since you may not get a clean after-the-fact read. Verify the input when you can't easily verify the output.

For a factual read or action that matters: verify it against the source, outside the model's narration. For a judgment that matters: first confirm the facts under it are real (a judgment built on a misread is worse than a guess — it wears the costume of grounding), then attack the reasoning: "What has to be true for 'finish the deck first' to be right? Which assumption is shakiest?"

Worked catch — a plausible-but-invented item, caught against the real source.

In the running scenario, Claude returns:

"I've found the Q3 deck — still a draft. I've also lined up the two scope threads. The second, 'Phase 2 — scope & SOW,' is Dana at Acme confirming the revised statement of work; I can draft an acceptance."

Three things sound right and one is invented — and only the source tells them apart.

• The wrong move: "Great — is that the right thread?" → "Yes, it's the SOW acceptance from Dana." (The model confirming itself. Worthless — see the principle above.)
• The right move: open thread #b7 in Gmail (the real source).
  • Thread #a1 is a genuine scope question from Acme. Real. ✔
  • Thread #b7 is not "Dana confirming a revised SOW." It's an invoice notification that merely contains the word "scope" in a footer. There is no SOW, no Dana, no acceptance to send. The model pattern-matched a plausible business email into a clean narrative and fabricated a sender and a subject that don't exist in the record.

Verdict: discard the "acceptance" idea entirely — approving it would have created a draft confirming an agreement that doesn't exist, on a thread that isn't even about scope. Keep #a1's draft, pending your edit. The fluent specificity ("Dana," "revised SOW," "acceptance") was the tell, not the proof — and at this level the invented item was one approval away from a real, wrong draft addressed to a real person.

When in doubt, the rule is mechanical: read before you trust, re-read after you act, and never let the model grade its own homework.

9. Recommendations → Plans

The engagement has to leave behind something you act on — not a transcript of fetches, but a decision about your week you can stand behind, and a sequence for executing it that's explicit about who does what. Two moves turn the verified-actions ledger (Section 7) into that.

1. Assemble recommendations — tagged by trust

Walk the ledger and write each finding as a plain instruction to yourself, tagged with how much you trust it. The tags are tighter than at Chat level, because some recommendations are actions on real systems — so the tag says not just "how sure" but "safe to let Claude prepare, or mine to keep":

• Act on it — verified against the real source; low-consequence or already confirmed. Claude may prepare it within granted scope; you still glance at the result.
• Act after I confirm X — pending one external check or one human edit before it touches anything real.
• Hold — mine to keep — a consequential verb (send) you do not hand over; you keep the keystroke.
• Discard — didn't survive verification against the source.

For the running scenario, assembled from the ledger:

2. Line them into a plan — sequence, hand-over split, reusable context

A plan sequences the recommendations and, for each, names what you hand to Claude (within which scope) vs. what you keep, plus the reusable context so next week starts where this one ended. The hand-over split is the heart of the level — where you exercise the scope-owner hat one action at a time, in the loop per consequential action.

The hand-over in one line: Claude does the looking-up (it found the review, the draft deck, and the real scope thread across three tools so you didn't copy-paste between them) and prepares the consequential action (a draft reply, a proposed time block) — but you keep every keystroke that changes a real system: the send (which the connector can't do anyway), the confirmed calendar create. That is the precise trade the level buys, and the precise trade it does not exceed.

Reusable context to capture (so next Monday starts ahead):

• The promoted pattern (Section 7), as a standing instruction: "When you read my week, cross-check each meeting's deliverable against Drive and flag drafts; list threads that look like they need a reply, but open each to confirm it's really what its subject suggests before you summarize it."
• The scope set that worked and didn't over-reach: Calendar (read + propose), Gmail (search + draft, no broader access), Drive (read + search) — narrow enough that no single approval could change a meeting or touch a file on its own.
• One line of trust memory: "Claude once mis-narrated a mis-tagged invoice as a scope acceptance — always open the thread."

The walk-away artifact is concrete: a prioritized plan for the week (finish the deck, send one real reply, hold Thursday), every consequential action tagged for who executes it and verified against the real record, one fabricated action caught and dropped, and a reusable brief + scope set that makes next week's "what should I prep?" faster and safer. That's a single ask turned into a repeatable, scoped operating rhythm — the Middle Manager's actual job.

10. Worked Examples

Three runs through the whole template. Example A carries the running work-week scenario end to end (a pure read). Example B is a single authorized write on Gmail (the everyday high-stakes case — and the proof that Claude drafts, you send). Example C is a custom MCP server write (the highest-stakes combination — a non-Google tool, an action — to show the spine holds). Every fenced block is either what you'd type or what comes back; the scope lines are the artifacts, not decoration.

Example A — Read across three tools (the running work-week case, end to end)

The whole point of Connect: you stop being the bridge. Claude reads your real calendar, inbox, and Drive in one pass and hands back a prep list you can act on. Nothing is written — a pure read, the right place to start trusting a connector.

Step 1 — Brief.

Objective: "Tell me what this week actually looks like and what I need to prep —
especially Tuesday — read from my real calendar, inbox and Drive, don't guess."
Answer shape: a short prioritised prep list, each item traceable to a source.
Wrong-action cost: LOW — this run only reads; nothing changes.

Step 2 — Connect (grant scope). Settings → Connectors → add the three Google connectors → authorize → scope each to read (or accept the narrowest bundle on offer):

GRANTED SCOPES (this engagement)
  Calendar  → read events       (NOT: create / update / delete)
  Gmail     → read + search      (NOT: draft / label)
  Drive     → read file content  (NOT: create / copy)
Why read-only: the task is "tell me," not "do." A write scope here is power I
have no use for this run — so I don't grant it.

Step 3 — Fetch. One bounded ask, traceability demanded up front:

Read my calendar, inbox and Drive. For this week — especially Tuesday:
1. List my meetings with times.
2. For each, flag anything I still need to prepare — and say which file or
   email tells you that.
3. Surface any unanswered emails tied to those meetings.
Cite the specific event / file name / sender for every claim. Don't infer
beyond what's actually in the tools.

What comes back (the con-2 result, sources exposed): four meetings this week; Tuesday 2pm Q3 Client Review is the one needing prep, because "Q3 Review — Acme.gslides" (Drive) is still a DRAFT; two threads look like they're waiting on a scope reply ("Re: Acme Q3 — scope change?" and "Phase 2 — scope & SOW"); keep Thursday afternoon clear.

Step 4 — Verify against the real source. The signature move, non-negotiable — the answer ran, but did it hit the right records? Open the artifacts, don't ask Claude if it's sure:

The catch: one item read plausibly but was a misread of the record — the model's narration drifting from your inbox. A clean run is not a correct run; only the source is.

Step 5 — Review/approve. Nothing to approve — read-only by design. Review = accept the verified items, strike the invoice. Corrected prep list: finish the deck, answer the one real scope email (#a1), route the invoice normally.

Step 6 — Capture. Lift the prep list into your task tool; save the prompt and the read-only scope set into a reusable Project (or your notes) so next Monday starts pre-scoped. Capture records three things: the result, what you verified it against, and the reusable scoped prompt.

The run in one breath: objective → three read scopes → fetched prep list with sources → verified against the real calendar/Drive/inbox (and caught one misread) → corrected list → saved for next week.

Example B — Take one authorized action (a single Gmail write — and the send stays with you)

Now the stakes change: a mistake lands on a system. The discipline: narrow scope, propose-before-commit, verify the actual record after — and note the connector cannot send, so the irreversible verb is yours by design.

Brief: "Draft a reply to the open Acme scope thread (#a1) using the answer I'll provide. I approve the exact text, then I send it from my inbox." Connect: add one scope to Example A's read-only set — Gmail → create draft. There is no send scope to grant; the connector composes drafts only. Narrowest scope that does the job. Fetch/act, propose-first:

Draft a reply on the open "Re: Acme Q3 — scope change?" thread (#a1) from Acme.
Use this answer: [your 3 bullet points]. Match the thread's tone. Show me the
full draft and the recipient BEFORE creating anything — propose, don't execute.

Review/approve — the gate. Read the draft and the recipient (a wrong recipient is the classic real-system mistake):

DRAFT — review before it's created
  Reply on: "Re: Acme Q3 — scope change?"  [thread #a1 — verified genuine in Ex. A]
  To:       the existing Acme participant on this thread (not a wider alias)
  Body:     [matches my 3 points, tone fits]
  → Approve → Claude creates the DRAFT. It cannot send.

Execute + verify against the real source. Claude creates the draft; you open your inbox, read it once more, and press send yourself. Then open Sent and confirm the message is there, to the right person, with the right body. "It created the draft" is the model's word; the Sent folder is the evidence. Capture: note the thread is now answered (so next week's Example-A run shouldn't re-flag it); revoke the draft scope until the next run that drafts.

Example C — A custom MCP server write (the highest-stakes combination: non-Google tool + an action)

Connectors aren't only Google, and the riskiest move is a write through a tool whose behavior you can't eyeball as easily. The same six steps still run — and Section 8's "verify the input when you can't easily verify the output" earns its keep here.

Brief: "In our internal issue tracker, open one new priority-2 ticket for the billing bug I describe — then I confirm it landed." Connect: Settings → Connectors → Add custom connector → paste the tracker's MCP server URL (from IT) → authorize → vet and scope it:

VETTING (Section 3 checklist)
  Operator: our own IT (org-internal) — known. ✓
  Scopes on offer: read issues + create issue (no delete/bulk-edit). ✓ narrow enough.
  On the org allow-list. ✓
GRANTED SCOPE
  Issue tracker → create a single issue (+ read to confirm)   (NOT: edit / close / bulk)

Fetch/act, propose-first:

Propose a new priority-2 ticket in the billing component: title, description,
and the exact fields you'll set. Do NOT create it yet — show me the proposal.

Review/approve — verify the INPUT, because the output is awkward to un-create. Read the proposed title, component, priority, and fields before approving — this is the "verify on the way in" case from Section 8, since a created ticket isn't as trivially re-openable as a Gmail draft. Approve only the exact thing. Execute + verify against the real source. Claude creates the ticket; then open the tracker UI and confirm the ticket exists, in the billing component, at P2, with the text you approved. If it landed in the wrong component, that's a real wrong action — caught because you opened the tracker, not because the call returned success. Capture: save the working request phrasing; revoke create scope if this was a one-off, keep read if you'll query the tracker weekly.

What all three share: the scope grant is an explicit artifact, the action is verified against the tool itself (never the model's confidence), and every write is gated behind a propose-first review with the irreversible/awkward-to-undo verb kept in human hands. That is the level, made concrete.

11. Pitfalls — How It Goes Wrong

Connect breaks in ways Chat never could, because now a mistake can touch a real record. Two failure classes are new: scope (you granted the wrong amount of power) and false-success (the action ran but didn't do what you think). Each fix restores one hat — and the Verifier hat now includes its scope/permission-owner role.

The one reflex under all of them: a connector grants power and returns claims — scope the power to the task, and verify the claim against the tool, never against the model that made it. "It ran" is not "it's right"; "it can see it" is not "I framed it"; "I granted it once" is not "I should still grant it."

12. Practice + Self-Check

Reps on the two new muscles: scoping a grant, and verifying an action against the real source. About 15–20 minutes. The rubric below is the instructor and is gradable from this document alone.

The starter task (do it now)

Use a low-stakes, read-only slice of your own world — your real week is ideal (it's the running scenario). Do not start with a write; earn the read first.

1. Brief (2 min). Write the one-line objective and the wrong-action cost before opening Settings. For a read-only run the cost is low — name that, because it's why a narrow scope is safe and a broad one needless.
2. Connect, scoped (3 min). Settings → Connectors → add one or more connectors → authorize → take the narrowest option on offer (read-only) → save. Write the granted scopes down — that list is an artifact you'll grade. (If the only option is a broader bundle with no per-permission toggle, that's normal — accept it knowingly and plan to revoke.)

   Granted for this run: Calendar=read, Gmail=read/search, Drive=read.
   Withheld (didn't need): draft, label, create, update, delete.
   

3. Fetch, with traceability (2 min). Ask one bounded question and require sources:

   Read [the tools]. Answer [my question]. For every claim, cite the specific
   event / file / sender it came from. Don't infer beyond what's in the tools.
   

4. Verify against the source (4 min). Pick the single most load-bearing item and open the actual record — the event, the file, the thread. Confirm or correct. Do not verify by asking Claude if it's sure.
5. (Optional, only if ready) one gated write (3 min). If your connector lets you add a write scope (e.g. Gmail create-draft), do so for this one task; if it's bundled with other permissions, accept it knowingly. Ask for a draft/proposal + target shown before commit, approve the exact thing, then open the real record (Drafts / the file) to confirm the effect. Either way, practice propose-then-confirm and the cleanup.
6. Capture + clean up (2 min). Save the result and the scoped prompt for reuse. Then review your connector scopes and revoke anything you won't need again — closing the loop is part of the rep.

Self-check rubric (gradable from this document alone)

Scoring. 7/7 (or 6/6 if you skipped the optional write) — you ran the level; read Section 13. 4–5 — solid; the usual miss is #2 (took the default bundle without noting it) or #4 (verified by re-asking the model). 3 or below — you treated the connector as magic: you over-granted (#2) or trusted "it ran" (#4/#5). Re-run and force a narrow scope and one real source-check.

13. Level-Up / Exit Criteria — Bridge to the Next Class

You don't graduate by feeling in control of your connectors — over-granting feels efficient right up until it isn't. The gate is behavioural.

The exit gate — you've mastered Connect when you consistently, unprompted:

A blunt self-test: could a colleague look at your connector list and your last run and see exactly what power you granted, why, and how you confirmed the result landed on the right record? If yes, you're out of Middle Manager. The marker worth naming: at the entry you either grant broad and trust "it ran," or you grant nothing and stay the copy-paste bridge; at the exit you've calibrated — you grant exactly the scope a task needs and verify exactly the records that matter. That judgment is the whole class.

What the gate does NOT require: you haven't failed because you still drive each fetch or action one at a time with yourself in the loop — that's the level's design, not a shortcoming. You haven't failed because you can't yet hand over a whole multi-step job unattended — that's the next class. Hitting those walls is graduation, not failure.

The signal you've outgrown it

One unmistakable tell — a specific, repeated wish:

"I keep wishing it could just run the whole multi-step job end to end — read the calendar, draft the replies, prep the deck, propose the follow-up — instead of me approving one fetch or one action at a time."

When approving each step individually becomes the slow part of the job — when you trust the scoping and the verifying enough that the in-the-loop-per-action rhythm is the bottleneck — the class has run out of room. That wish is the core thesis again: the more you let Claude reach, the more you can hand over. You've let it reach your tools; now you want to hand over the sequence, not just the single reach.

The hand-over you're trading up for

The catch worth naming before you go: at Connect you verify each action as it happens. At Delegate, work happens in sequence before you see it — so the discipline shifts from gating each action to setting up the space, the skills, and the review checkpoints well enough that you can trust a run you didn't watch. The scope-owner reflex you built here is the prerequisite: you learned to grant exactly enough power and verify exactly the right records, and Delegate spends that judgment on a job with more moving parts and a longer leash.

Hand-off

Next: hand over a whole job, not one action — give Claude a standing space and let it run the multi-step work while you review. That's Cowork.

Carry three things forward: the scoping reflex (a delegated agent runs on the scopes you set up — grant narrow, or a multi-step run inherits a wide blast radius), the verify-against-the-source reflex (it matters more when you review after a sequence ran, not during it), and one real connected workflow from this level — bring the work-week run you scoped and verified here, and let Delegate be the thing that runs the whole Tuesday-prep sequence end to end instead of you approving each fetch. Same reach, same scope discipline — now pointed at a job instead of a single action.