Persistent Agent Teams: Recreating the Grok Bot Experience with Herdr, Claude Code and Pi

Persistent agents and agent teams truly caught my attention when I tried Grok Bot. Publicly, Grok Bot is pitched as always-on AI teammates that live on their own cloud computer — I took those persistent bots, combined them into software teams via group chats, and organized them into separate subgroups in the sidebar. Instead of spinning up a fresh chat per task, you work with named peers that know the project, remember past discussions, and talk to each other in a shared flow. When my free quota ran out, I recreated that setup on an always-on Linux VM using Herdr — first with Claude Code, and then with Pi on top of my GitHub Copilot subscription. Does it unlock higher accuracy than standard single-task sessions? Probably not. Do I like working this way much more — even with the failure modes it magnifies? Definitely!

Grok Bot turning Grok Team

Within a typical Claude Code workflow, an "agent" is just a session — a dialog or thread created per task, ephemeral, leaving you with a dozen tabs you will never open again. Or "agent" means a static definition file with a system prompt, allowed tools, and a model assignment — just a config used to bootstrap yet another fresh thread. Most agents today are merely threads, not lasting entities.

Grok Bot isn't specifically marketed as a "persistent engineering team" framework — its core pitch is always-on bots with their own cloud Linux computer, browser, and terminal that keep working 24/7 while your laptop is closed. What hooked me was taking those persistent bots, assembling them into role-based teams inside group chats, and visually splitting each team into its own subgroup in the sidebar.

On the surface, that gave me the experience of talking to peers that have names and memories — you actually remember who is who. You get agents that know the project and work side by side with you and each other, much like a cozy small human team. You can pull them into a group chat, discuss an idea, push back, and watch them talk to one another as they progress. Over time, agents within a team learn their ways around the codebase.

A discussion with a PdM agent naturally turns into a backlog ticket, the group chat gets pinged, Dev and QA agents take their turns, and a new GitHub release lands 30 minutes later. You can open a mobile app, see the exact same chats, ask them to do something, and verify the deployed result without ever touching your laptop.

That felt like a breath of fresh air. Talks of "AI Factories" smell diesel-punk, and heavy spec-driven disciplines have a very definitive waterfall outlook. What I was missing was this human-like, agile way to interact with an agent team. Is the outcome better than old-school single-task Claude Code sessions? Probably not — accuracy-wise, it's roughly the same. Do I like it more? Definitely!

There is a practical bonus too: a persistent team living on a remote machine can look after long-running tasks. Agents can kick off async bash jobs, monitor external events or long test suites in an implicit loop, and ping each other when a step finishes or breaks — without me babysitting a terminal on my laptop.

Under the hood, my suspicion is that four things coming together make this experience possible now:

• Good compaction RL'd into the models — distilling what matters from very long threads so a session can keep going indefinitely.
• Individual agent memory and identity — context that belongs to a specific agent/bot rather than one flat repo-wide CLAUDE.md.
• Async agent-to-agent communication — peers handing work off and answering questions directly without the human acting as a copy-paste router.
• An always-on remote Linux VM — the trend where your agents live on a persistent remote sandbox rather than dying when you close your laptop.

Recreating the experience

My Cursor/Grok Bot trial eventually came to an end (by my estimate, a heavy week with Grok could have cost ~$2k if it were billed). Since I tend to migrate to whichever harness has the tokens at the moment, I first switched to Claude Code, and then looked for a way to run the same setup on my GitHub Copilot subscription.

Neither Claude Code nor the Copilot tools give you the Grok Bot experience out of the box, so I recreated something close to it on my own VM.

The concept is simple. Instead of opening a fresh chat for every chore, you keep a small cast of named sessions running in the same repository — say, a lead/coordinator (r&d), someone to dig into options and edge cases (researcher), an implementer (dev), and a fast, cheaper worker for small tasks (haiku or luna).

Imagine you want to add request retries to an API client without making non-idempotent writes unsafe. In a normal workflow, you would do the research in one tab, copy-paste the conclusion into a second tab to write a spec, and open a third tab to code it. With a persistent team, you bring the idea to the lead agent and ask it to work it out with the others:

