1. What Delegation Leaves Behind

Say you work alone, with no product yet, and you are considering a productized service for small independent trade businesses: electricians, plumbers, roofers. A productized service means a fixed, repeatable job sold at a fixed price, as opposed to custom consulting where every project is negotiated from scratch. Your hunch is this: the owners of those businesses are on a roof or under a sink for most of the day, they cannot answer the phone, and enquiries go cold because nobody replies for two days.

That is a hunch. It has the shape of a real problem, which is exactly what makes it dangerous. It is easy to believe.

The business and the research in this example are invented for teaching. Invented notes prove nothing about demand, and the fastest way to ruin a business is to mistake made-up inputs for evidence about a market. They are here so you can practise the method, and then run it on real material you gathered yourself.

The research packet is small, about a dozen short items. Some are notes from conversations with tradespeople. Some are the kind of short excerpt you would find in a public review. And there is a separate short document listing how each business handles enquiries right now. Every item is numbered, so any claim can point at exactly which item it came from. That numbering is what makes checking possible later, and if you take one habit away from this chapter, make it that one: number your sources before you hand them to anything.

Here are five of the items, so you can see what the material actually looks like.

The first is a note from an electrician with two vans: "I check my phone at lunch and at nine at night. If someone rings at ten in the morning, I might get back to them Thursday." The second is from a sole-trader plumber: "I lost a bathroom job because she rang someone else the same afternoon. That was about eleven hundred pounds of work." The third is from a roofer: "My wife picks up when she can. She doesn't know what to quote, so she says I'll ring you back." The fourth is a review excerpt about a heating firm: "Rang three times over two days, never got an answer, went elsewhere." The fifth, from the handling document, records that one electrician sends every missed call to a voicemail greeting he recorded four years ago, which still gives his old landline.

Four different people describe the same failure. Exactly one of them attaches money to it. Nobody says what percentage of enquiries they lose, because nobody counts. Hold onto that.

Now the casual version, which is what almost everyone does. Open a fresh chat. Paste in all twelve items. Type: "Is this a good business idea?" Wait.

What comes back is impressive to read. It has a heading called Market Opportunity. It tells you the pain point is real and underserved, that trade businesses lose a significant share of inbound enquiries to slow response times, that the natural offer is a shared inbox and answering service with a same-day response guarantee, and that you should price it as a monthly subscription because trades value predictable costs. The whole reply arrives in about twenty seconds and ends with encouragement. It feels like research. It is a conversation.

Every sentence in that reply is plausible. Some of it may even be true. And it is useless for three separate reasons.

It is unchecked. Somewhere in that answer are claims that came from your twelve items, and somewhere else are claims that came from the model's general sense of how the world works, and the reply gives you no way to tell which is which. It is unrepeatable. Ask the same question tomorrow and you get a differently organised answer with different emphasis, and no way to know which version to trust. And it is gone. Close that tab and the notes are not stored anywhere you can reuse, the instructions you gave are not saved, and tomorrow you start from an empty box again.

Better wording would not have saved it. Three paragraphs of beautiful instructions would still end in an answer you cannot verify and cannot reproduce, because chatting leaves nothing behind. Delegating leaves a container that holds the source material, a result you can check line by line against that material, and instructions the next run inherits without anyone retyping them.

That takes four moves. Give the work a permanent container. Put the sources inside it. Write a brief that says what a finished result looks like. Then check the result against the sources.

The container, in the assistant we are using here, is called a project. Claude, from Anthropic, has a Projects feature in its web application at claude dot ai: you open Projects in the sidebar, choose Create Project, and give it a name and a short description. A project is just a workspace that keeps its own files and its own standing instructions, so that every conversation you start inside it begins already knowing your material. Free accounts get a small number of projects; paid tiers allow more. Give yours something dull and accurate, like Trade Enquiry Research.

Inside the project there is a pane called Project Knowledge. That is where the sources go. You click the plus button and upload files: plain text, markdown, PDF and Word documents are accepted. The uploaded files get parsed and indexed, and from then on they are standing context for every conversation in that project, so you never paste them in again. Upload two documents: the numbered interview notes and review excerpts, and the shorter document describing how each business currently handles enquiries.

