The hard part of a long agent run is not starting it. It is being able to walk away, come back on a different device, and still know what happened.

These are the habits that make that true. None of them are clever; all of them are learned the same way.

1. Run it somewhere that stays on

Everything else on this list assumes the machine is still there. A laptop is not: it sleeps, changes network and runs out of battery, and each of those ends the run. Once the process lives on a machine that stays awake, your laptop becomes a viewer — and a viewer can disappear without consequence.

2. Give the session a name you will recognise in six weeks

Name it after the project, never after the task. clientname is useful in a month; fix is not useful by Thursday. You will reattach to something you have entirely forgotten, and a list of unnamed sessions tells you nothing at all.

3. Keep real scrollback

Agents are verbose. A default of two thousand lines of history disappears inside one large refactor, and the part you want is always the part that scrolled away — the command it ran before the failure, not the failure. Raise the limit to tens of thousands of lines before you need it, because you cannot raise it retroactively.

4. Write the important runs to a file

claude 2>&1 | tee ~/runs/refactor-payments.log

Scrollback is memory; a log is a file. For anything you might have to explain later — a migration, a dependency bump, anything that touches money — send it through tee and keep the file. It also means you can grep the run instead of scrolling it.

5. One job per window

A useful layout for agent work is three: the agent, a shell where you inspect what it did, and something watching — tests, logs, a resource monitor. Trying to do all three in one pane means you stop the agent every time you want to look at anything.

6. Watch memory, not CPU

Runs rarely die of CPU. They die because several agents, a database and a browser were all resident at once and the machine ran out of memory — and the thing the kernel kills is usually not the thing that caused it. free -h before you start a fleet, and give the machine swap so a spike becomes slowness rather than a dead session.

7. Parallel work goes in separate worktrees

git worktree add ../checkout feat/checkout
git worktree add ../webhooks fix/webhooks

Two agents in one directory will fight over the same files and produce a merge you cannot review. A worktree each gives them separate directories against the same repository, and the practical ceiling stops being conflicts and starts being memory.

8. Detach on purpose, not by closing the lid

Closing the laptop works when the run is somewhere else, but detaching deliberately leaves you with a session you know the name of and a clean prompt to come back to. It is a two-second habit that turns "is it still running?" into a question you can answer from a phone.

The two people learn the hard way

Sizing to the smallest screen. Attach from a phone once and some setups will size the session to phone width — and leave it there when you return to a desktop. Configure sizing to follow the client currently looking, not the smallest client that has ever looked.

Sessions that end when the last viewer leaves. Some configurations tear down a session when nobody is attached, which is precisely the behaviour you were trying to avoid. Turn it off before you rely on it, not after.

The mental model worth keeping

Your laptop is a viewer, not a host. Every habit above follows from that one sentence — and if you would rather not assemble them yourself, that is exactly what we sell: the do-it-yourself guide is here, and the managed version is a minute away.