They separate every task into its data, logic, and presentation before asking AI to handle any of them
Chapter Progress: Early DraftPicture a task you give AI often: take this quarter's sales numbers and write a short summary the leadership team can read in two minutes. As of 2026 you do this by typing it all into a chat model, and the interface will keep changing under it, to voice, to glasses, to an earbud you talk to on a walk. Whatever you are talking to, one request like that asks for four things in the same breath. The model has to find and read the numbers, work out what they mean, decide what a leadership team cares about, and shape all of that into clean prose. It does each of those jobs at half strength because it is doing all of them at once. The summary comes back smooth, confident, and a little off in a way you cannot quite point to. The reason is that one request is carrying several different jobs at once, and pulling those jobs apart is what clears it up.
The cleanest way to see the split is to name the three questions it asks. Every complex task answers, in order: what does this need to know, what should it figure out from that, and what should the result look like for whoever reads it. The first question is the data. The second is the logic. The third is the presentation. Asking AI all three at once tends to produce the smooth-but-off result. Asking them one at a time, with a way to check each, is what lets you steer the output toward what you actually wanted.
The prose above has built the felt idea: one tangled request becomes a few focused ones, each handling a different kind of work. Here is the formal name.
The reason to split a task is that it makes each part checkable. When reasoning and formatting are tangled together, polished prose hides flawed analysis: the writing sounds authoritative, so you stop questioning what it says. When the parts are pulled apart, you read the raw analysis before any of it gets dressed up, and a shaky conclusion is easy to catch while it is still rough. The split converts a single hard-to-judge output into a few small ones you can each judge on their own.
Name what the task needs to know before what it needs to do
Every complex AI task has a data layer: the facts, sources, context, constraints, and raw material the model needs before it can reason about anything. A casual user buries that data inside a long prompt, mixed in with the instructions, the formatting requests, and the notes about the audience. A power user pulls the data out and presents it on its own, so the model can take it in before it is asked to do anything with it.
The data layer answers a short set of questions, and naming them is most of the work. What does AI need to know for this task? Which sources should it draw from? Which facts are fixed and not up for interpretation? What background sets the scene? Pulling the data away from the instructions means the model is not trying to take in the source material and follow directions in the same pass. It reads the facts first, then follows the directions. The output of this layer is a real artifact you can name and reuse: a labeled set of sources and facts, or a data-connector instruction that tells the system where to pull them from each time.
Return to the sales summary to see the difference. The don't-apply version pours the data and the ask into one stream. You type the quarter's numbers, three side comments about what was unusual, a note that this is for the leadership team, and the instruction to keep it short, all in one message, and you hope the model sorts it out. The do-apply version gives the model the numbers first as their own thing: paste the figures, or load them into a project and point the model at them, or hand them over in a clean table before you ask for a single word of analysis. As of 2026 that looks like a file or a pasted block; on glasses or an earbud it looks like the model pulling the figures from a source you named. Either way the model reads the facts as facts before it is asked to think.
The forms the data layer can take group into three families, and keeping every one in reach means you always have a way to separate it. The first is in-line material: you paste the source document or the figures into one message and put the instructions in the next. The second is attached material: you load the data into a project or connect a source, then prompt against it. The third is structured material: you arrange the facts as a table, a list, or labeled fields before you ask for any analysis. All three do the same job, which is to let the model take the data in cleanly before it reasons.
Separate the reasoning from the shaping of the result
The logic layer is where the model reasons: it decides, analyzes, compares, ranks, or judges. The presentation layer is where it shapes that reasoning into a result for a particular reader: the format, the structure, the tone, the length. These are different kinds of work, and asking the model to do both in one pass weakens both, because each one is pulling its attention away from the other.
Stay with the sales summary, now past the data step. The don't-apply version asks for the finished thing in one shot: analyze the quarter and write the leadership summary. In that single request the model has to find the trends, draw the conclusions, decide what leaders care about, and format it all for them at once, and you receive a polished page with no way to see whether the thinking underneath it holds. The do-apply version splits the thinking from the shaping. First you ask the model to analyze the numbers and lay out the key findings in plain rough form. You read those findings and check the reasoning while it is still easy to question. Then you ask it to shape those reviewed findings for the leadership team, with the right tone, structure, and emphasis.
The split works because rough analysis is easy to inspect and polished prose is hard to question. Once a shaky conclusion is wrapped in confident, well-formatted writing, your eye slides past it. Catching it earlier, while the reasoning is still bare, is exactly why you want the thinking step to finish and pass your review before the shaping step starts.
Read the layers to find where an AI output went wrong
When an AI output is wrong, the three layers tell you where to look. Was the data wrong or missing? Was the reasoning flawed? Or was the analysis sound and only the way it was presented misleading? Without the split there is one flat verdict, 'the output was wrong,' and no clear next move.
Each kind of failure points to a different repair, and the three layers sort them. A summary that reaches the wrong conclusion might have a data problem, like a missing piece of context or the wrong source. It might have a logic problem, like a faulty comparison or a cause claimed from a coincidence. Or it might have a presentation problem, like sound analysis buried under an emphasis that points the reader the wrong way. Naming the layer that failed turns a vague 'try again' into a precise fix, so one part gets redone instead of the whole task.
You do not have to do that sorting by hand every time. Because the layers are separated, you can hand the model its own data, logic, and presentation steps and ask it to analyze which one produced the error, against the standard you set. A short evaluation prompt that names the failure modes to watch for can run that check on every output and report the layer it suspects, so a person reviews the call instead of doing the diagnosis from scratch. This is the same move the chapter on turning failures into reusable specifications develops in full: once a failure is named, it can be written down as a rule the system applies next time, so it does not break the same way again.
A fourth layer, evaluation, sits beside the first three and is the one power users add on purpose. After splitting out the data, the logic, and the presentation, they define the standards separately: what the output has to meet, what a good example looks like, and which failure modes to watch for. When the standards are tangled into the production task, a poor result leaves you unable to tell whether the trouble was bad input, bad reasoning, bad shaping, or a bar you never set. Pulling evaluation out gives you a clean place to ask the only question that resolves that: against what?
Split a task apart before you run its parts in parallel
The layers you name here are what the next two chapters build on. The chapter on giving each conversation one focused job and the chapter on running output through a second model as an editor both start from a task you have already split. You can give a thread one focused job once you know what the separate jobs are. You can hand a second model the role of editor once you have separated the reasoning from the way it is presented.
A split task is what the parallel and editing moves run on. Once a task is broken into its data, logic, and presentation, each layer can go to a different conversation, a different model, or a different stage of a workflow. Naming the parts comes first; running them apart comes after.
Use enough splitting to make checking possible, and no more. A quick lookup stays one prompt. A leadership-ready analysis built from rough, scattered sources earns its layers. Use enough structure to protect the work, not so much that the setup costs more than the gain it buys.
Once a split works for a task you repeat, the move is to evolve it into something that runs itself. Save the three prompts as a named workflow and write down which layer tends to fail. From there you climb a level: fold the evaluation step in so the system flags its own weak layer, then hand the whole sequence to a harness that runs the layers in order without you retyping them. Each pass you sharpen it where it breaks. The output of any one run fades; the workflow you keep evolving is what compounds, because it can take on more of the task each time you teach it what good looks like.