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

Level 1 — Ask (Chat)

The entry class. Verb: Ask. Org-rung: Beginner. One expert who has read almost everything, in a single conversation. You bring the context, it brings the reasoning, and you carry the result back out into the world yourself. Master this class and every level above it inherits the two muscles you build here: framing an intent and verifying a result.

Before you start — three things to read once

These get used on every page below. Read them now and the rest reads cleanly.

The four-level ladder (where you are)

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

"MCP" is short for Model Context Protocol — the plumbing that lets Claude reach into a tool like your calendar. You don't need to understand it yet. You only need to know that reaching your real tools is Level 2's job, not this one's.

The three jobs (your hats)

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

At Level 1, the Verifier hat dominates — because the level's signature failure is trusting a confident-but-wrong answer, and mistakes here are cheap, which makes it the right place to build the reflex. But you still wear all three: you Navigate when you frame, you Conduct when you iterate. Later levels lean harder on Navigator and Conductor as the stakes of each action rise. The vocabulary is the connective tissue of the whole ascent; learn the three hats here and you carry them up.

Mini-glossary (plain definitions, used throughout)

• The window (context window): everything Claude can "see" in this one conversation at once — your messages plus its replies. It has a size limit, so in a very long chat the earliest details can fall out of view. It is per-conversation: open a new chat and that window is empty.
• Hallucinate: AI jargon for when the model states something made-up — a number, a citation, a date — in the same confident tone it uses for things it actually knows. The confidence is not a signal of truth.
• Training cutoff: the model learned from data up to a fixed point in time and then stopped. Without a live tool, it cannot know what changed after that point. You usually won't know the exact date and the model may not either, so the practical rule is: treat anything that could have moved in the last year or two as possibly stale.
• Artifact / Project / connector: features you'll meet in Section 3 — Equipment, where each gets a plain definition and a "where to find it" cue.

Availability note: the features named in this module (file upload, web search, Artifacts, Projects, optional memory) can vary by plan, by device (web / desktop / mobile), and by account settings. If you don't see a button described here, that's why — not a mistake on your part.

0. Class Card — at a glance

In ten seconds: Chat is the cheapest, fastest, lowest-risk way to reach the model. You trade away reach — it cannot touch your real files, inbox, or calendar — and in exchange you keep total control: nothing happens in your world unless you do it. That trade is exactly why Chat is safe to use on anything, including work you'd never let a tool near.

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

The class in one line: Chat is one expert who has read almost everything, in a single conversation that lasts exactly as long as the window stays open.

The plain definition

You type, it answers. You're talking to a model that has absorbed an enormous span of text and reasoning — code, law, finance, biology, the shape of a good memo — and can bring it to bear on whatever you put in front of it. Picture asking "What's the difference between a budget and a forecast?", getting a clean answer, then adding "Now assume I run a finance team — go deeper" and watching the answer sharpen into variance tracking, rolling forecasts, and sandbagging. That is the whole mechanic. The class is built on one move: Ask.

It feels like having a brilliant colleague you can ask anything. The class is simple. Playing it well is not.

The thinking that makes it work

Three practices separate a senior operator from someone treating this like a search box.

• The answer is only as good as the frame. Claude knows almost everything in general and nothing about your specific situation until you say so. In the example above, nothing changed but one clause — "assume I run a finance team" — and the altitude of the answer changed completely. Framing is not politeness; it is the input that determines the output. (How to do it deliberately: Section 4 — Preparation.)

• You hold the Verifier hat. Chat is articulate even when it is wrong, and articulate-when-wrong is the single most expensive failure mode of the class. So you supply the doubt: ask for the reasoning, the source, the check. (The actual procedure for verifying: Section 8.)

• Reach is the currency you spend. The thesis of the whole Ascent: the more you let Claude reach, the more you can hand over. Here you've let it reach almost nothing of yours — only the window. So you hand over almost nothing: you get advice; you remain the one who acts.

The boundary of the class — stated precisely (and used identically everywhere below)

Be exact here, because a loose version of this boundary causes more confusion than anything else in the module. The precise statement is:

At Chat level, Claude can READ (it can reason over what you paste or upload, and — if web search is on — read public web pages) and it can PRODUCE drafts. It does not WRITE TO or ACT ON your private systems on your behalf. It will not send the email, change the file in your Drive, or put the meeting on your calendar.

