My Director Said 'Context Window' and Meant Me

There was a little reshuffle at work.

The kind where the org chart moves around and you wake up with a new name next to “Reports to”.

Mine turned out to be a director.

Now, directors come in two flavours. The ones who live in Gantt charts. And the ones who live in the terminal.

Mine lives in the terminal. CLI tools, dotfiles, Claude Code. The works.

This matters for the story.

The Brag

I’ve been using Claude Code for a long time now. Long enough to have built my own little hack on top of it.

One of my Claude Code instances is my secretary.

I don’t open new sessions myself anymore. I just tell the secretary:

Me: Spawn a session to review that PR.
Me: Spawn a session to write the Jira story for the retry bug.
Me: Spawn a session to …

It runs a script, and a fresh session pops up, already loaded with the task.

Basically, a very polite fork().

So naturally, in one of my first proper conversations with my new director, I told him all about it.

Nerdily. Proudly. In far too much detail.

I was, essentially, bragging about my AI middle manager to my actual manager.

It Was a Lot of Terminal

He was impressed. He’d been down this road himself.

Then he said:

Him: Show me your terminal.

So I did.

It was a lot of terminal.

Panes inside windows inside tmux sessions. Logs scrolling. Three agents mid-thought. A cursor blinking somewhere. Presumably mine.

I could see him looking for a place to rest his eyes.

Me: Hang on. My secretary maintains a board. Let me show you that instead.

I opened a local HTML page. Plain. Every session, every task, what’s waiting on me, what’s done. Kept up to date by the secretary.

And that is what he wanted to look at.

Not Jira. Not a Gantt chart. Not a burndown.

A homemade HTML page on localhost, maintained by an AI I call my secretary.

That’s when I knew he was the real thing.

The Line

Then he said something I’ve been chewing on for more than two weeks now.

It was barely a line or two. Roughly:

Him: Your agents’ context windows aren’t the problem.
Yours is.

He didn’t say “attention”. He didn’t say “focus”.

He said context window.

And I understood him instantly.

That’s the thing about two engineers who have both spent too many hours watching an agent run out of tokens. Nothing needed defining. The software word carried the human meaning perfectly.

We both know what it looks like when the window fills up. When the early instructions fall off the edge. When the model starts confidently answering a question you asked forty minutes ago.

He just pointed it at me.

An agent’s context window is cheap. It fills up, you start a fresh session, it reloads its memory from a file, and it’s back. No grudges. No residue.

Mine doesn’t come with /clear.

The Scheduler

So we talked about how I actually work.

Which, it turns out, is an Operating Systems lecture I’ve been giving myself for years without noticing.

Several sessions, several repos, all running, and something has to do the job sequencing. That something is me. In theory I run round robin: cycle the tmux sessions, give each a time slice, check in, nudge, move on. A standing one-to-one with every process I own.

In practice I’m interrupt-driven. An agent finishes, a response lands, I jump, and whatever I was holding gets dropped mid-thought. Every completed task is an interrupt and I service every single one, which means nothing I’m doing is ever not preemptible. There is no protected time on that calendar. An agent can preempt me, so can a Slack ping, and a client can preempt both without filing a ticket first.

Every switch costs something. The OS saves registers and restores state. I have to remember which repo I’m in, what the bug was, and why I decided not to touch that lock. Different codebase, different conventions, different mental model, and no handover doc, because the person handing over is me from forty minutes ago.

Cold cache. Every time.

When it isn’t interrupts it’s priority scheduling, and priority just means volume. The loudest project gets the CPU. Client escalations jump the queue, always. And when nothing is loud I fall back to shortest job first, because ten-minute tasks are what a status update is made of.

Great for throughput. Terrible for the one hard problem sitting there since Monday, which is how it starves. Always runnable. Never scheduled. It’s on the roadmap.

Some work needs a mutex. Deep debugging, design, a tricky review. Exclusive access to the one resource that actually matters: my head. I run exactly one of those. No replicas, no failover. You can’t share it. You shouldn’t try.

So of course two projects want it the same afternoon. One waits, or worse, both walk away thinking they hold it, which is where contention turns into deadlock. Project A is waiting on my review. I’m waiting on Project B’s agent. Project B’s agent is waiting on a decision I haven’t made, because I’m reviewing Project A.

Nobody moves. Everyone’s busy. Nobody’s blocked, on paper.

My secretary spawns sessions beautifully. It parallelises beautifully.

But everything it spawns reports back to one single-threaded runtime.

Me.

The Question

Then he put a question on the table. Not really to me. More like he placed it there and left it.

Him: tmux will handle all of that just fine.
But what about you?
Are you doing a lot of things, or are you getting a lot done?

He didn’t wait for an answer. He didn’t expect one.

Software handles this kind of complexity well. That’s the whole point of software. Schedulers, queues, locks, retries. The machine never gets tired of switching.

Brains do.

We’re bounded by what we already know, by the stories we carry, by how much we can hold at once.

The agent gets a fresh context window every session.

I get the one I woke up with.

The Paradox

Here’s where it gets funny.

In the weeks since, the director and I have had our regular catch-ups. We brainstorm. We go through the list.

How’s this project going? How’s the other one? How’s the team doing? Are we on track with the deliverables? What’s the client expecting?

Twelve years in this industry. Tech lead across more than one project. That’s the job. That is literally what the job looks like.

The advice says mutex.

The job description says round robin.

The appraisal rewards throughput across every process in the queue.

Nobody’s wrong. That’s what makes it interesting.

Anyway.

In OS terms, there’s a name for a system that spends so much time swapping context in and out that it stops doing any actual work.

Thrashing.

Every process is running. Nothing is progressing.

I did consider asking my secretary to spawn a session to think about it.

Which is exactly the problem.

The board looks great, though.

Every card is in progress.