Agents Over Bubbles: Why a Session Manager Is at the Top of GitHub Today

The developer in Waltham wasn’t trying to build a new product. He was trying to stop building.

He’d spun up a Claude Code agent to refactor a legacy pricing module. Then a second to audit security debt. A third to generate docs. By Thursday, he had five agents, each running on a different branch, each making commits, each occasionally stalling out mid-task.

“I didn’t realize how fragile the illusion of control was,” he told me over espresso at a Cambridge café. “One agent thought it was done. Another had asked a question I didn’t see. A third had overwritten the second agent’s changes. I spent Friday morning untangling git logs like a forensic analyst.”

He’s not alone.

This week, agent-of-empires, a session manager for AI coding agents, hit the top of GitHub’s Rust trending list. Not because it writes better code. Not because it’s flashy. But because it solves the quiet crisis no one talks about: what happens after you deploy your first agent, and then your second, and then your third.

It doesn’t generate. It coordinates.

The Deployment

Agent of Empires (AoE) is a session manager for AI coding agents. It runs on Linux and macOS, using tmux under the hood to keep agent processes alive across terminal closures, SSH disconnects, or laptop sleep cycles.

You can launch it in three ways: via a terminal-based TUI (text user interface), a CLI, or a beta web dashboard. From there, you spin up agents, Claude Code, OpenCode, Mistral Vibe, Codex CLI, Gemini CLI, Copilot CLI, Factory Droid, and others, each in its own isolated session.

Each session gets its own git worktree, so agents working on different branches don’t clobber each other. Optional Docker sandboxing adds isolation. The TUI shows real-time status: running, waiting for input, idle, or errored. You can review diffs, edit files, and detach or reattach sessions at will.

Press R in the TUI, and it exposes the web dashboard over HTTPS with QR and passphrase auth, letting you check agent status from your phone. It uses Tailscale Funnel when available, Cloudflare Tunnel as a fallback.

Sessions persist. Close the app? The agents keep running. Reopen it? Everything’s where you left it.

No new code generation. No frontier models. Just infrastructure for the chaos we’ve already unleashed.

[[IMG: a developer in a home office reviewing multiple AI agent sessions on a terminal, one window showing git diffs, another a status dashboard, late-night lighting]]

Why It Matters

We’ve spent the last two years optimizing prompt quality, model latency, and output accuracy. But the real bottleneck isn’t the AI. It’s the operator.

You can have the smartest agent in the world. If it crashes when your SSH session drops, or overwrites another agent’s work, or stalls out waiting for approval you never see, it’s not smart. It’s a liability.

AoE doesn’t fix the agent. It fixes the environment.

And that’s the shift: we’re no longer deploying AI tools. We’re running AI fleets. And fleets need command centers.

The vendor pattern this echoes? Docker in 2014. Not because of containers, though AoE uses them, but because of the mental model shift. Before Docker, you managed servers. After Docker, you managed orchestration. The server became a disposable unit. The process became the thing you designed for.

Same here. The agent is no longer a script. It’s a long-running process. It needs persistence. It needs status visibility. It needs recovery paths.

And the web dashboard? That’s not a convenience. It’s a declaration: this is now production-grade infrastructure. You don’t build a PWA-able, remotely accessible dashboard for a toy.

The fact that it’s written in Rust, fast, safe, systems-level, isn’t incidental. It’s a signal: this tool expects to be trusted with your core workflow.

And the fact that it’s trending now? No surprise. The wave of AI agent adoption that started in mid-2025 is hitting its second phase: scaling and stabilizing. The honeymoon is over. The merge conflicts have begun.

What Other Businesses Can Learn

You don’t need five agents to need AoE. You need two.

Because the moment you go from one agent to two, you introduce coordination risk. One agent modifies a function. The other relies on the old signature. One agent commits. The other rebases. The build breaks.

This isn’t theoretical.

A mid-market SaaS firm in Bristol tried running parallel agents for feature development and tech debt cleanup. Within a week, their staging branch was unmergable. “We thought we were gaining velocity,” their CTO said. “Turns out we were just generating technical debt faster.”

AoE wouldn’t have prevented the conflict. But it would have surfaced it immediately. The status column would have shown one agent waiting, another idle, another in error. The diff view would have let them review changes before they merged.

Here’s what you need to consider:

“If your agents don’t outlive your SSH session, you haven’t shipped anything.”

That’s the core insight. If your agent process dies when you close your laptop, you’re not running agents. You’re running scripts. And scripts don’t scale.

So start here:

1. Enforce session persistence. Use tmux, screen, or a tool like AoE. No agent should be tied to a terminal session. If it is, it’s not infrastructure, it’s a demo.

2. Isolate agent work. Git worktrees or separate branches are non-negotiable. Agents can’t share a working tree. They’ll trample each other. AoE automates this. If you’re not using it, build the guardrails yourself.

3. Monitor status, not just output. An agent that’s “waiting for input” but not flagged as such is a silent failure. You need real-time visibility into state: running, waiting, idle, error. AoE’s TUI gives that. If you’re hand-rolling, build it into your runbooks.

4. Enable remote access. The ability to check agent status from your phone isn’t a luxury. It’s a firewatch. AoE’s QR + HTTPS flow is slick. If you’re using something else, make sure it’s secure and reliable.

5. Audit before you scale. Don’t wait until you have five agents to ask how they’re coordinated. Start with one. Add the tooling. Then scale.

And if you’re evaluating AoE, know this: it’s beta on the web side. The TUI is solid. The CLI is functional. The web dashboard works, but treat it as a convenience, not a primary interface, until stabilization lands.

[[IMG: a software engineering lead in a co-working space using a mobile device to monitor AI agent status via a web dashboard, natural light from a large window]]

Looking Ahead

The developer in Waltham ended up adopting AoE. He’s down to three agents, not because he scaled back, but because he consolidated. “I realized I didn’t need five,” he said. “I needed one, well-managed. The rest were noise.”

He showed me his new workflow: one agent per feature branch, each in its own worktree, all managed from the TUI. He checks status from his phone during standups. He reviews diffs before merging. No more midnight git archaeology.

“I used to worry about the AI getting it wrong,” he said. “Now I worry about me getting it wrong, about not seeing that one agent was stuck, or not checking the diff before it committed. AoE doesn’t fix the AI. It fixes me.”

That’s the quiet truth of this phase: we’re not building smarter agents. We’re building smarter ways to survive them.

And if a session manager is the most important tool on GitHub today, it’s not because the technology is flashy.

It’s because the cost of chaos has finally exceeded the cost of control.

• GitHub: njbrake/agent-of-empires, accessed 2026-04-29