That is the line. Note what it does not say: it does not say "no tools ever fire" (web search is a tool, and it does fire) or "nothing executes" (an Artifact can run code in a sandbox). What it says is narrower and true: Chat advises and drafts; it does not act on your private accounts. Concretely:

These are not bugs. They are the boundary of the class — and that boundary is exactly what Level 2 moves.

Why mastering the simplest class matters most

MCP, Cowork, and Code don't replace the ask — they amplify it. A vague prompt that gets a mediocre answer in Chat becomes a vague prompt driving an agent in Code: same flaw, far larger blast radius (how much damage a mistake can do). A weak Verifier reflex that lets a wrong fact slide in a chat becomes a weak reflex that ships that fact into a real action two levels up. So the promise of this level is precise:

Master the Ask and the Verify-reflex here, on the class where mistakes are cheap and reversible, and Levels 2–4 inherit both for free.

The rest of this module is reps on those two muscles.

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. The lesson is to spend them where they pay off — not to reach for the most powerful-looking tool every time.

Every level can technically answer almost any question. That is exactly the trap. A wizard can swing a sword; it's just a bad use of what you spent becoming a wizard. The skill is not "can Chat do it" — it's "is Chat the right spend for this task."

Chat is the cheapest, fastest, lowest-blast-radius way to reach the model. You pay for that cheapness in three currencies: context (it knows only what's in the window), reach (it advises, it can't act on your systems), and continuity (each chat starts cold by default). Allocate well and Chat is the highest-leverage move you have. Allocate badly and you under-spend (grinding by hand what one good prompt would crack) or over-spend (reaching for connectors and agents when a paste-and-ask would have done it in thirty seconds).

The master gate: the Wrong-Answer Cost Test

There is one spine to carry. Everything else hangs off it. Before deciding how to use Chat — or whether Chat is even the right class — ask: if this answer is confidently wrong and I act on it, what does it cost me? That number sets everything downstream: how much context you invest, how hard you verify, and whether Chat is the right class at all.

The point is not "always verify hard." It's proportion — calibrate effort to stakes. Three sub-moves fall out of the gate:

• Context is the lever (proportional to cost). The biggest predictor of quality is not clever wording — it's how much relevant, specific situation you put in before asking. Higher cost earns more context. Most "Claude gave me a generic answer" complaints are really "I gave Claude a generic situation."
• Confident ≠ correct (verify proportional to cost). Fluency is constant; accuracy is not. There's no built-in "I'm unsure" tell. The higher the cost, the more of the answer gets a real check. (Mechanics in Section 8.)
• Match answer shape to the decision. Decide up front what you need and ask for it: a one-line verdict, the reasoning, options with trade-offs, or a draft artifact. (This is the canonical answer-shape list; Section 5 reuses it.) Under-asking wastes the model's reach; over-asking buries the answer you needed.

The decision: stay in Chat, step up, or just do it

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

Where Chat ends and Connect begins (the one boundary that matters here)

• Chat (Ask): you are the bridge between Claude and your world. You paste context in; you carry the answer out; you take every action. Claude reasons, you reach. Maximum control, minimum reach.
• Connect / MCP: you hand Claude the keys to a tool so it reaches your real data itself — reads the actual calendar, the actual file. You stop being the copy-paste bridge. You trade a slice of control (it now touches your stuff, under scopes you grant) for reach you no longer broker by hand.

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, becomes the bottleneck. Until then, stay in the cheapest class that can do the job.

3. Equipment — the Tools You Equip at This Level

At Chat level your character has no hands on your private world. What it does have is a set of pieces you bolt onto a single conversation to change what the ask can stand on. None of them give Claude its own agency on your accounts; every one is you loading the workbench before you ask. Treat them as a loadout, not a feature list to switch all on — each changes the ask in one way, each carries a cost, and a couple change what data leaves your hands.

The loadout

The memory model, reconciled once (read this; it resolves an apparent contradiction)

Three different things get called "memory." Keep them straight:

