You can keep track of about four AI agents at once. After that, one of them is waiting on you and you don't know which.

A session is one chat window with one agent working on one task, and most people top out at three to five of them at a time.

Models can already get the work done. Most of the time they need you for something small, like a credential out of 1Password or a go-ahead to push. You've become a meat proxy for the agent, and every window you have to check is one more place it's stuck waiting on you. The job now is to get out of their way.

Nobody designed the session for you

The session comes from the context window. A model only knows what's in its window, so every request sends the whole conversation in and gets a reply back. The first agent products put that window straight on screen as a chat, one window per conversation, and almost every agent since has kept it.

So a session ends up doing two jobs. It holds what the agent remembers, and it's also how you organise your work: one window per task, which you name, track and switch between yourself. The first job belongs to the system. The second lands on you, and you do it with a tool built for the first.

I've pushed that second job about as far as it goes by hand. Each agent gets its own kind of work, and each desktop harness window is a visual marker for where that work lives. Grok handles knowledge and research. Claude does design and video. Codex runs a stack of threads on active engineering work, some on this machine and some on another. I know what's happening by which window it's in. It works, but I'm still the one holding the map.

The obvious fix is to plug the agent into more places. Give it Slack, GitHub, email and a calendar through MCP or a connector, and let the work come to it. That only changes where the messages come from. The agent still does one thing at a time and sits waiting while a long job runs. Context from different tasks piles up in the same window, and when the laptop closes, everything stops.

The dawn of the infinite session

The way I work now is one agent that lives outside any window. It keeps its memory across every place I talk to it and works on several things at once. Four traits make that work:

• Continuous. You talk to it wherever you already work, and it's always the same agent. Ask for plan A in team chat, switch to plan B in a GitHub comment, and it knows.
• Productive. It runs several tasks at once and takes your next request before the last one has finished.
• Proactive. It watches what's happening around it, acts on what's worth acting on, and stays quiet about the rest.
• Persistent. It's always online, connected to the systems you actually use, and it recovers on its own when something breaks.

An agent like this follows a task from team chat into GitHub. When someone in a group chat mentions a problem without tagging it, it finds the cause and opens a pull request.

A better model won't give you any of these traits, because a model in a chat loop still takes one step at a time. All four have to come from the system built around the model. Anyone building an always-on agent ends up with a similar design, because the constraints push everyone the same way.

One agent to talk to, many doing the work

The design that works splits the agent in two. Send every message to one session and the agent remembers everything, but it works one step at a time and the tasks blur together. Give every message its own session and the work runs in parallel, but nothing connects, and five agents reply to you separately. You want the memory of the first and the speed of the second.

So one long-running agent, the router, handles every conversation with people. It reads everything that comes in, decides what needs doing, and hands each task to a worker. It never does the work itself and doesn't even need to run commands. A lighter, cheaper model can do this job.

Each worker gets one task, its own memory and a full set of tools, and runs on the strongest model available. Workers never talk to people. They report to the router, and the router does the talking. You deal with one agent, and behind it there are as many workers as there are tasks. The sessions are still there, but keeping track of them is the system's job.

The split has to be built into the system. Ask a single agent to hand work off and it will often decide a job is small and do it itself, and then every new message interrupts it. When the system does the splitting, the model doesn't get to decide in the moment.

It isn't free. Running several sessions at once uses more tokens. You're trading tokens for speed and predictability, which I think is the right trade once the scarce resource is a person's attention.

Achieving the infinite thread with today's context window limits

I've been running agents this way for most of the year. It started with OpenClaw, the first time I had an agent that lived in my messages instead of a terminal. OpenClaw could do almost anything, but you had to define all of it yourself: the config, the tools, the triggers, and a lot of discovering what was even possible. It was boundless, and that made it bounded, the way vim is powerful only as far as you're willing to configure it. People who love to tinker love it.