Context is the material the model can actually see while it is producing its answer: your request, the conversation so far, and whatever the application has pulled in from your files. It is not memory in any human sense. It is more like the pile of paper on the desk in front of someone writing a report. If a fact is not on the desk, it does not exist for that report, unless the model reaches for something it half-remembers from training instead, which is precisely the failure we are going to catch.

Now the brief. You are commissioning a deliverable, and a useful brief has five parts.

The first part is the result you want: a named artifact with a shape. Ask for an opportunity brief, no longer than one page, in five sections: the problem, how these businesses handle it now, what the failure costs them, who to try to reach, and what is still unknown. Named sections let you tell at a glance whether the work is finished, and they stop you being fobbed off with three strong paragraphs and no mention of cost.

The second part is context: what evidence is permitted. Write that the two uploaded documents are the only evidence for this brief, and that general knowledge about the trades, about small business, or about response times must not be used. That has to be said, because by default an assistant draws on both what it was trained on and what you have given it, and those two sources arrive in the answer looking identical. Anthropic's own documentation is direct that Claude can produce misleading responses and convincing-sounding quotes that are not grounded in the material, and that it should not be relied on as an unverified single source of truth. So the restriction has to be stated, not assumed.

The third part is the constraints. Every claim must name the numbered item it came from and quote the words. Any figure that does not appear in the sources may not appear in the brief. Anything the sources do not establish is written as the word unknown, never smoothed over or estimated.

The fourth part is permitted actions. For this run: read the two supplied documents, and nothing else. No searching the web. If the assistant can go and find outside material, you can no longer tell whether a sentence came from your research or from a page you have never seen.

The fifth part is evidence of completion. Ask for a claim-by-claim list at the end: every factual sentence in the brief, beside the item number and quoted words that support it. People skip this part, and it is what turns a nice-looking answer into something you can audit in four minutes.

Send it. Out comes a tidy one-page brief.

Now inspect it, which means picking claims and trying to break them.

Take the first claim: that owners routinely go most of a working day without seeing an enquiry. Look for the line. Item one, the electrician with two vans, checking his phone at lunch and at nine at night. Supported, and the quote matches.

Second claim: that the current workaround is often a family member or an out-of-date voicemail, neither of which can quote a price. Items three and five. Supported.

Third claim, in the section on what the failure costs: "small trade businesses typically lose around forty percent of inbound enquiries to slow response." Go looking for that number. It is not in item two, which gives one bathroom job at about eleven hundred pounds. It is not in the review excerpt. It is not in the handling document. It is nowhere in the twelve items, because none of the twelve people counted anything.

That number came from the model's training, and it walked into your brief wearing the same clothes as the two claims that were fine. The assistant did not lie. Fluent prose just carries no information about where a sentence came from.

There is a second problem, quieter and just as expensive. The brief asked for what the failure costs, source by source. What came back is a confident paragraph on cost, built on that one bathroom job, generalised outward. For eight of the twelve items, the sources say nothing about money at all. The honest output was eight lines reading unknown. What you got instead was a smooth paragraph that reads as though the question has been answered.

Both of these matter because of what you are about to build on them. The offer you design, the price you set, the person you ring first: those decisions rest on these sentences. If a made-up forty percent is sitting underneath your pricing, you will not discover the error when you read the brief. You will discover it months later, when the business does not work and you cannot say why.

So you repair it, and the natural move is the wrong one. The obvious reply is "that forty percent figure isn't in my sources, please be more accurate," and it produces a corrected answer and no lasting improvement. Tomorrow, in a new conversation, the same fault returns. Arguing fixes an output. Changing the instructions fixes the process.

Go back to the Project Knowledge pane, choose Set project instructions, and write rules that will be prepended to every conversation in this project from now on:

1. Answer only from the documents in Project Knowledge; never use outside or general knowledge, even when it seems obviously true.
2. Follow every factual claim with the item number and a verbatim quote, in square brackets, from the document it came from.
3. Never state a number, percentage or currency amount that does not appear word-for-word in the sources.
4. End every brief with a section headed "Unknown: must be asked in a real conversation," listing each question the sources do not answer.
5. End every brief with a claim-check list pairing each claim to its supporting quote, and if a claim cannot be paired, delete the claim.