1. In-chat context — the window. Within one conversation, Claude sees the earlier turns. This is real and always on. It does not survive into a new chat.
2. Project shared context — a Project gives every new chat in it the same starting material (instructions + knowledge-base files). This is not memory of past chats' turns; it's a shared starting point you set up deliberately.
3. Optional cross-chat memory / preferences — some accounts offer a separate, opt-in setting that carries a profile or preferences between conversations. The default this whole module assumes is: no memory between chats. If you've never turned such a setting on, assume it's off and everything here holds. If it might be on, know that, because it silently shapes answers.

So: "does Chat remember my context?" — By default, no, not across conversations. A Project gives new chats a shared starting context; a separate opt-in feature may add cross-chat memory. Don't assume; check what's enabled.

What each piece changes about the ask

• No equipment — stands on training alone. Fast, broad, bounded by the cutoff and by what you typed. The right default more often than people think.
• + Upload / Project — stands on your material. From "what an expert generally knows" to "what an expert makes of my situation." The single biggest upgrade at this level.
• + Web search — stands on current public material and can show source links. You trade a little speed and noise for currency.
• + Artifacts — the answer changes shape from talk into a thing you can hand on and iterate.

The rule of thumb: equip everything that grounds or shapes the ask, and notice the moment you start wishing you could equip a hand that reaches your real tools. That moment is the level-up signal (Section 13).

4. Preparation — Before You Engage

Nothing gets typed to Claude until this exists. Preparation is the Navigator's work, and it's what separates a framed task from a hopeful one. Three moves.

1. Align with yourself — what do you actually want out of this? Before the engagement, name the outcome you're after, not the question in your head. "I want to be able to decide our reforecast cadence and defend it to my board" is an outcome. "Tell me about forecasting" is a topic. The outcome dictates the answer shape (Section 2's list: verdict / reasoning / options / draft) and the bar for "good." If you can't state the outcome in one sentence, the task isn't ready — that's a finding, not a failure.

2. Run a one-minute discovery on yourself. A quick self-interview surfaces the context Claude can't infer:

• What's the real decision or deliverable this serves?
• Who's the audience, and what's the Wrong-Answer Cost?
• What do I know that the model can't (my numbers, constraints, house style)?
• What would make an answer useless to me? (Often the fastest way to find the constraint that matters.)

3. Scope to the window. Decide what goes in and how:

• Paste inline the few load-bearing facts the reasoning hinges on — the numbers, the hard constraints, the actual paragraph in question. These are certain to be read.
• Attach as a file long reference material (a report, a transcript) so it doesn't drown the question.
• Cut anything that wouldn't change the answer. Over-stuffing makes the answer regress to a generic summary of your paste instead of an opinion on your problem.

Output of this section: a written one-line objective + the minimum context assembled and sorted into paste-vs-attach. That is the thing you hand to Section 5.

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

A great ask is a short pipeline where each step produces something the next consumes. Skip a step and you don't get a faster answer — you get a confident-sounding one you can't trust and can't reuse.

The rule that makes it a workflow, not a vibe: no step without a named output. If a step didn't produce its artifact, you haven't finished it — you've just talked.

The running example below is one task carried end to end: a non-finance founder deciding how often to reforecast.

Step 1 — Frame → a one-line objective