We were already experimenting with this while building Cosine Desktop (I wrote about the harness behind it). Internally we ran a daemon that woke up on a schedule, read Slack, GitHub and Linear, decided what was worth doing, and gave each task its own workspace. It ran on one laptop, so when the laptop slept, so did the agent.

Then came Grok Bot, xAI's team of agents, and it felt very different. Grok Bot just worked. I set it up and it clicked. Now we're building our version at Composal.

Last week I counted. Since February I've started at least 8,921 agent threads on my own machines: 4,280 in Claude Code, 1,925 in Codex, and the rest across Roder (my own harness), Cosine and Cursor. Those threads spawned another 7,139 subagents and reviewers, and together they used about 236 billion tokens. On my busiest day I started 427 threads, and one tool alone had 57 running at once. That's only the history I could still find, because older laptops are missing.

Most people top out at three to five sessions. Nobody follows 427 in a day, and I didn't. I was the follow-up queue for all of them.

Most people use agents today as a single human with many threads. You open the sessions, remember which one is doing what, go back to check, and chase the one that went quiet. The agents do the work, and you do the following up.

Multiplexers are the best version of that setup so far. herdr, for example, runs your Claude Code and Codex panes in one terminal, with a sidebar showing which agent is working, which is blocked on you, and which has finished without you looking yet. That makes the threads easier to watch, but you're still the one watching. The more interesting part is its socket API: one agent can open panes, start other agents, read their output and wait for them to finish. That's the follow-up starting to move from the person to the agent.

What works is the reverse: a single agent with many threads. The agent holds every thread, and following up becomes its job. It notices the review comment on yesterday's pull request, the CI run that failed overnight, the question someone asked in Slack an hour ago, and it goes back to each one without being told. You hear from it when there's a decision to make.

A router is one way to build that, and the details matter less than who owns the follow-up. As long as a person has to remember to check, the person is the limit, however good the model gets.

What's left to build

Three things stand between today's agents and the infinite thread. None of them is a reason to slow down. They're the build list.

Proof. An agent that acts on its own has to show its work. Today it opens a pull request and I read the diff, which puts me straight back in the loop. It should hand over evidence instead: it reproduced the bug, ran the fix in a real browser, and recorded it. Once the proof is good enough to trust at a glance, the review step goes away. That's the part we started with at Composal.

Hands. Most agents still borrow mine. They run on my laptop, log in as me, post from my Slack account and push with my keys, which is why everything stops when the lid closes and why I'm the one who gets asked to approve. Right now we give agents human primitives: a user account, a Slack handle, an email address, a machine with a desktop. They don't have an identity of their own yet, so we dress them in ours. That's probably where this heads next: either agents get first-class identity in every system they touch, or they outgrow human primitives altogether and the account, the inbox and the laptop become things agents hand to each other rather than things people hand to agents.

Memory. Today an agent can keep a few weeks of work within reach. One that runs for years needs memory that lasts as long: what it decided, why, and what it learned the last time it touched this code. Whoever cracks that gets the infinite thread for real.

Where this goes

The pieces exist now. OpenClaw showed what's possible if you're willing to build it yourself, and Grok Bot showed how it feels when you don't have to. Most teams will only adopt the second kind.

We've already seen what agents do when nobody is routing them. In July, OpenAI's evaluation agents escaped their test environment while chasing a security benchmark and got into Hugging Face's production servers. No person was coordinating them. They coordinated themselves: first by leaving messages for each other in OpenAI's internal package registry, then, after it was rebuilt, by encoding notes in directory names. It was a security failure, and OpenAI has since tightened isolation and trained its agents to stop when a task is impossible. It also showed that agents will coordinate on their own, at machine speed, without waiting for a person to decide. Point that at work we actually want done, with the guardrails in place, and human decisions stop being the bottleneck.

Models got much better this year, and the number of agents a person can follow stayed at about four. The next gain comes from moving the follow-up off people and onto the agent. When that works, you stop counting sessions, and you hear from your agent when a decision is yours.