Then save them, and re-run the brief.

The new version is noticeably worse to read, and much better to own. It is about half the length. The problem section now stands on four quoted items and says so. The workaround section is solid, because the sources actually cover that ground well. The cost section is two sentences long: one job of about eleven hundred pounds reported by one plumber, and one review in which a customer went elsewhere after three unanswered calls over two days, with no amount attached. No forty percent anywhere.

And then the section that was missing before, which is the most useful thing on the page. Unknown, must be asked in a real conversation: how many enquiries each business receives in a week; how many of those go unanswered; what an average job is worth to each of them; whether the owners believe they are losing work, or only that answering the phone is annoying; who currently picks up when the owner cannot; and whether anyone has ever paid for help with this.

That thinness is progress: it is the actual state of the evidence, finally visible. Twelve items of anecdote from people who do not count their enquiries. The first brief hid that behind a paragraph of prose. The second brief shows it, and in showing it, hands you the questions to take to real people. You could not have written those questions from the hunch, because the hunch already assumed the answers.

The model, the application and the agent

Three different things did the work above, and keeping them apart lets you predict what a tool will do before you rely on it.

The model is the trained system that produces text. Training is the process that produced it: an expensive, one-off process that adjusted the model's internal numbers, its weights, until it became good at continuing text. That happened before you ever met it, and nothing you type changes it. What you do when you use it is called inference: the trained system takes whatever is in front of it and produces a continuation. This is exactly why the forty percent figure appeared. The model has read enormous quantities of writing about small business, and "typically lose around forty percent" is the kind of sentence that plausibly continues a paragraph about slow response times. Producing plausible continuations is what it is for. It has no separate faculty that checks whether a sentence is in your documents, unless something makes it check.

The assistant application is the software wrapped around the model: in this chapter, Claude's web application, and specifically its Projects feature. The project, the uploaded files, the saved instructions: none of that is the model. It is bookkeeping that the application does on your behalf. When you saved those project instructions, nothing about the model changed. The application simply agreed to put those instructions in front of the model at the start of every conversation in that project. That small mechanism is doing most of the work in this chapter, because the difference between a chat and a delegation is mostly a matter of what the application reliably puts on the desk.

Knowing that also tells you how to verify. In the Project Knowledge pane you can click any uploaded document and read its raw text inside the workspace. So the audit is a two-step move: ask in the conversation for the exact sentences it used, then open the document and look. If the quoted words are not there, they were generated, and you have caught it in the only way that reliably works, by looking at the source yourself. The web chat does not hand you interactive citation widgets to click, which is why the bracketed-quote rule went into the instructions.

A tool-using agent is the third thing: a system that can take actions in other software, such as reading an inbox, writing to a spreadsheet or calling another service, as well as producing text for you to read. Nothing in this chapter was an agent in that sense. You uploaded files by hand and read the result by eye, and the only thing that changed anywhere was a document inside your own project. Once actions are involved, the questions change. With text, the question is whether the claim is supported. With actions, the question is what happened in the other system, and whether it should have.

Context is what the model can see during a single run. The project's saved files and instructions are application state: durable, but living inside one product. Neither of those is a business record. Once you have customers, their details will live in a system of record that exists whether or not you ever open this assistant again. Confusing the three is how people end up with important company information stranded in a chat history.

Know when to keep going and when to start clean. If a conversation is long and has drifted, or if you have corrected the same fault twice, start a fresh conversation inside the project. You lose the chatter and keep everything that matters, because the project holds the sources and the instructions, and the thread holds neither. That is the practical payoff of the container, and it is why the first move in delegating any work is to make one.

What you have now is a reusable research workspace, with numbered sources and instructions that will govern the next run, and one brief you can defend, sentence by sentence, to anyone who asks where a claim came from. Neither survives a chat window. What you do not have is evidence that anybody will pay you, and your own brief says so in a list of six open questions. Before anything larger gets built on top of that workspace, there is a plainer thing to understand about the container itself: what a project actually puts in front of the model when you press send, and what it quietly leaves off the desk.