Write one line for yourself first: the decision/deliverable, the audience/stakes, and the answer shape. (This is the objective from Section 4, restated as the workflow's first artifact.)

Bad:  "Tell me about budgets vs forecasts."
Good: "Help me decide how often we should reforecast. Output: a recommendation
       with the 2-3 reasons behind it, written for a non-finance founder."

Every later step measures against this line — "is the answer good?" is unanswerable until "good for what?" is on the page.

Step 2 — Load context → the minimum context set

Fill the slots that apply, skip the rest:

Step 3 — Make the scoped ask → a scoped prompt + first answer

Combine objective + context into one bounded request. Three moves: name the output form (Section 2's shapes), ask for the working ("flag what you're inferring vs. sure about"), and bound the scope (one decision per ask).

You're a fractional CFO advising a non-finance founder.

Situation: seed-stage SaaS, 9 people, ~$2M ARR, finance run by me in a
spreadsheet. Constraint: no new tools, ~2 hrs/month for this.

Decision: how often should we reforecast?

Give me a recommendation, the 2-3 reasons behind it, and flag which parts
are general best practice vs. specific to a company my size.

Because you asked for reasoning and inference-flags, the answer arrives pre-loaded with the things to interrogate.

Step 4 — Interrogate → a verified-claims list

Read as a Verifier. Separate the answer into load-bearing claims and sort each into accept / verify / discard, running each through: Is it load-bearing? Is it a fact or a judgment? Does it hang together? (Patterns and outliers: Section 7. How to actually verify: Section 8.)

Here is what the artifact looks like for the running example — this is the product of the step; the prose around it is packaging:

Then pull on the weak ones in the same chat:

You said monthly is "standard SaaS practice" — is that specific to SaaS or
general? For the sandbagging risk, what would I actually watch for? And is
anything in that answer you're inferring rather than confident about?

Step 5 — Iterate → a converged answer

Send one corrective turn at the largest gap. Good iteration narrows ("tighten this," "you missed that I have no tooling"), it doesn't enlarge ("more detail"). Match the turn to what Step 4 found:

What "converged" looks like — shown, not asserted. Convergence is when another turn changes only the wording, not the substance:

Before (hedged):   "Reforecasting frequency depends on many factors; monthly,
                    quarterly, or rolling can all work depending on context."
After (converged): "Reforecast monthly. At ~$2M ARR with one part-time
                    finance owner, monthly catches variance early without
                    eating your 2 hours. Revisit only if burn swings hard."

The "after" answers the actual decision, respects the constraint, and stops hedging — and a further turn would only restyle it. That's the signal it's done. A circular exchange (the answer keeps needing your real files or live numbers) is the Level-Up trigger, not a reason to grind.

Step 6 — Capture → a saved, reusable artifact

Lift the durable part out of the transcript. Match the method to use: an Artifact for a deliverable you'll keep editing; a Project for context you'll reuse across future asks (drop your Step-2 set into its instructions/files so new chats start knowing it); your own notes for the verified-claims list and the decision itself. A capture worth its name records three things: the answer, the verified-claims list, and the reusable context.

The pipeline in one breath: objective → minimum context set → scoped prompt + answer → verified-claims list → converged answer → saved artifact. Run it twice and it stops feeling like steps and starts feeling like how you work.

6. Goals → Considerations Map

People bring three recurring goals to Chat. Each bends the workflow differently — match your real intent to the right variant instead of running the pipeline blind.

The tell that you've matched goal to variant: a "draft" run that ends in a clean editable artifact, an "understand" run that ends with you able to apply it to your case, a "decide" run that ends in a defensible call with its weak point circled.

7. Connect the Components — Patterns & Outliers

A multi-turn chat is an engagement, not a pile of isolated replies. Read it as a whole: track the claims that accumulate, then watch for two things.

Patterns (promote them). When the same recommendation survives several angles of pressure-testing, or the same framing keeps proving useful, that's a pattern worth keeping — capture it (Section 9) and, if it recurs across tasks, promote it into a Project's instructions so future chats start with it.

Outliers (interrogate them). An answer that's off, contradictory, or unsupported. Three drift signals to watch for across turns:

1. It hedges where you needed a call. "It depends" when you asked for a recommendation means the frame was too loose or the model is dodging — push for the call ("if you had to pick one…").
2. It contradicts an earlier turn. Turn 5 disagrees with turn 2. In a long chat, early detail can drift out of the window. Surface it directly: "Two turns ago you said X; now Y — reconcile those."
3. It asserts a specific fact or number with no support. A precise figure, a named citation, a date, stated confidently and out of nowhere. Treat as an outlier until verified (Section 8) — this is the most common place a hallucination hides.

How to track without ceremony: keep the running verified-claims list (Step 4) as you go. It is your map of the engagement — what's accepted, what's pending a check, what you discarded — and it's what turns three turns of chat into one coherent read.

8. Qualitative vs Quantitative — Results Vary by Case

The level produces two kinds of output, and they are verified in opposite ways. Misfiling one as the other is how wrong answers slip through. Results also vary by case: the same prompt can land differently on two runs — phrasing, context, and the model's sampling all move the output — so a good answer once is not a guarantee, which is exactly why you verify by type rather than by trust.

The verification procedure (this is the part most people skip)

For a factual claim that matters: verify it outside the chat. Open the cited page yourself, search for it, check the number against your own data. Asking the model to cite its own source is not verification — if the original claim was hallucinated, "what's your source?" often just produces a matching, equally-invented citation. The check must come from something that isn't the model: a primary document, a search result, a calculation you run.

Worked catch. Claude says: "Most SaaS companies reforecast every 14 days — it's the industry benchmark." That precise number, stated flat with no source, is a classic outlier. The wrong move: "where's that from?" (you may get a confident, fabricated citation). The right move: search it / check a source you trust. You find no such benchmark — different sources say monthly or quarterly. Verdict: discard the "14 days," keep "monthly is a common cadence" only after the source confirms it. The fluent specificity was the tell, not the proof.

For a judgment that matters: there's nothing external to look up. Test it by making the reasoning visible and attacking it: "What has to be true for this to be the right call? Which of those assumptions is shakiest? What would change your answer?" A judgment that survives that is one you can act on; a judgment that collapses under one question was never load-bearing.

When recency is the issue and you have web search on, prefer it for the factual half — it can pull current public facts with source links (which you still open). When search is off, treat recent facts as unverified and confirm elsewhere.

9. Recommendations → Plans

The level has to produce something — not a transcript, an artifact you act on. Two moves turn the engagement into that.

1. Assemble recommendations. From the converged answer and the verified-claims list, write down what to do in plain terms, each tagged with how much you trust it: act on it (verified or low-stakes), act after I confirm X (pending an external check), discard (didn't survive). For the running example: "Reforecast monthly (act on it). Watch for sandbagging in the Q2 forecast (act on it). The '14-day benchmark' — discarded."

2. Line them into a plan. Sequence the recommendations and, for each, name what you hand to Claude vs. what you keep. At Chat level the hand-over is narrow — Claude can draft the board memo announcing the cadence; you set the cadence, confirm the one pending fact, and send the memo. The plan also records the reusable context so the next run starts where this one ended.

The walk-away artifact is concrete: a decision you can defend, with its reasoning, its trust levels, and (if you captured into a Project) a backdrop your next ask inherits. That's a one-off ask turned into a repeatable move.

10. Worked Examples

Example A — Make a decision (the running CFO/reforecast case, end to end)

Frame: "Help me decide our reforecast cadence; output a board-defensible recommendation for a non-finance founder." Load: seed SaaS, 9 people, ~$2M ARR, spreadsheet finance, no new tools, ~2 hrs/month. Ask:

You're a fractional CFO advising a non-finance founder. [situation + constraints above]
Decision: how often should we reforecast? Give a recommendation, the 2-3 reasons,
and flag general best practice vs. specific to my size.

Interrogate: sort the claims (the verified-claims table in Section 5). Verify "standard SaaS cadence" externally; discard the invented "14-day" figure; accept the size-fit judgment after pressure-testing it. Iterate: "If you had to pick one cadence, which — and what's the one thing that would make you change it?" → converges on monthly, revisit if burn swings hard. Capture: the decision + reasons + trust levels into your notes; the situation/constraints into a "Company Finance" Project so future asks skip the re-paste.

Example B — Draft a document (with a real reach-limit)

Goal: draft a one-paragraph message to your manager recommending you cancel an under-used SaaS tool, due today.

Weak ask: Should we cancel our Notion subscription? — gives generic "it depends," no decision criteria, no output shape, nothing for you to send.

Strong ask:

Help me decide whether to recommend cancelling our team's Notion subscription.
I'm a team lead writing to my manager, due today.

Context:
- 8 seats, ~$120/month. ~2 people use it daily, the rest almost never.
- We already pay for Confluence (org-wide, no extra cost) and Slack.
- The 2 heavy users keep the project tracker + meeting notes there;
  moving them costs ~1-2 days.
- My manager cares most about cost discipline this quarter, but hates
  disrupting productive people.

Don't just say yes/no. First lay out the 3-4 criteria a sound decision weighs
and where the tension is. Then recommend against those criteria, and flag the
one assumption that, if wrong, would flip it. Keep it pasteable into a short email.

Why it's strong: stated role + stakes (Section 4), pasted the context Chat can't reach (Section 4), named the decision criteria up front ("make a decision" goal, Section 6), demanded reasoning not a verdict (Section 8 + Verifier), and asked for the flip-assumption (Section 7 outlier, pre-requested).

The payoff: the reply flags its hinge — "assumes the 2 heavy users can't be migrated cheaply." That's your one follow-up: check migration cost. Maybe it's trivial and the recommendation flips — and the weak asker would never have known there was a hinge to check. Note what strong did not do: it didn't dump the whole contract in (the over-stuffing pitfall). Strong is scoped, criteria-first, and shaped for what you'll do with the answer.

Example C — Understand a concept (fast, low-stakes)

Goal: "Crisp distinction between OKRs and KPIs, with three examples from a support org, so I can explain it to my team Monday." Run: light context, one scoped ask naming the output (distinction + 3 examples), one iterate ("make the examples specific to a 6-person support team"), capture the final framing into the notes you'll present from. Wrong-Answer Cost is low and it's a stable concept, so verification is a quick sanity-read, not an external hunt. This is the right-sized spend — don't over-engineer a cheap ask.

11. Pitfalls — How It Goes Wrong

The level feels thin when you play it thin. Each fix restores one of the three hats.

The one reflex under all of them: read the answer as a claim to be tested, not an answer to be taken. Plausible ≠ correct; fluent ≠ current; an answer about your data ≠ your data.

12. Practice + Self-Check

The rest is reps. Run one full pass now — about 10–15 minutes — then score yourself against the rubric. The rubric is the instructor.

The starter task (do it now)

Pick a real question from your work this week — something you genuinely don't know, where being wrong has a small but real cost (not trivia, not a ten-second Google). If nothing comes, use the house example (budget vs forecast) but push it past the definition into your own context.

1. Frame (2 min). Write the one-line objective before opening the chat (Section 4). Assemble and sort context (paste vs attach).
2. Ask (1 min). Send a framed prompt, asking for reasoning, not just the conclusion:

   I'm a [role] trying to [objective]. Context: [the 2-4 facts that constrain the answer].
   [Your real question.]
   Give me the answer, then the reasoning, and flag any assumption about my
   situation that could change it.
   

3. Read critically (3 min). Find the one claim that would hurt most if wrong; interrogate that. Watch the three drift signals (Section 7).
4. Refine at least once (3-4 min). Push into your real situation:

   That's the textbook version. In my case, [specific wrinkle]. How does that
   change your recommendation, and what would you watch for?
   

5. Capture (2 min). Pull the one decision/draft/rule you'll act on out of the chat into your own notes (Section 9). The chat is not your memory.

Self-check rubric (everything here is gradable from this module alone)

Scoring. 6/6 — you ran the level; read Section 13. 4-5 — solid; find the missed beat and re-run on a new question. 3 or below — you treated Chat as a search box; the usual culprits are skipping the frame (#1) or never refining (#4). Re-run and force those two.

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

You don't graduate by feeling fluent — over-trust feels exactly like competence from the inside. The gate is behavioural.

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

A blunt self-test: could a colleague read your last five chats and reconstruct what you were trying to achieve and why you trusted the answer? If yes, you're out of Beginner. One marker worth naming: at Beginner you over-trust or over-verify everything; at the exit you've calibrated — you can say which claims in an answer need checking and which don't. That judgment is the whole class.

What the gate does NOT require: you haven't failed because you still re-paste context each session (that's the level's design) or because you can't make Claude act (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 Claude could just see and act on my actual stuff — read this file, check my real calendar, send the draft — instead of me copy-pasting and doing it by hand every time."

When copy-pasting between Claude and your real tools becomes the slow part of the job, the class has run out of room. That wish is the core thesis asserting itself: the more you let Claude reach, the more you can hand over. You've exhausted what you can hand over while it can only advise.

The hand-over you're trading up for

The catch worth naming before you go: once Claude can reach your tools, a mistake stops being words on a screen and starts touching real things. That's why Level 2 leads with the permission model, not "sign in and authorize." The Verifier reflex you built here is the prerequisite that makes Level 2 safe — you earned it on cheap mistakes so you can spend it on expensive ones.

Hand-off

Next: connect one tool so Claude acts on your real work — that's MCP.

Carry three things forward: the framing habit (a connected Claude with a vague brief just fails faster, against real data), the verify-reflex (it matters more now — wrong output can land on a live system), and one real capture from this level — bring a decision or draft you produced here, and let connecting a tool be the thing that lets you execute it instead of retyping it. Same expert, same reflex — now pointed at your reality instead of the world's.