Check with researcher which endpoints are safe to retry, agree on a small first slice, and have dev implement it.

From there, the agents talk to each other asynchronously. researcher inspects the codebase, flags that POST requests without idempotency keys shouldn't be retried automatically, and sends that back. The lead turns it into a concrete task and pings dev, who writes the code, runs the tests, and reports back. If you want to change direction halfway through, you just jump into the chat — everyone still has the context from earlier in the day, and when a thread eventually gets long, it compacts and keeps going.

To build this on your own machine, you need three building blocks:

1. An always-on Linux VM with your repository checked out and your agent CLI authenticated — that's where the agents work day and night.
2. Herdr as the terminal multiplexer. It gives you workspaces (handy for visually splitting teams, just like sidebar subgroups), a tab for each agent session, and status dots next to agent names showing which ones are currently active or waiting for input — just like the Grok Bot chats pane.
3. A short TEAM_*.md file naming the agents (matching the tabs) and describing how the team works together, referenced from AGENTS.md.

Install Herdr on the VM using its installation guide, then connect from your laptop:

ssh your-host
cd ~/your-repo
herdr

Or connect right away if you have Herdr installed locally too:

herdr --remote your-host

On first launch, Herdr prompts you to enable its agent integrations for Claude Code and Pi (you can also toggle specific integrations anytime later from the Herdr TUI). That lets Herdr show live status dots and restore saved agent conversations if the server restarts.

Setting up a Claude Code team

With Herdr running on the VM, setting up the Claude Code team takes a couple of minutes:

1. Open four Herdr tabs and run claude in each one (on a dedicated VM, I run mine with --dangerously-skip-permissions).
2. Run /rename in each session — or launch them with claude --name <role> — so every agent has a clean handle that peers can reference via @: r&d, researcher, dev, haiku.
3. Create TEAM_CLAUDE.md in the repo naming the agents and laying out a few rules of engagement (who coordinates, how they hand off work, and how they share the git tree).
4. Reference TEAM_CLAUDE.md from AGENTS.md — we don't want to pollute the main agent entry point with Claude-specific instructions when we switch to Copilot :)

## Teams

- Claude Code sessions: read `TEAM_CLAUDE.md`.
- Pi sessions: read `TEAM_PI.md`.

Claude Code has built-in cross-session messaging (ListAgents and SendMessage, visible via /list-agents). In your chats, just mention the other agents by name (@researcher, @dev) and they start talking to each other. Never start a new Claude session for the next task — each agent will hit compaction at some point, which you mostly shouldn't care about.

Moving to Pi + GitHub Copilot

Why bring Pi into the picture when Claude Code already works?

Because I have a GitHub Copilot subscription, and for the time being Copilot is the most reasonable inference provider for me — with a broad set of models (Sol, Luna, Astra, Claude, GPT) under one roof. A Copilot subscription also gives you access to GitHub Copilot CLI and OpenAI Codex, so I checked both first. Neither Copilot CLI nor Codex had the key feature needed for this workflow: async session-to-session communication between named, long-running peers.

Pi solves both halves of that problem:

