If your team has AI licences and mostly uses them to tidy emails, or your pilot demos well and nobody uses it, this is for you. In both cases each person asks for the smallest version of each task, nobody checks the result against anything outside the chat, and nobody sees a colleague do something bigger.
This is not for you if your team has no AI tool yet, or if nobody owns the work you would point it at. Name the owner first.
Why do most teams stall at tidying emails?
Most requests are a guess at the method. Felix Rieseberg, who works on Claude at Anthropic and has led engineering for the Claude app, Cowork and Claude Code Desktop, put it this way in a tutorial he published on 13 October 2026: "When you give the model a task, it's executing your best guess at how to get the outcome you want."
He describes a split. Some people "seem to be flying". Many others wonder what the tools are good for "beyond asking 'What is the capital of France' or 'Can you make this email sound less angry'". His answer is to be more ambitious, and he breaks ambition into four types: speed, altitude, depth and range. Speed, the same work in less time, needs no help, so he skips it. We do too.
His tutorial is written for one person at a keyboard. A team needs more than that: shared access, a shared rule for who checks the work, and a reason for people to try the bigger version. So we turned it into seven steps, and added the step his closing section points at but does not spell out for a team. For each one, here is what most teams do and what to do instead. Treat it as a small AI adoption framework you can run one team at a time; most of the change management sits in steps 2 and 7.
What is the AI playbook, in one table?
What most teams do, and what to do instead
Step 1: Ask for the outcome, not the task
Rieseberg calls this altitude. His question: "What's the goal beyond the goal?" His own example: "At the beginning of last year, I still asked Claude to fix individual crashes for me. Eventually I asked Claude to simply keep our apps crash-free."
The office version he uses is the quarterly business review. Most teams ask for slides, or for the template filled in. The higher ask names why the review exists: "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."
He is clear about the limit: this works "if you really are after some ultimate outcome; it works less well for creative endeavors", and "'Claude, go make money' doesn't seem to work for most businesses by itself in 2026". His test for when to use it: if you are going to have meetings about the work, ask for the outcome.
On your team: list the recurring tasks that end in a meeting (the weekly pipeline review, the month-end pack, the tender response). For each, the owner writes one sentence: what should be different after the meeting. That sentence opens every request for that task.
Step 2: What does the model need to reach it?
Asking for the outcome fails if the model can only see what you pasted. Rieseberg's crash-free example needed work first: he had to make sure the model "can easily fetch crash reports, understand which app version maps to what git commit", and could reach Windows, macOS and Linux machines "so it can actually independently reproduce and verify fixes". His rule covers all three types: the model needs "a computer with the ability to install software and access to all kinds of relevant data".
On a team, someone has to decide which data the model may read, which systems it may touch, whether it may write, and which identity it acts as. Read-only first is the safe default. When the work lives in Salesforce or Slack, that means a connector with a scoped user that your security team can audit, not a shared admin login. A pilot that security will not let write is usually stuck at exactly this point.
On your team: in week one, the owner of each task and your security lead agree four things in writing: the data it may read, the tools it may use, whether it may write anywhere, and the identity every write is logged under. Our AI governance page covers how we record that.
Step 3: Copy the expert's method, not their words
This is the first half of what Rieseberg calls depth. Telling a model to "act like a data scientist" changes its vocabulary. In his words, "models often switch vocabulary without actually switching methods." His fix is to insist on the instruments: "When Claude reaches for markdown tables, insist on the use of databases and statistical models." You do not need to know what the experts use, he adds: "Claude usually does."
He also asks the model to challenge what the business believes. His example: "We believe churn is an onboarding problem. Try to reproduce that from the raw data." And he shares one prompt that does most of this step:
I want a deeper version of this task, not a bigger one. Before rewriting it: (1) say what a top professional in this field would do here that I'm not asking for; (2) name the rawest material they would start from instead of what has already been digested for me; (3) name the specific methods and tools they would use; (4) say what, other than you or me, would show the result is right. Then rewrite my prompt to ask for exactly that.
On your team: put that prompt in the shared library where your team keeps templates, under its author's name. Anyone starting a task that matters runs it first and keeps the rewritten prompt with the task.
Step 4: How hard should the goal be?
Harder than feels reasonable, and specific. Rieseberg: "You need your website to load in 5s instead of 10s? Ask for 200ms. Does something seem impossible to the model? Reiterate that it's very much solvable, it just needs to keep going."
There is research behind the habit, at least for people. Edwin Locke and Gary Latham reviewed 35 years of goal-setting studies in American Psychologist in 2002. Their finding: specific, difficult goals lead to higher performance than being told to "do your best", as long as the person is committed and has the ability and resources.
A hard goal with no access (step 2) and no judge (step 5) is how you get a confident answer that is wrong.
On your team: every request for work that matters carries a number. A time, a count, a threshold, a date. Write "every lead gets a reply within 5 minutes, day and night", not "faster".
Step 5: Who checks the work?
Not the model that did it. If you keep only one step, keep this one. Rieseberg: "Do not ask the model to judge itself. I assume that this will eventually be solved with increasing model intelligence, but in October 2026, I implore you to insist on outside validation. Ideally that's a tool the model can run to get feedback immediately."
This is the same rule we build agents on. Our method for a first agent is called Spec, shadow, gate: write the job on one page, run the agent beside your person so it writes nothing until you have compared its calls with theirs, then let each write go live behind a person's approval. The shadow run is an outside judge. So is the person at the gate. Our spec-driven engineering guide walks through it.
Here is the shape of what a shadow run shows the judge. A made-up example, not a client.
A write leaves the shadow run only when the owner has read the log and every mismatch has a rule in the spec. Mismatches stay with a person, and the owner from step 1 owns the exceptions after go-live.
On your team: before a task runs, write down its judge. It can be a test that passes or fails, a check against the source data, a second reviewer who did not see the draft being made, or the owner from step 1. If nobody can name the judge, the output is a draft, and everyone should treat it as one.
Step 6: Which other fields should you bring in?
More than the task seems to need. Rieseberg calls this range, and compares it to heist films that spend their first half hour assembling a crew. His own example of a blind spot: he never thought of using Claude for 3D scenes on his homepage until he saw his colleague Alex Albert use Blender to render interior designs, even though he had made video games before.
His method has two moves. First, replace nouns with verbs, a trick he credits to Tom Kelley and Jonathan Littman's The Art of Innovation. A quarterly review is not "a deck". It is "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes." Second, assemble the crew: an analyst, a journalist and an editor for the content, a motion and audio designer if it is presented, and a red team of a short seller and a forensic accountant to find the holes.
He warns against the obvious failure, role play: "Don't ask the model to write like a short seller, ask it to do what a short seller does to research their position."
Here is the same move on a Dubai brokerage's weekly task (our example). The noun is "the weekly lead report". The verbs are "get the sales manager to move two agents onto the leads that are going cold, before Monday's meeting". Now the crew is obvious: someone who reads response times, someone who knows which portal sends which buyer, and a red team that asks which leads were marked lost too early.
On your team: keep range for the work that matters most (the board pack, a pricing change, a large tender). Running several viewpoints or several agents costs more time and more usage, so it should earn its place.
Step 7: How do you make ambition normal?
Steps 1 to 6 are about how one person asks. Step 7 is about why the rest of the team would try. Rieseberg ends his tutorial on the reason: psychology calls it self-efficacy, the belief that you can do the thing, and "people with high self-efficacy believe in their own abilities more, and in turn actually accomplish more."
The term comes from Albert Bandura, who in a 1977 paper named where that belief comes from: doing it yourself, watching someone like you do it, being told you can, and how you feel while trying. Rieseberg's three stories cover three of them.
- Believe it is possible. In 1939, George Dantzig arrived late to a statistics class at Berkeley, copied two problems from the board, and handed in solutions thinking they were homework. They were two unsolved problems in statistics, as Snopes records from his own account.
- Watch someone else do it. Roger Bannister ran the first mile under four minutes on 6 May 1954. John Landy did it 46 days later.
- Give yourself permission to fail. Rieseberg points to The Inner Game of Tennis, whose thesis is that you do not play your best when you try too hard, and to Linux, first announced as "just a hobby, won't be big and professional like gnu".
A first small win of their own gives them the first source Bandura names. A colleague showing what they did last Tuesday gives them the second. A manager saying "this is solvable, keep going" gives them the third. A review that treats a miss as information, not a mark against someone, lowers the stress that Bandura counts as the fourth.
On your team: run a 20-minute show-and-tell each week where one person shows a result they did not think the tool could reach, with the prompt, the access and the judge. Set one stretch goal per team per month. Review misses in the same meeting, by the same rules as wins.
How do you roll out AI adoption in four weeks?
This is our suggested pace for a first round, not a benchmark. Start with three recurring tasks, not thirty.
A first round, three tasks
Week 1
Pick three recurring tasks, an owner for each, and the outcome sentence. Agree data and tool access with security, read-only first.
Week 2
Run each task with the four-question prompt, a number in the goal, and a named judge. Compare the result with how a person did it.
Week 3
Hold the first show-and-tell. Add a crew and a red team to the most important task. Set one stretch goal.
Week 4
Keep what the judge passed. Write the prompt, access and judge into the team library. Pick the next three tasks.
When should you slow down?
When nobody can say why the work matters. Step 1's outcome sentence is the check: if the owner cannot write it, the task should wait.
Slow down, too, when the judge is missing. Rieseberg is open that models are, in Terence Tao's words, "astounding in some directions, while inadequate in others". Raise the goals only where someone has named who checks the work.
For how to use AI at work one prompt at a time, read our prompt engineering guide for business. For rolling Claude out across a company, see the Claude enterprise deployment guide.
How can we help?
The work is led by Shivanath, our founder, a Salesforce MVP Hall of Fame member who has put 200+ agents into production, with desks in the UAE, India and the US. We start with the written assessment, which is free: where your team uses AI today, which three tasks to take first, and, if you have a stalled pilot, what to keep, fix or stop.
We can help your teams adopt AI better. Contact us and we will help you roll this out.
