Inside the document, or across the work

The situation

The quarterly business review deck. It looks like one document: forty slides, one file, due Friday. So you open the assistant inside the deck and ask it to build the review. What comes back is forty slides of plausible headings with nothing underneath them, because the numbers live in a spreadsheet, the account notes live in the CRM, and last quarter's commitments live in a deck nobody has opened since March. The tool used what it could see. You handed it a task shaped like one document that is really shaped like four.

The principle

Most close calls between an in-document assistant and a general assistant are two tasks wearing one name: gather across the work, then finish inside the document.

The two-question test resolves most work in seconds. The tasks it does not resolve are almost never a tie between tools; they are a task you have not finished defining. So split it. The gather step has many sources and produces something small and checkable: a table, a list of numbers, six bullets with citations. The finish step has exactly one source — that intermediate — and produces the file.

Write the intermediate down before you route anything. It is the seam. If you cannot say what the gather step hands over, you have not split the task, you have only renamed it.

Worked example

Shown here in Microsoft 365 Copilot.

Four tasks from one week. The rule handles the first three. It gets the fourth wrong.

CASE 1 — Rewrite the safety briefing in plain language.
  Sources: 1        Lands: in the briefing
  Inside the document. No split.

CASE 2 — Build the QBR deck.
  Sources: 4        Lands: in the deck
  Split. Gather in Copilot chat over the sales sheet, the CRM export
  and last quarter's deck -> a 12-row table of numbers and commitments.
  Finish in Copilot in PowerPoint, building slides from that table.

CASE 3 — Answer a customer's 60-question security questionnaire.
  Sources: 2        Lands: in the questionnaire file
  Genuine close call. Gather once: standing answers keyed to question
  type, pulled from the policy set. Then finish in the file itself,
  question by question, where the answer has to sit.

CASE 4 — Reconcile an invoice against its purchase order.
  Sources: 2        Lands: a note in the finance system
  The rule says: across the work, general assistant.
  The rule is wrong here. This happens 400 times a month.

Case 2 is worth running end to end, because the seam is the part nobody writes down. The gather step, assigned in Copilot chat:

Job: Build the fact table for this quarter's QBR. Do not write any slides.

Inputs: the Q3 sales workbook, the CRM opportunity export, and last
quarter's QBR deck. Use only these three.

Output: One table, 12 rows maximum. Columns: the commitment made last
quarter, what actually happened, the number, and the file and sheet or
slide you read it from. One row per commitment.

Standard: Where a commitment has no matching number in either file, write
"not measured" and give the slide it was made on. Never carry a number
forward from last quarter's deck as if it were current.

Three of the twelve rows that came back:

Commitment (Q2 deck)       What happened   Number   Read from
Lift renewal rate to 90%   Missed          84%      Sales wb, Renewals!C14
Close 3 enterprise deals   Met             4        CRM export, rows 231-234
Cut quote turnaround       Not measured    —        Q2 deck, slide 9

That table is the seam. Every cell in the last column opens something. The finish step — Copilot in PowerPoint, building slides — now has exactly one source, and the third row is the finding: a commitment nobody instrumented, which no amount of slide-writing was going to surface.

Nothing about the shape of one reconciliation is unusual. The volume is. A task you do four hundred times is not a chat task in either chair — it is a process with a fixed input, a written instruction and an exception rule, and the thing you build once is the instruction, not the answer. Volume overrides shape. The routing rule quietly assumes you are doing the task; when the task is doing you, stop routing and start building, which is what Unit 1 meant by making it repeatable.

One other thing overrides shape, and it is not negotiable: if a source is not permitted to leave the system it sits in, the route was decided before you asked the question. Unit 5 draws that boundary.

In your tool

Every split has a seam. What differs across ecosystems is whether the gather step's output can reach the finish step without a copy-paste — and what the gather step can see in the first place.

Product surfaces checked 2026-08-04.

An in-place handover saves you a paste. It also fixes what the gather step can see: only what that ecosystem holds. A gather step whose fourth source is a PDF attached to an email is a copy-paste either way. Neither property makes a tool better — they make it better at a shape.

Try it

Take three tasks from this week that felt awkward in whichever tool you used. For each, write one line: what the gather step hands over. Not the tool — the object. "A twelve-row table of last quarter's numbers by region." "Six bullets, each with the clause it came from."

You are done when at least one of the three has become two tasks with a named object between them. If all three still read as one task, check what you wrote: you are probably describing the deliverable instead of the seam.

Common failures

• Calling it a tool problem. "This one isn't good at decks." "That one can't do spreadsheets." Nearly every complaint of this shape is an undefined task in disguise. Tools are easier to blame than briefs, and the complaint has the pleasant sound of expertise.
• The forever-gather. The research is already in the general assistant, so you write the final document there too, then spend an hour restoring the formatting the paste destroyed. The gather step was routed correctly. The finish step was never routed at all.
• Splitting it backwards. Drafting first, then gathering evidence for the draft. The finish step inherits whatever the draft asserted, and the gather step becomes a search for confirmation rather than a check.