Leveling packages: what to understand, try, and do at each transition

B.adoption-spectrum.md describes five positions on the spectrum of AI-assisted research. This document describes the moves between them.

Each transition package has three parts: the conceptual shift (what needs to change in your mental model before the new level actually works), the first experiment (one concrete, low-stakes thing to try), and the practice (habits to sustain once you've arrived). The packages are a menu, not a curriculum — Level 2 is a strong, defensible endpoint for most humanities researchers.

0→1: From occasional query to regular practice

Conceptual shift

Dialogue beats single-shot. The first answer is a starting point, not a result. Most of the value in working with AI comes from the second or third exchange — clarifying what you meant, pushing back on a framing, asking for a different angle. Treating the first response as final forecloses most of the leverage.

Imperfect outputs are fine. They are material to react to and improve, not failures. The standard is not "did this output impress me" but "did this output help me think faster or better than I would have without it." Often a flawed draft that takes 10 minutes to fix is more useful than a blank page.

The AI doesn't know what you actually need. Audience, format, purpose, constraints — none of this is visible to Claude unless you provide it. "Summarise this" and "summarise this for a non-specialist audience in three sentences that I can use in an abstract" are different requests. The specificity of your instructions is the main lever you control at this level.

First experiment

Take one task you do regularly — reading a dense text, giving feedback on a draft, generating a list of options for something — and do it with AI five times over two weeks. The goal is not a perfect outcome. It is calibration: learning what kinds of help land and what kinds don't. After five iterations you will have a better sense of what AI is useful for in your specific work than any general guide can give you.

Practice

Build a small personal library of prompt structures that work for you. Not abstract prompting rules — your patterns. "When I want feedback on my argument structure, I start with..." The point is to stop reinventing the approach each session. These don't need to be written down formally; a rough mental catalogue is enough.

1→2: From episodic conversation to context-aware collaboration

Conceptual shift

The AI's ignorance of your work is the bottleneck. Without context, Claude is a highly capable stranger — intelligent, responsive, but generic. It doesn't know what you're investigating, what you've already established, what you've explicitly rejected, or what your standards are. Providing that context is the single highest-leverage thing you can do at this transition.

Context is infrastructure, not a prompt technique. It needs to be written, maintained, and updated — not created once and forgotten. A project description from six months ago that no longer reflects your current framing will produce coherent but misaligned responses, which are harder to catch than obviously wrong ones.

Articulating your project to a non-expert is a research activity. If you can't explain what you're working on clearly enough for Claude to be useful, that difficulty is information about your own thinking. The friction of writing the context document often surfaces assumptions you hadn't examined, framings you'd accepted uncritically, and goals that turn out to be underspecified. This is part of the value.

This shift has a name: context engineering. At Level 1, the main skill is prompt engineering — crafting better individual requests. At Level 2, the skill is context engineering: deliberately designing the persistent information architecture that Claude operates within, so you stop rebuilding context in every session and start maintaining it. The distinction captures exactly what makes this transition hard: it is not a refinement of something you already do, but a different kind of work entirely. See A4.conceptual-vocabulary for the full concept.

First experiment

Write a one-page project description for Claude. Include: what the project is, what you're currently working on, what you want AI to be helpful with, and — importantly — what you do not want AI to shape or decide. Don't try to be perfect. Write it in 30 minutes and use it for a week. Revise it based on what felt missing.

The natural home for this is a Claude.ai Project (which attaches the description to every conversation) or a CLAUDE.md file in your working directory (for Claude Code). Either gives you persistent context without having to paste it manually each session.

Practice

2→3: From conversations to workflows

Conceptual shift

AI can act on files, not just respond to text. Claude Code can read, write, and transform actual documents in your project — not copies you paste into a chat window, but the files themselves. This is qualitatively different from chat: the AI is a participant in your work environment, not a separate tool you consult and then return from.

Repeatable process design is different from conversation design. A workflow specifies: what is the input, what is the expected output, what does a good result look like, where and how do you verify. A conversation just asks. Moving to Level 3 means thinking in workflows: not "what should I ask Claude today" but "what is the input, what should come out, and where do I check the work."

Think in terms of what the AI needs, not just what you want. Workflows require you to design the context in advance — the instructions, constraints, output format, and verification criteria — rather than providing it conversationally in the moment. This requires a different kind of preparation, and it reveals ambiguities in your task definition that conversation can paper over.

First experiment

Pick one file-heavy task that recurs in your work — summarising a set of papers, maintaining a structured bibliography, applying a consistent annotation schema to interview transcripts. Do it once with Claude Code. The goal is not efficiency. The first time will be slow. The goal is to understand what working at the file level feels like and where verification becomes necessary.

Pay particular attention to the moment where you would normally just accept the output: what would you need to check to be confident it is correct? That moment is where your verification step belongs.

Practice

3→4: From integrated workflows to orchestration

Conceptual shift

The human role shifts from doing to specifying and reviewing. At Level 4, you define what needs to happen clearly enough to delegate; you review whether what came back is what was wanted; you intervene when the agent goes wrong. The skill is no longer execution — it is specification and judgment.

Automation introduces error modes that are qualitatively different from one-off mistakes. An error in step 3 of a five-step automated chain may only surface in the final output — plausibly, confidently, and far from its source. The chain completed; the output looks reasonable; the problem is invisible unless you audit intermediate steps. This is the defining risk of orchestration and it doesn't have an analogue at lower levels.

Delegation requires trust you have not yet earned with a new system. Automated workflows are not trustworthy by default. They become trustworthy through iteration: small runs, verified outputs, incrementally added complexity. The impulse to automate everything at once is the main way orchestration goes wrong.

First experiment

Write a two-step script: something where the output of Step 1 feeds Step 2 — for example, generating structured summaries from a document set and then synthesising them across documents. Keep the scope small enough that you can verify every intermediate output. Run it. Read the intermediate outputs before running Step 2.

The goal is to experience what "the chain completed but something went wrong at step 3" feels like before you are relying on a larger, harder-to-audit process. The learning is in the debugging.

Practice

You don't have to level up

These packages are an offer, not a curriculum. There is no implicit obligation to move up the spectrum, and moving up because it sounds more sophisticated — rather than because you have a specific use case that requires it — produces the worst outcomes: the complexity and risk of a higher level without the payoff.

Level 2 is a strong, productive endpoint for most humanities researchers. A well-maintained project context, a calibrated sense of what Claude can and can't do, and the habit of active verification will serve most research work well. Level 3 is valuable for researchers with recurring file-heavy tasks or a need for systematic consistency across a corpus. Level 4 is for specific large-scale or institutional use cases, or for researchers with programming fluency who have a concrete automation problem to solve.

The question at each transition is not "shouldn't I be at the next level?" but "do I have a use case that requires what the next level offers?"

Related