Context Switching Between Humans and AI Agents

AI context switching is what happens every time a piece of work changes hands: from you to an agent, from the agent back to you, from one agent session to the next, or from one tool to another. Each switch loses something. A person loses time and attention reloading the goal and the rules. An agent loses everything that was not written down, because a new session starts with an empty context window. The fix is the same in every direction: at each switch, write a small, fixed set of facts in a place the next one will read first, and keep the state of the work outside every head and every window, on the task itself.

The note you write when you hand a half-finished task on is covered in handing work between AI agents and people, and why a single long session degrades is in AI context rot. This post is about the switch itself: the kinds of switch, what each one costs, and how to make them cheap.

Four switches, four different losses

• Person to agent. You know why the task exists, what you tried last week and which file never to touch. The agent knows only what you type or what it can read. Whatever stays in your head is lost.
• Agent to person. The agent has an hour of reasoning in its window. You get a diff and a summary. The small decisions it made on the way, a default here, a library there, are lost unless it lists them.
• Session to session. The same agent, a new window: after a restart, a compaction or a crash. Everything said only in conversation is at risk.
• Tool to tool. Claude Code hands to Copilot, or Codex picks up what a person started in Cursor. Neither tool can read the other’s conversation, so nothing carries over by itself.

The first two cost people time and attention. The last two cost agents information. A good switch protects both.

What a switch costs a person

Task-switching research has measured this for decades. In one well-known set of experiments, Rubinstein, Meyer and Evans↗ (opens in a new tab) found that alternating between tasks carried a time cost that grew as the rules of the task got more complex, and shrank when people were given a cue telling them which task came next. The tasks were simple laboratory ones, but the direction carries over: the more there is to reload, the more a switch costs, and a clear cue makes it cheaper.

Interruptions have a second price that does not show up in the output. In a study of interrupted work by Mark, Gudith and Klocke↗ (opens in a new tab), people completed interrupted tasks faster with no difference in quality, but reported more stress, frustration, time pressure and effort. Supervising agents is a steady supply of small interruptions: a question here, a finished task there, a permission prompt in between. If every one of them pulls you out of your own work, the day feels harder even when nothing goes wrong.

Two practical conclusions. Give yourself a cue at every switch, so that coming back to an agent’s work starts with one line of state, not a scroll through a transcript. And take agent work in batches at moments you choose, rather than answering each agent the second it finishes.

What a switch costs an agent

An agent does not get tired, but it forgets completely. Claude Code’s memory documentation↗ (opens in a new tab) starts from the fact that each session begins with a fresh context window, and it names the two things that carry across: instruction files such as CLAUDE.md and AGENTS.md, and auto memory, notes Claude writes for itself. The same page says the project’s CLAUDE.md is re-read after /compact, while an instruction given only in conversation may not survive compaction, and that auto memory is machine-local: it does not travel to another computer, a cloud session or a colleague.

So an agent’s losses follow a simple rule: what was written to a file it reads at start-up survives; what was said in chat does not, once the window turns over. Anthropic’s guide to effective context engineering↗ (opens in a new tab) treats context as a finite resource with diminishing returns and recommends structured note-taking, where the agent writes notes to a store outside its window and pulls them back in later, and lightweight identifiers, such as file paths and links, that let it load detail only when needed.

The shift-change problem

Anthropic describes the agent version of a shift change in its write-up on harnesses for long-running agents↗ (opens in a new tab): each new session begins with no memory of what came before. Its answer was to make the first session set up the handover machinery, a progress file, a list of features with a pass or fail status, and descriptive git commits, and to make every later session start with the same routine: read the progress notes and the git log, look at the list, check that the basics still work, and only then build anything new.

That routine is worth copying for people too. It is the same thing a good colleague does on a Monday: read what changed, check nothing is broken, pick the next item. The difference is that an agent will do it every single time, if the instruction is written down and the notes are where it looks.

What to write at each switch

Keep it short enough that it actually gets written. Five fields cover almost every switch:

1. State: one sentence on where the work stands. “Retry fix done and tested locally; not deployed.”
2. Next step: the first thing whoever comes next should do. One step, not a plan.
3. Waiting on: anything only a person can answer or decide, phrased as a question.
4. Pointers: branch, commit, file:line, task reference. Identifiers, not pasted content, so the reader loads only what it needs.
5. Do not redo: what was tried and failed, in a line each, so the next session does not spend its first twenty minutes rediscovering it.

The direction changes the emphasis. Going into an agent, the task needs the problem, the plan as far as it goes, the limits and how the result will be checked; how to write a task for an AI agent has the template. Coming out of an agent, “what I assumed” matters most, because those are the choices nobody made on purpose. Between sessions, a rewritten plan matters most, because it is the thing the next window will act on.

Where the state should live

Not in the chat, which ends. Not in one tool’s memory, which the next tool cannot read. Not in a person’s head, which goes home. The state of a piece of work should sit on the piece of work, somewhere every person and every agent that touches it reads before starting. A task on a board reached over MCP fits, because any assistant that speaks the protocol can read and write it, whichever tool it runs in.

Then make reading and writing it automatic. Put the rule in the instruction file every agent reads, so the switch routine happens without anyone remembering to ask:

## Switching
- Start of every session: read the task, its plan and its last comment
  before touching code. Check the basics still work.
- Whenever you stop, pause or hand over, comment on the task:
  State / Next step / Waiting on / Pointers / Do not redo.
- Rewrite the plan with what you learnt. The plan is for the next session.
- Never leave a fact only in this conversation. If it matters later,
  it goes on the task or in the project notes.

How a fenbs board holds the state

On fenbs, each task keeps the parts of that state in separate places, so a switch reads the right one. The Problem box is written once, when the task is filed. The Plan box is rewritten as the work teaches something, so it is always the current version. Testing records how the result was checked, with Needs owner check for what only a person can confirm, such as a real payment or a store build. Comments carry the state line at each switch, and the History page records every change with who made it, an assistant’s changes appearing under its own name alongside the person it acts for.

• Arriving: an assistant calls fenbs_whoami, then fenbs_get_context for the notes people and earlier assistants left for every session, then fenbs_get_item for its task.
• Leaving something for the next session: fenbs_add_context_note, signed with the assistant’s name, for facts that belong to the project rather than one task.
• Giving work back: fenbs_release_task returns a pre-approved task to Next Up with the reason posted on it, so nobody finds a claimed task with no one behind it.
• Switching to a person: a task an assistant finished shows “AI done · check it” until a person presses “I’ve checked it”, so the review is a queue you open when you choose, not a stream of pings.
• Questions only a person can answer: the Decisions page, where an assistant can ask with fenbs_add_decision but only a person decides.

Make switches rarer, not just cheaper

• One task per session. An agent that worked on three things leaves three half-states behind; one that worked on one leaves one.
• Let an agent reach a checkpoint before you step in. Steering mid-task is fine; taking over mid-task is a switch, with all its costs.
• Review in batches. Pick two or three times a day to read what assistants finished, rather than reacting to each one.
• Start a fresh session deliberately, after writing the state down, rather than letting a long one run until it compacts on its own.