One Developer, Five Terminals, Zero Awareness

It's 11 p.m. and I have four terminals open.

One is running a Claude Code session on the auth refactor. Another is in a git worktree, rebuilding the tests. A third is reviewing a pull request. A fourth is just… there, waiting, because I know I'll need it in ten minutes. Somewhere in the mix there's a small team of sub-agents fanning out on a migration.

I'm not doing this because I enjoy the chaos. I'm doing it because this is what "productive" looks like now.

If you ship software with AI agents, you already know the feeling. One agent working one task, start to finish, is too slow. So you split the work. You open a second window. Then a third. You spin up a worktree so two branches can move at once. You hand a batch of independent tasks to a fleet of sub-agents and let them run. Parallelism is the only lever left when a single session can't keep up with the size of what you're trying to do.

And it works — right up until it doesn't.

The parallel blind spot

Here's the thing nobody tells you when you start running sessions in parallel: every one of those sessions is an island.

Session A is deep in the auth module. It's been there for twenty minutes, halfway through a refactor, files open, changes uncommitted. Three minutes later, Session B — a completely separate process, in a completely separate terminal — also reaches for the auth module. Not because it's reckless. Because it has no idea Session A exists.

Now you have two agents editing the same code with no knowledge of each other. One overwrites the other's assumptions. A merge conflict blooms out of nowhere. Or worse — no conflict, just two half-finished ideas quietly braided into the same file, and you don't notice until the tests go red for reasons that make no sense.

You lose exactly the time parallelism was supposed to save. That's the trap. The faster you go by splitting work, the more surface area you create for the splits to collide — because none of them can see the others.

I started calling this the parallel blind spot. You added more hands to move faster, and the hands can't see each other.

Memory solves "what happened." This is "what's happening."

If you've used ContextForge, you know it already gives your agents a memory that survives every session — the decisions, the corrections, the constraints, carried from one session to the next so your agent stops forgetting Friday by Monday.

But durable memory answers a question about the past: what happened before. The parallel blind spot is a different question entirely — a question about right now:

Who else is working on this, at this moment, while I am?

Memory is history. This is presence. A session's history tells you what it did yesterday; it tells you nothing about the session running in the terminal next to it this second. No amount of "remember what happened" fixes "I can't see what's happening."

That's the gap. And for a while, it was a gap I only half-noticed — because when it's just you and one terminal, it doesn't exist. It only shows up once you're deep enough into parallel work to get bitten by it.

The comment that named it

Then a reader left a comment on one of my posts that named it exactly.

They pointed out that ContextForge covered the single-session story beautifully — memory that persists — but that the multi-session case was wide open. When you run two or more agents against the same project, there's no live shared-state layer. Nothing that lets Session A raise a hand and say "I've got the auth module right now" so Session B doesn't walk into it.

Reading it, I felt that particular sting of good feedback: the obvious thing you somehow hadn't let yourself see. They were right. Memory across sessions was solved. Awareness between sessions wasn't. It had a name now, and once something has a name, you have to go build it.

So I did.

Session Presence: a live "who's here" for your agents

The new feature is called Session Presence, and the whole idea fits in one sentence: your parallel sessions can now see each other in real time.

Here's how it actually works, because the best part is how little you have to do:

• It registers itself. Every Claude Code session (or Cursor, or any MCP client) automatically announces itself as live the first time it does anything. You don't run a command. You don't think about it. The moment a session starts working, it's on the board.
• It stays honest. Each session sends a quiet heartbeat every couple of minutes. So the list is always live sessions — not a graveyard of things you closed hours ago. A session that dies without saying goodbye simply ages off on its own.
• It disappears cleanly. When you close a session, it's removed at once — even in the split second before the process is fully killed. No stale ghosts lingering on the list.

On top of that, three small tools give the agent a voice:

• session_update — "I'm working on the auth module." One session declares what it's focused on.
• session_list — "Who else is on this project right now, and what are they doing?"
• session_end — "I'm done here."

And you don't have to memorize any of that. You just talk. Ask your agent, in plain English, "is anyone else working on this project right now?" — and it checks the board and tells you: yes, another session has been on the auth module for the last few minutes; you might want to steer clear.

One more thing that matters: it's advisory, not a lock. Presence is a "busy" sign on a door, not a key that bolts it shut. It doesn't stop you from doing anything — it just makes sure you're never doing it blind. You stay in control; you just get to make the call with the full picture instead of half of it. And it's scoped to the project you're actually in, so a busy afternoon across five different repos doesn't turn into noise — you see the sessions that can actually collide with yours, and nothing else.

What it feels like in practice

Back to that 11 p.m. scene. Two sessions, both drifting toward the auth module.

With presence, the second one asks the board before it dives in. It sees that Session A is already there, focused on exactly that. So instead of colliding, it picks up the tests — the other thing on the list that nobody's touching. No conflict. No braided half-ideas. No 30 minutes lost untangling a mess that never needed to happen.

That's the whole win. It's not flashy. It's the quiet difference between five sessions working near each other and five sessions working blind next to each other.

Try it this week

If you're already running parallel sessions — worktrees, agent teams, three terminals before lunch — this is for you.

1. Update to the latest ContextForge MCP. Session Presence ships in the current release and works with Claude Code, Cursor, and Copilot through MCP — so even if you bounce between all three tools in a day, your sessions still see each other.
2. Ask "who else is here?" at the start of a session. Make it the first thing you do when you sit down, the same way you'd glance around an office before taking a desk.
3. Say what you're working on when you switch tasks. One sentence — "I'm on the payments flow now" — and every other session can see it.

It's on the free tier. Five minutes to set up. And if you've ever lost an evening to two of your own agents fighting over the same file, you already know exactly what it's worth.

Parallelism without awareness isn't speed. It's a collision waiting to happen.

Give your sessions a way to see each other.