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.
The tax you're already paying
Picture a normal day with three projects going at once. Underneath the actual work, you're running a second, smaller loop all day long:
- capture: get what's on your plate into view
- check state: figure out where each piece actually is
- prioritize: pick what's next
- review: at the end, see what got done
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 misdiagnosis: "just have more discipline"
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 context instead: of the 47, the one project that actually shipped was the one that started from a real problem he had right now ("I literally need this tomorrow"), not from forcing himself to finish the rest. Bonaventure Ogeto keeps what he calls a "projects parking lot": a single place to log every project and its current status, so you always know where everything lives and nothing feels lost. That's not a discipline fix. It's an orientation fix: one honest place where the state of in-flight work lives.
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.
The numbers (it's expensive, and some of it is measured)
"Staying oriented" sounds soft. The cost isn't.
| What | Figure | Source |
|---|---|---|
| Re-teaching the agent at the start of every session | ~12 min/session ≈ one workday/month | Ma (self-tracked) |
| Refocusing after a single interruption (complex work) | up to 23 min | Gloria Mark / APA |
| A 10-dev team losing 20% to switching | ~$240,000/year | onehorizon |
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.
The AI era makes it worse, not better
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.
It's one loop, and it breaks in the same place every time
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:
- No list → capture fails. Committed work never lands in one place, so you orient on a partial view.
- → check-state fails. State isn't updated, so the list (such as it is) lies: it says "in progress" for things that are done or dead.
- → prioritize fails. What matters shifted; nothing flagged it; you keep working yesterday's order.
- → review fails. Closure was never recorded, so "what did I actually ship this week" is unanswerable, and it stays invisible until the shame shows up.
- → it cascades. Every break above is inherited by the agent, which is reading the same broken picture.
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.
Why nobody's built the fix
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.
The reframe, in one line
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.
Sources
- Agent context loss: Augment Code, "Why AI Agents Keep Asking the Same Questions"; Marvin Ma, "Why Your AI Coding Agent Keeps Forgetting Everything" (the ~12-min/session figure).
- Interruption and team cost: Gloria Mark / APA interruption research (via secondary reporting); onehorizon (the ~$240k/yr figure).
- Maker self-diagnoses (the 47-projects and parking-lot pieces) are linked inline. Full source ledger lives in the problem-convention dossier.
Top comments (1)
The reframe from discipline to context is the right one, and the part that hooked me is that the agent pays the same tax for the same reason. We anthropomorphize it as "the AI keeps forgetting," but really both you and the agent are re-deriving state every morning because the state lives in your head (or in a scrolled-past chat log) instead of somewhere both of you can read.
That's the actual fix, and it's boring in a good way: externalize the orientation loop into a shared store — what's in flight, what state each thread is in, what's next — so the human's "capture / check state / prioritize" and the agent's context bootstrap are reading from the same source of truth. When they diverge is when you get the agent confidently re-suggesting the thing you rejected yesterday.
Where do you see the loop actually break first — is it the "check state" step (figuring out where each thread really is), or "prioritize"? My hunch is check-state, because it's the one that silently rots the moment you touch a thread without recording the delta.