How to brief a model, review its work and decide what to hand over.
Sourced
Concept at a glance
The quality of working with a model depends on what you ask and what you verify.
A focused everyday life example. Additional perspectives appear where they provide a useful contrast.
Practices for specifying, delegating, reviewing, and evaluating work done with a model.
Follow a person shaping a task, inspecting a draft, and deciding what to accept or revise. The useful skill is directing attention toward the parts that need human judgment.
Help me prepare a workshop plan I can responsibly approve.
Task brief, delegation boundary, draft, independent checks, and a recorded acceptance decision.
The setting makes the example concrete. Carry the underlying pattern into your own work; adapt the sources, tools, and level of oversight to your task.
Help me prepare a workshop plan I can responsibly approve.
Authored case. Select any record below; nothing is sent to a model.What changed: Establish the facts supplied for this version of the task.
Fluent output can hide omissions, and the user may not initially know every requirement. The task can become clearer through iteration.
Each one goes further into a part of this page than this page does.
Saying what you want clearly enough that the model does not have to guess.
Deciding which parts of a task to hand to a model and which to keep.
Learning, from results over time, how much to rely on a model without checking.
Describe your task to your own model and use Working with a model as a reference. Ask whether it fits, which alternatives meet the same automation needs, and how you would implement and check the result.
Operator craft is the human half of the manual: the skill of working well with a model, which grows more demanding, not less, as a system climbs the ladder. At level 1 it is mostly one skill, saying clearly what you want. By level 7 it is several: judging work you did not do yourself, deciding what to hand over and what to keep, and knowing, from evidence rather than a good first impression, how much to trust a system that acts without asking each time. This page is the overview; four pages carry the depth: briefing, reviewing, delegating, and calibrating trust.
None of this is specific to a coder. A domain professional who has never written a line of code briefs, reviews, delegates and trusts a model exactly the way a builder does, on the same four skills, just without the code.
This page is sourced, not measured: the habits below are checked against primary sources, and none of them has been tried on a scored task here.
Four things to do this week, one per skill, each handed to its own page for the full depth.
Briefing: before your next real request, write the goal, the constraint and what “done” looks like on three separate lines instead of folding them into one paragraph. Anthropic’s own guidance states the underlying point plainly: “Claude responds well to clear, explicit instructions”[1]. How much detail a model needs also depends on which one you’re briefing: OpenAI’s own guidance sorts its models into two kinds for exactly that reason, one that works out the details from a goal on its own and one that needs them spelled out[2]. Read a result that missed the mark against those three lines before rewriting it louder; the briefing page has the full six-part version and a worked example.
Reviewing: pick one thing you routinely accept from a model without checking, and check it once this week against something independent, a citation that resolves, a number you can recompute. You’ll know it worked when you can point to what you verified, not just say the answer “seemed right”; if you can’t find anything in the output to check it against at all, that’s the failure, not your diligence. Anthropic’s own guidance for agent builders treats human checkpoints as a normal part of design, not a fallback, and even for coding, where “Code solutions are verifiable through automated tests,” says human review remains crucial[3]; the reviewing page has the rest.
Delegating: before handing something over, ask what a wrong answer would cost and how you’d notice, then hand over only the part that scores well on both; the delegating page turns those two questions, plus two more, into a short table you can score any task against.
Trust: a string of correct answers is exactly when to keep checking, not stop. A scale-development paper on automation complacency found that monitoring a system “at a frequency that is suboptimal or below a normative rate” leads to performance failures[4]; calibrating trust covers what a record of your own corrections over time should look like, and how to read it.
None of this is worth doing for a single, low-stakes request you wouldn’t mind redoing by hand yourself.
A builder shapes operator craft through the interface, whether or not any of this is written down as a rule. A free-text chat box makes the brief and the request the same blob of prose, so nothing stops the constraint or the definition of done from getting silently dropped on a rewrite. A task input with separate fields (what to do, what not to do, what finished looks like) costs a little more to build and makes the brief a thing the reader can check against later, not just a paragraph they typed and moved past.
Reviewing needs something to review. A system that shows only a final answer gives a reviewer nothing to check but the answer’s surface plausibility; one that shows its sources, and ideally the steps that produced the answer, lets a reviewer check the parts that can be verified independently, the way this site’s own trace player exposes each step of a run instead of only its last one. Anthropic’s guidance for agent builders treats the interface between a model and its tools as real design work rather than plumbing: one rule of thumb it gives is to think about how much effort goes into human-computer interfaces and “plan to invest just as much effort in creating good agent-computer interfaces”[3]. The surface a reviewer reads deserves the same budget.
Approval points are where operator craft becomes a piece of code, not just a habit. An interface that lets a person approve or reject one specific action before it runs (rather than trusting an instruction in a system prompt to hold) is the same shape as the permission check on the safety, privacy and governance page: a check outside the model, that runs whether or not the model would have gotten it right on its own. A builder designing for delegation decides, ahead of time and in code, which actions get that checkpoint and which do not; leaving that decision to be made informally, in the moment, is how it stops getting made at all once volume goes up.
No runnable example accompanies this page. A task-input form, a review surface, and an approval checkpoint are interface and process decisions, not an algorithm with a fixed answer to test against: the honest Build it lane here is what to design for, not code to run.
Skip building any of this out formally (a task-input form with separate fields, a visible review surface, a coded approval checkpoint) for a single, low-stakes request you would not mind redoing by hand. Writing the constraint and the “done” condition on their own line, the way the Practices below ask, is already most of the value, and it costs nothing to try before building anything around it.
There is nothing to brief, review, delegate or trust before a model is actually in the loop; level 0, no model at all does not raise any of these questions.
Build the formal version once a wrong answer costs enough, or gets reviewed by someone other than the person who asked, that “I would have caught it” stops being a good enough plan.
How often you catch a problem after the fact instead of before, on work you were supposed to be reviewing as it happened. A rising after-the-fact rate is the signal to review more closely, not a sign that less review is now safe.
Review time should not fall to zero as trust grows; it should shift from checking everything to checking a sample plus anything that crosses a fixed bar (an irreversible action, a number that gets repeated elsewhere), the same shape a human-in-the-loop checkpoint uses.
Automation complacency: after enough correct answers in a row, checking starts to feel like wasted effort, and the one wrong answer that actually mattered goes through unchecked.
What you changed or rejected in anything you reviewed, and why. A record of your own corrections, not a memory of how confident things felt, is what calibrated trust is actually built from.
Before your next real request to a model, write the constraint and the "done" condition on their own line, separate from the request. Did writing them down change what you actually asked for?
Look at a tool you use or have built that shows a model's reasoning or sources before its final answer. Find one place in it where a wrong intermediate step would be invisible to a reviewer, and write down what would have to change to surface it.
Pick one thing you routinely accept from a model without checking. Write down what checking it would actually cost you in time, and what a wrong one slipping through would cost. Decide, on paper, whether that's the trade you actually want.
Give it a clear brief, inspect the result against evidence, and decide what is ready to use.
An illustrative task example. No verified product or tool is currently listed for this concept.
No product, tool or model is registered against this page yet. The names index lists every one the site does name, and which technique each belongs to.
Names listed 09/19/2026. 223 of 223 registry entries have been checked against the maker's own page; the registry marks the rest as unchecked.
Last reviewed 09/19/2026. Pages unreviewed for 90 days are flagged for another pass. Markdown version of this page