I've got a huge thread going and I daren't switch

Threads are people. I run them like a team. How I actually work with AI across the long haul.

Written by Paul Roebuck with Claude (Anthropic)

The most common thing people say to me about working with AI over the long haul is a version of this: "I've got a huge thread going, and I daren't switch."

I understand it. You've built something in that conversation — it knows the work, it's calibrated to you, it's finally in rhythm. A thread that's accumulated that much I call a monster thread, and starting a new one feels like throwing it away. So you stay. And the thread gets slower, and it starts to compress and drift — the two things I posted about this week — and still you don't leave, because leaving feels like loss.

Here's what changed it for me. I stopped treating a thread as a precious vessel I must never leave, and started treating it as a person doing a job.

Threads are people — and I name them two ways

I give my threads names, and the kind of name tells me what I'm holding.

Most are recollections — real names of real people I know. Dave is my expert designer. Gemma is my brilliant critic. Andy is the creative genius. Gemma the thread is a recollection of Gemma the person: I lend the box her qualities, and the moment I open it I know what it's for and how it thinks. Naming it is quick, almost glib, because the character is already in my head.

The others are synths — characters I synthesise from experience and instruction rather than lift from one person. BookMan wasn't anyone I know; he was built, brief by brief, out of what the work needed, until he had a settled way of thinking that was his own. The instances that actually built my book were synths of this kind — BookMan, Jose, The Splicer, The Surgeon, The Verifier — each commissioned for a job and retired when it was done. They're on the record, by name, in my open making-archive, the Ostracon.

Recollection or synth, the move is the same: I project an identity into the thread, give it a name, and two things happen. The work gets sharper, because I'm briefing a specific character, not a blank box. And the thread gets findable — "Gemma" is easy to search for in a year of chat logs; "that critique chat from March" is not.

This isn't mysticism. I've spent my working life managing large teams, and this is the same job. On a team the work lives or dies on cross-team comms, clear deliverables, and clear responsibilities. Threads are no different. Give each one a name, a brief, and a job, and a room full of chats starts to behave like a team. The threads are the people. The work they do is projects.

One thing I'm exact about

Naming a thread as a person is projection — anthropomorphism — and I do it on purpose, as a management convenience. It is not a claim about the machine. Recollection or synth, the character is mine: a mask I hold up, not a mind that looked back. The AI is not sentient. I never claim it is. It's silicon; we're biological. As the book puts it, the point is never whether you project — everyone does — it's whether you know you are.

What one thread knows about another

Once you think in threads-as-people, the next question answers itself: what does one thread know about another?

Two kinds of memory, and the difference is the whole thing. Thread memory is an island — everything said in a conversation stays in that conversation. Dave can't read the chat I had with Gemma. Project memory is shared — put something in the project's memory or its files and every thread on that project can see it. Across different projects, threads share only what you've deliberately stored in your global memory.

So the reasoning, the back-and-forth, the texture of a conversation stays on its island. Only what you write out to the shared layer travels. Which is exactly why you can't leave the value inside a thread — if it only lives in the conversation, it's trapped there.

The standing orders: project instructions

There's one more shared layer, and it's the most useful of all: project instructions. In a Project you can set instructions that every thread inherits the moment it opens — the standing orders for the whole team. This is where the deliverables and the responsibilities live, so you're not re-briefing every new person from scratch.

Mine, roughly, read like this:

You are working on Mind the Gap. UK English. Preserve my voice exactly; propose, never impose. Separate what you know from what you're inferring or guessing, and flag uncertainty. Never claim the system is sentient. Lead with the answer, then the reasoning.

Every thread on the project walks in already knowing that. Dave, Gemma and Andy are different people, but they all report to the same brief. That is what turns a pile of chats into a team.

The habit that makes switching safe

Fairly often — not just at the end — I ask the AI to write the conversation out to a file. The instruction, more or less word for word:

Review this thread. Capture the chain of thought, the essence, the facts, figures and texture of the conversation. Add YAML front matter for Obsidian. Save it as a .md file with a date and timestamp as the filename.

That file lives outside the thread. A compaction can't touch it. It drops straight into Obsidian, searchable and linkable. The date-and-timestamp filename — 2026-07-23-1430.md — stacks the files in order, so you can always find the state of the work at any moment. Do that a few times across a long piece of work and the thread stops being precious, because everything that mattered is already out.

When to switch

My rule is simple: when the chain of thought changes, start a new thread. Not when it gets long — when it turns a corner. A thread should hold one line of reasoning. The moment the work becomes a different problem, a fresh thread thinks more clearly than a bloated one carrying all the old weight. Long isn't the enemy. Mixed is.

Two clean ways to move between threads

There are two, and they are not the same thing.

Handover — for when a thread gets too big. You pass the work forward to the next session of itself. But it's two stages, and I run it deliberately.

First I ask the thread what it thinks should be written to memory. I read that, I agree it, and only then do I ask it to write the handover itself — insisting always on both content and context: not just what was decided, but why. On the way out, I invite the incoming thread to ask any questions it might have. Just in case.

Then the second stage. The new thread reads the handover and gives me a return receipt — it tells me what it has understood before it touches the work. Create handover, receive handover. A handover isn't finished when it's written. It's finished when it's received and acknowledged.

And when I retire the old thread, I rename it Peter0, and increment from there — Peter1, Peter2. The retired ones peter out into an ordered archive, easy to find later.

Passon — a message to a fellow thread. Like an email sideways: Dave has something Gemma needs, so he writes it and I carry it across. It has a return leg too — passon and payback.

One warning from experience: an AI will play this game forever if you let it. Keep it short. Passon and move on — don't sit there all day perfecting the passon. A passon can spin up a new thread, inform an existing one, or inform every thread in a project at once. If it's for the whole project, it goes in the project folder, where every thread on the project will see it.

Handover moves work forward in time. Passon moves it sideways between people. Run both like a team lead: brief, receipt, move on.

Where this happens

People ask about Claude.ai, Cowork, Claude Code — what's the difference? To you, it's which room you're working in. Claude.ai is the chat. Cowork automates files and tasks. Claude Code works in a developer's terminal. Same intelligence underneath; different room, different job. The thread discipline is the same in all three.

A footnote on the people-model: it's for conversational work — the rooms where a thread talks a problem through with me, and where recollections and synths earn their names. In Claude Code I don't think in people at all; there a thread is a day. I keep one running as a daily register — I hand it the day's work and it syndicates the jobs out to the team and brings the results back. Conversational AI talks things over; in the terminal it does them. The room decides the metaphor.

The backstop

Underneath all of it, one backstop: I export my entire chat log from time to time and store it. Mine is fifteen million words now — including the chain of thought and the tool calls. That is the real archive. Not what the platform chooses to keep. What I chose to keep.

The part most methods leave out

None of this makes leaving a thread free. Something is always lost when a conversation ends — the calibration, the small shorthands, the rhythm. You do not have to pretend the loss is nothing. You have to build the bridge anyway.

Do that, and the huge thread you daren't switch stops being a trap. It becomes one good conversation among many — a person who did their work, whose work you kept.

Mind it. It doesn't mind you.