The AI orientation tax: it's missing context, not discipline

You have eleven things in flight. Three of them are "almost done." You can't remember which three. Every morning you spend the first ten minutes rebuilding the picture (what was I on, where did I leave it, what's actually next) before you do any real work. And the coding agent you brought in to go faster starts every session asking you the same questions you just answered yesterday.

The usual diagnosis is discipline: you start too much, you don't finish, you're scattered, get a system and stick to it. I think that diagnosis is wrong, or at least aimed one layer too high. The people who actually dug into this landed somewhere else: it's missing context, not discipline. And the interesting part is that your agent now pays the exact same tax, for the exact same reason.

This is a post about that tax: what it is, what it costs (there are numbers), why the AI era makes it worse instead of better, and the small loop where it actually breaks.

Picture a normal day with three projects going at once. Underneath the actual work, you're running a second, smaller loop all day long:

That loop is cheap when you're running one thing. It gets expensive fast when you're running several phased threads at once, because now you're holding all of it in your head, and your head has a ceiling. Past that ceiling, you start paying what I'll call the orientation tax: the time and attention you burn just staying oriented (re-contextualizing, re-deciding, re-finding your place) instead of moving the work forward.

The tax is small per hit and easy to dismiss. That's exactly why it's expensive: you pay it dozens of times a day and never see the bill.

The dominant framing for this is moral. You have too many half-finished projects. Finish what you start. Stop being a magpie. It shows up everywhere in dev culture, and it feels true, so nobody questions it.

But look at what the people who took the problem seriously actually concluded. The developer behind I Have 47 Unfinished Side Projects expected the lesson to be discipline, then landed on

Here's the distinction that matters, because it's easy to blur. Deciding what to start is a selection problem: upstream, real, but not this one. The tax I'm describing starts after you've committed. You've got work you've decided to do, broken into pieces, and the cost is just staying oriented across it. The grassroots fixes all quietly agree the lever is context (a single status home), not willpower. The discipline frame keeps people optimizing the wrong variable.

"Staying oriented" sounds soft. The cost isn't.

Three angles on one cost: per session (the agent), per interruption (you), per year (the team). Two honest caveats, because the credibility is the point. The 23-minute refocus comes from Gloria Mark's interruption research, usually reported second-hand, so treat it as directional, not gospel. The 12-minute/session figure is newer and thinner: one developer's week of self-tracking. Strong as illustration, not yet replicated. I'm citing both as what they are.

But the direction is unambiguous, and the two tiers point at the same thing: the cost of losing the thread, multiplied by how often you lose it.

You'd expect a coding agent to reduce this. It does the opposite, in two ways.

First, it raises the thread count. Agents let you start more and ship faster than you can stay oriented. Every capability jump (faster models, parallel agents, longer task horizons) increases how many pieces a solo operator can have in flight at once. That's the exact input that drives the tax. More throughput, more to keep straight.

focus / context-switching research (decades, pre-AI)
        |  attention is serial; switching is costly
        v
indie-maker "too many threads" culture (2010s ->)
        |  more starts than you can hold
        v
agent era (2024-2026)   <-- the amplifier
        agents let you START more and SHIP faster than you can orient,
        AND the agent itself loses the thread between sessions

Second, and this is the new part: the agent pays the tax too. It starts every session cold. As one tooling write-up puts it, model weights are frozen, the context window rebuilds from scratch, and "most tools do not write cross-session memory by default. Manual files like AGENTS.md help, but they drift." That drift is the same staleness that rots your own notes, now happening to the agent.

And it's not a one-way street where your mess flows downhill into the agent. The sharper read: you and the agent are running the same loop on the same work, on two different clocks. Your clock spans days and weeks. The agent's clock is the session, and it resets every time. When you ship fast, you spin up many sessions, often parallel, across days. Nothing inside a single session can carry the picture across all those resets. The agent reaching for AGENTS.md

, the threads asking "how do you handle context loss between Claude Code sessions?": that's the agent trying to run check-state and review and failing for lack of a durable, shared list. Same break as yours, different clock.

Step back and the whole thing collapses into a single mechanism. The tax isn't five unrelated annoyances. It's one loop breaking for one reason: there's no single honest list to run it on. Take the list away and watch each act fail in order:

That's the give-away here, the part worth keeping even if you never touch any tool: when your multi-threaded work feels like it's slipping, don't reach for more discipline. Find the act of the loop that's breaking, and notice it's breaking because nothing holds one honest list.

If the problem is this legible, why is the slot empty? Because the field inherited the discipline frame. Orientation got filed as a pre-existing human-character problem (be more focused, start fewer things), so when agents arrived, nobody built the AI-native answer for it. The tooling that did get built lives one layer down, on execution: making the agent build a single task correctly (spec files, rules files, memory stores). All useful. None of it keeps you and the agent oriented across the whole board of in-flight work.

So the pain is mainstream and well-documented, but the solo-operator-plus-agent framing is young and mostly open. The vocabulary is even splitting in real time: "context switching" on the productivity side, "agent memory" and "persistent context" forming on the tooling side, both circling the same hole from opposite directions.

Your scattered board and your forgetful agent are not two problems, and neither is a discipline problem. They're one orientation problem: nothing holds a single honest picture of what's in flight, so you keep rebuilding it from memory and the agent keeps inheriting a broken copy.

The fix isn't to want it more. It's to give the loop one surface to run on: honest, shared, and gated, so the honesty doesn't ride on memory. A board you reconcile before you build on it, instead of one you hope you updated. That's a design problem, not a character flaw. I've been building toward an answer to it, and that's the next post. This one only had one job: to get you to stop blaming your discipline for a context bug.