What You Need to Know
Research gathers and synthesises outside material, so you start from material that already exists. Planning turns a goal into ordered steps. Process optimisation finds and fixes the bottleneck, which is the step that slows a process. All three work the same way: Claude makes the first draft, and you make the decisions about it.
This lesson uses one made-up example throughout: a software company. Its operations manager uses Claude for all three: other companies' pricing, a plan for a customer training event, and slow setup of new customers.
Research at Two Scales
The product supports research at two scales, and the Help Center describes the difference. Web search suits straightforward factual queries that one or two lookups can answer. Research mode runs multiple searches that build on each other. It explores different angles of a question and addresses the open questions systematically. It returns cited findings and suits bigger multi-source jobs. At the company, one data-protection rule is a job for web search. A survey of how other software companies set prices is a job for Research.
A third option, extended thinking, lets Claude think harder before it answers, without a web search. It suits complex reasoning over material that you already have, such as the company's own record of the date when each setup stage finished. Lesson 3.1 compares the three features.
The value is coverage and speed. The limit is that anything important gets checked before anyone repeats it, whether it has citations or not. A citation shows where a finding came from, not that the finding is right.
Plans Are Built from Stated Constraints
Starting from Claude's first plan is better than starting from nothing. Claude is good at finding gaps in a plan. If you ask what a plan is missing, you get dependencies, sequencing problems and the step that everyone forgets.
Claude will also confidently make plans that omit constraints you never mentioned, because it does not know them. Examples are the one room with step-free access, the trainer who cannot work Fridays and the room that another team has booked. Nothing in the output warns you that Claude built the plan without them. A training-event plan without constraints might give the Friday sessions to a trainer who never works Fridays. The plan is wrong, but it looks correct. That makes it more dangerous than an obviously bad plan, because people are more likely to trust it.
This is easy to prevent. Anthropic's business prompt-engineering guidance says to treat Claude like an intern on its first day, with clear, explicit instructions and all the necessary detail. For a useful plan, put the real constraints in the brief, then ask for the assumptions that the plan rests on. When the plan states an assumption, you can read it and correct it.
A plan can list more assumptions than you have time to check. Check first the assumptions that much of the plan depends on and that nobody has confirmed. Often you can check them yourself, with one phone call or a look at your own records. Skip facts that are already settled. Also skip details that would not change the plan if they were wrong. For the training event, check that the trainer can work on the Friday, because every session depends on her. Do not re-check the event date that the director fixed months ago.
The Optimisation Loop
Claude generates hypotheses about where a process is slow, fragile or duplicated. A hypothesis is a possible explanation that nobody has tested yet. Claude cannot tell you which one is true, because it has never watched your process run. Data decides which hypothesis is true. The loop has four steps:
- Describe the process and its constraints, as staff really run it.
- Ask for candidate bottlenecks, and for the evidence that would confirm each one.
- Collect that evidence.
- Change the step that the evidence identifies.
Step 1 needs the process as staff really run it, not as the written procedure says. Claude can suggest a bottleneck only in a step that you describe. So include the informal steps that no document records. Also give numbers: how often the work happens, how many cases there are and how long each case takes. Anthropic's workflow-improvement guidance says that this kind of detail helps Claude design solutions that match your scale. At the company, the written setup procedure might list five steps. In practice, an account manager also holds each new account until the finance manager approves it by phone. If the description omits that phone approval, Claude cannot name it as a possible bottleneck.
Evidence comes after Claude names the hypotheses, so you know what you are looking for. Evidence comes before anything changes, so the change has a target. For the company's customer setup, Claude might suggest slow data import or late contract approval by the customer. The company's own record of when each stage finished decides between them.
The same guidance advises approaching the work like a scientist, and testing and iterating often. It also advises pairing prompt work with the organisation's own subject-matter experts rather than trusting either alone.
The Wrong Bottleneck
The most expensive mistake is optimising a step that was never the constraint. It wastes the budget on a step that was working, and people are then less willing to try another change. It usually comes from treating the most plausible hypothesis as the confirmed one. The cause that looks most likely is often the real one, so it is tempting to act without evidence. But the likely cause is wrong often enough to make this expensive. Collecting the evidence that shows the real cause usually needs a day's work. Suppose the dates show that contract approval causes the delay. If the company buys a faster import tool, it spends its money and the delay remains.
In the exam
The exam tests your judgement, not Claude's first draft. Every right answer in this objective either supplies the facts Claude could not know or checks something before acting. Every wrong option that recurs treats a fluent output as a finished one. Domain 3 covers which feature does the research. This objective tests the practice around that feature. Checking findings before repeating them belongs to Domain 2.
How to spot the right answer
The right answer gives Claude the facts that Claude could not know, such as how staff really run the process. Or it checks something before anyone acts on Claude's output. In a process question, the evidence comes after Claude names the possible bottlenecks, so you know what to collect. The wrong options act on reasoning that sounds convincing. Or they collect evidence before anyone knows which evidence matters, or choose a bigger feature when local facts were missing.
Exam Traps
Treating a plausible, well-structured plan as a checked one
Claude confidently makes plans that ignore constraints it was not told, and nothing in the output warns you. The plan looks correct but is wrong. Put the real constraints in the brief, then ask for the assumptions it is based on.
Changing the process because of the best-sounding hypothesis
Claude's candidate bottlenecks are hypotheses; it has never watched the process run. Acting on the most plausible one can spend money on a step that was fine. Get the evidence that would confirm each one, then change the step that the evidence identifies.
Substituting more research for local evidence
Citations from elsewhere cannot say which cause is true in your process. Research mode suits bigger multi-source jobs, but the deciding evidence here is the process's own data. Pull that data before changing anything.
Practice Scenario
The operations manager of a property management company keeps hearing that repairs in its rented apartments take too long. She describes the repair process to Claude, which suggests four plausible causes: contractors receive new jobs only once a week, staff record phone requests late, tenants are slow to agree a visit time, and parts are ordered only after the first visit. Only the figures of her own company will show which cause is the real one, and she will act on none of them until they do. What is the professional next step?
Build Exercise
Plan It Twice, Then Find the Real Bottleneck
What you'll learn
- How stated constraints change the usefulness of a first-pass plan
- How to spot a plan that looks correct but is wrong
- How to run the describe, hypothesise, evidence, change loop
- How to test whether the data points at the step you would have guessed
- Pick a real upcoming piece of work with genuine constraints: an event, a staff schedule, a launch, anything that is actually yours
Why: The exercise only works when you know the real constraints well enough to catch a plan that ignores them.
You should see: One named piece of work and, privately, its three most binding constraints.
- Ask Claude for a first-pass plan twice: once with no constraints stated, once with the three most binding real constraints written in
Why: The comparison makes the objective’s core failure visible: the unconstrained plan looks just as correct as the constrained one.
You should see: Two fluent plans that differ in exactly the places where your constraints apply.
- List what the unconstrained plan got wrong that nonetheless reads as perfectly sensible
Why: Naming the specific errors makes it a habit to check plans against facts rather than against how well they are written.
You should see: Three or four concrete errors, each invisible to someone who did not know the constraints.
- Now pick a process that feels slow and describe it to Claude from start to finish; ask for four candidate bottlenecks and, for each, the evidence that would confirm or rule it out
Why: This is the optimisation loop’s first half: hypotheses plus the evidence that would decide between them.
You should see: Four candidate causes, each paired with a named, gettable piece of evidence.
- Collect one of those pieces of evidence this week, and note whether the data pointed at the step you would have guessed
Why: The gap between the guessed bottleneck and the evidenced one is what this step teaches; most people are surprised at least once.
You should see: One piece of real data and a one-line verdict: guess confirmed or guess wrong.
Sources
- Use research on Claude — Anthropic
- When should I use web search, extended thinking, and research? — Anthropic
- Prompt engineering for business performance — Anthropic
- Workflow improvement planner — Anthropic
- Claude Certified Associate – Foundations Exam Guide — Anthropic. This lesson draws on the exam guide's objective and standard practice; the articles above support only the points they are cited for.