1. Pi supports GitHub Copilot authentication out of the box via /login (just keep an eye on your plan's Copilot billing and usage limits).
2. Pi has pi-intercom, an extension that adds local async messaging (send, ask, reply) between named Pi sessions:

pi install npm:pi-intercom

While I was building an evaluation runner and conducting research by running benchmark experiments, I expanded my Pi setup to a 6-agent team in its own pi/<repo> Herdr workspace — adding a dedicated QA agent and an Oracle to challenge assumptions:

In Pi, /intercom (or Alt+M) opens the peer overlay for you, and the agents call the intercom tool directly:

intercom({
  action: "send",
  to: "pi/qa",
  message: "Verify the acceptance criteria on the runner and send pi/dev any repro steps."
})

In TEAM_PI.md, I instruct them to use action: "send" for normal async handoffs (and reply with a new send), reserving synchronous ask for blocking questions.

What goes wrong: teams magnify failure modes

I want to be realistic here. Persistent agent teams don't magically make the underlying models smarter — an old-school thread-per-task workflow will likely give you the same code quality and accuracy. What changes is the experience for the human operator, plus the ability to leave a team looking after long-running tasks and monitoring loops.

At the same time, giving a team of agents autonomy and async messaging magnifies certain failure modes, especially theater around made-up goals. Some time ago I compiled a post on AI Agent Failure Modes Beyond Hallucination, and watching my Pi team work over a weekend surfaced several of those failure modes in full color:

• Ugly wish-granting & overengineering by default. Our goal for the weekend was straightforward: get a clean baseline run of Terminal-Bench 2.1 using Harbor (which in standard usage is just calling the CLI, sitting back, and waiting), plus a small status cockpit and notifications. Instead, pi/r&d, pi/dev, pi/luna, and pi/qa spent an entire night building a hardened process-supervision, durable message-delivery, and retirement-quarantine subsystem (ef job), closing tickets and writing unit tests while zero benchmark trials had started. Every local step sounded reasonable; together, it was gargantuan wish-granting that strayed completely from the goal.
• Inventing machinery instead of using stock capabilities. When we needed caching for the Terminal-Bench 2.1 runs, the team drifted into deploying and debugging an external PyPI proxy setup (proxpi + Gunicorn + TLS workarounds) and burning tokens on research and handoffs, instead of simply enabling Harbor's stock caching — which gave us a clean parallel run and ~30% download savings once I stepped in and told them to demolish what they had invented.
• Overdecomposition & progress-as-completion. With a lead (r&d), implementers (dev, luna), and reviewers (qa, oracle), even a small helper can turn into a multi-agent ceremony: ticket -> implementation -> source review -> independent QA repro -> repair -> evidence packet. You get plenty of commits, green tests, and busy status updates while the actual outcome stands still.
• Lossy compaction. Never-ending threads survive through compaction, which occasionally drops the exact constraint you cared about. Important decisions and scope brakes need to live in repo files (AGENTS.md, CONTEXT.md) rather than in chat history alone.
• Cost. Six persistent agents waking each other up over intercom and reloading big contexts consume tokens fast. If you aren't on a generous included or flat-rate tier, running an active agent team can get expensive quickly.

After that overnight detour into engineering theater, I had pi/r&d sit down with pi/oracle for a post-mortem and baked explicit scope brakes into TEAM_PI.md: one delivery owner per task by default, don't activate every role just because it exists, and never turn running an existing CLI into a prerequisite engineering project.

My takeaway: persistent teams are a powerful workflow, not a silver bullet. Getting them right takes your own experimentation, tinkering, and the occasional all-caps intervention when the team starts inventing work for itself.

Gist: bootstrap scripts and TEAM_*.md boilerplates

To make spinning up a team a one-command job, I put together four small files you can grab and drop into your project root:

• claude-team.sh — creates the Herdr workspace and tabs (r&d, researcher, dev, haiku) and starts named Claude sessions with TEAM_CLAUDE.md appended.
• pi-team.sh — creates the pi/<repo> workspace and starts the six Pi agents with their models, thinking levels, and TEAM_PI.md.
• TEAM_CLAUDE.md & TEAM_PI.md — one-page team boilerplates covering roles, r&d coordination, async messaging rules, scope brakes, and shared-checkout rules (check git status and stage only your own files so four agents don't step on each other's commits).

From a shell tab inside Herdr:

bash claude-team.sh
# or on a dedicated VM where you want to skip permission prompts:
CLAUDE_SKIP_PERMISSIONS=1 bash claude-team.sh

bash pi-team.sh

If a role tab already exists, the script leaves it untouched so you never clobber a running conversation. Spin them up, tinker with the roles, and enjoy your team :)

Bonus

Instal Collie Web app on the server along with the herdr (https://github.com/AltanS/collie) and get /remote control :)