The job is twelve pages of documentation, or eight endpoints, or a rewrite that touches thirty files. You start it in one session. By hour two the model is contradicting decisions it made in hour one, and the last four files are visibly worse than the first four.

The idea

A session degrades as it fills. The fix is to stop treating the whole job as one session and start treating it as several, each starting clean, each reading its instructions from files rather than from a conversation. The same move works sideways: several running at once, each on an independent piece. Both patterns rest on one fact. Files cross the boundary. Conversation does not.

code
  ONE LONG SESSION              SEVERAL FRESH SESSIONS
  ────────────────              ──────────────────────
  ctx ████░░░░  file 1 good     s1: ██░░  ch.1  ──┐
      ██████░░  file 2 ok       s2: ██░░  ch.2  ──┼─► same plan file,
      ████████  file 3 drifts   s3: ██░░  ch.3  ──┘   same conventions,
      ████████  file 4 wrong                          fresh context each

  what crosses the line:   plan file, spec, the code itself, PROGRESS.md
  what does not:           "as we discussed", "the approach from earlier",
                           anything you only ever said out loud

How it works

Splitting downward, into sequential sessions, means writing the plan before the first one. A file that names each slice, the conventions every slice must follow, and the order. Session two does not remember session one, so anything session one decided has to be in the plan file or in the code before session two opens. Then you run them one at a time, and each one updates the pointer file when it finishes.

Splitting sideways, into parallel subagents, works when the pieces are genuinely independent. Claude Code can run several at once, each with its own context, and they report back to the session that launched them. It suits fan-out work: drafting eight documents against one shared spec, or searching a large codebase from four angles at once.

Two limits shape everything here. Subagents do not see each other's work, so two of them can invent two different names for the same thing, and neither knows. And the review burden does not shrink. Four agents produce four diffs, and the part of this that only you can do, deciding whether the output is right, now arrives four times at once.

What to do

  1. Before splitting, write the shared contract: one file with the conventions, the format, and the boundaries every slice must respect. Without it, parallel work produces four confidently inconsistent results.
  2. Split along file boundaries, never across them. Two agents editing the same file at the same time is a merge conflict you created deliberately.
  3. Give each slice its own verifiable finish, such as "the build passes and the new page renders". A slice you cannot check is a slice you will accept on faith.
  4. Review each result as it lands, not all seven at the end. The second review is where you find the convention drift, and finding it after seven is expensive.

Where it breaks

Parallelism helps when the pieces are independent and hurts when they are not. Anything where slice two needs to see what slice one decided should stay sequential, because the alternative is discovering the disagreement during integration.

There is also a cost that is easy to miss. Every parallel agent is a full session with its own token spend, so four agents on a job that did not need splitting cost roughly four times as much and produce more text for you to read. Before orchestrating five agents, check whether the job can simply be made smaller. Most of the time the reason a session drifted was that the slice was too big, and five agents on five slices that are still too big drifts five ways at once.