What Are Persistent Agent Teams? How to Create Them with Herdr, Claude Code and Pi

Most AI coding agents are really just threads: you open a session, finish a task, and abandon it. Persistent agent teams flip that model. Instead of a fresh chat per chore, you work with a small cast of named, long-running agents that know your project, remember earlier discussions, and message each other without you acting as a copy-paste router. I first noticed this working style in Grok Bot, then rebuilt it on an always-on Linux VM using Herdr, Claude Code, and Pi on top of a GitHub Copilot subscription. Here’s what persistent agent teams are, how to set one up, and where they go wrong.

What Are Persistent Agent Teams?

A persistent agent team is a group of named AI agents with their own identity and memory that stay running over days or weeks and collaborate through asynchronous messaging. Think of a small human team: a lead, a researcher, a developer, a QA engineer. Each has a role, each remembers what happened yesterday.

These persistent agents are different from single-task AI sessions. In a typical Claude Code workflow, an “agent” is one of two things: a session created per task (ephemeral, leaving a dozen tabs you’ll never reopen), or a static definition file with a system prompt, allowed tools, and a model assignment, used to bootstrap yet another fresh thread. Most agents today are threads, not lasting entities. Persistent agents are the opposite: the same named peer picks up where it left off.

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.

Read more: Introducing Agentic Development Lifecycle (ADLC): Building and Operating AI Agents in Production 

Where the Idea Came From: The Grok Bot Experience

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.

The Benefits of Persistent Agent Teams: Are They Better Than Single-Task Sessions?

These persistent agent teams feel 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!

Other benefits of persistent agent teams include: 

• 1. Agents with identity and memory: Each agent is a named peer that remembers earlier discussions and learns its way around your codebase, instead of a throwaway thread you start from zero every time.
• 2. Agent-to-agent handoffs without you in the middle: Agents message each other directly (researcher to lead to dev to QA), so you stop acting as the copy-paste router between tabs.
• 3. Long-running, unattended work: Because the team lives on an always-on VM, agents can run async jobs, watch long test suites or external events, and ping each other when something finishes or breaks, even with your laptop closed.
• 4. A more human, agile way to work: You remember who is who, can jump into any conversation, push back mid-task, and change direction without losing context. It feels like a small team rather than a pile of abandoned tabs.
• 5. Access from anywhere: Chats and sessions persist remotely, so you can check progress, give instructions, and verify results from another device without touching your main machine.

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.

Why Persistent Agent Teams Are Possible Now?

• 1. Compaction trained into the models. Models can now distill what matters from very long threads, so a single session can keep going indefinitely instead of hitting a context wall.
• 2. Per-agent memory and identity. Context belongs to a specific agent rather than one flat repo-wide CLAUDE.md, which lets each peer build up its own role-specific understanding.
• 3. Built-in async agent-to-agent messaging. Tools like Claude Code’s SendMessage and Pi’s pi-intercom let named sessions hand off work and answer questions without a human relaying messages.
• 4. Always-on remote Linux VMs. Agents live on a persistent remote sandbox rather than dying when you close your laptop, which is what makes “persistent” actually true.
• 5. Terminal multiplexers built for agents. Tools like Herdr give each agent its own tab, group teams into workspaces, show live status dots, and restore saved conversations after a server restart.
• 6. Flexible, affordable model access. Subscriptions like GitHub Copilot put many models under one roof, so you can mix stronger reasoning models with cheaper, faster workers across a team.
•  

How to Create a Persistent Agent Team: A Step by Step Guide 

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.

What You Need To Build Your Own Machine: The Three Building Blocks

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.

How to Create a Persistent Agent Team: Step by Step

Step 1: Install Herdr and Connect to Your VM

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.

Step 2: Set Up a Claude Code Agent 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`.

Step 3: Let Your Claude Code Agents Message Each Other

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.

Step 4: Switch to Pi for GitHub Copilot (Optional)

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:

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

pi install npm:pi-intercom

Step 5: Build a Six-Agent Pi Team

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:

Step 6: Connect Your Pi Agents with pi-intercom

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.

Common Problems with Persistent Agent Teams (and How to Fix Them)

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.

Challenge 1: Overengineering and Wish-Granting

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.

Challenge 2: 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.

Challenge 3: Overdecomposition and 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.

Challenge 4: Lossy Compaction

Never-ending threads survive through compaction, which occasionally drops the exact constraint you cared about. Important decisions and scope breaks need to live in repo files (AGENTS.md, CONTEXT.md) rather than in chat history alone.

Challenge 5: Tokenomics and rising costs

Six persistent agents waking each other up over the 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.

The Solution: Add Scope Brakes to Your TEAM File

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.

Bonus

Bonus 1: Download Bootstrap Scripts and TEAM File Templates

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).

Bonus 2: Launch Your Team with One Command

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 3: Control Your Agent Team Remotely with Collie

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

What's Next: Enable Persistent Agent Teams For First-Mover Advantage

Today, a persistent agent team is a handful of named sessions on a Linux VM. Tomorrow, it may be the default way software gets built, unifying enterprises with real codebases, compliance requirements, and budgets. EPAM can help you make that step:

• Strategy and use-case discovery: Identify where persistent teams add the most value in your delivery lifecycle, such as engineering, QA, migrations, and long-running monitoring, and where a simpler single-agent workflow is enough.
• Secure, always-on infrastructure: Design the remote sandboxes, access controls, secrets management, and network boundaries so agents can work around the clock without putting your code or data at risk.
• Team design and orchestration: Define the right roles, model assignments, handoff rules, and TEAM_*.md-style operating guidelines for your environment, using Claude Code, Pi, GitHub Copilot, or the tooling you already have.
• Guardrails against failure modes: Put scope brakes, human-in-the-loop checkpoints, and evaluation in place to prevent overengineering, runaway cost, and progress-as-completion theater.
• Cost governance and observability: Track token usage, agent activity, and outcomes per team, so you can see what the team is delivering and tune it.
• Enablement and change management: Train your engineers to work with persistent peers, and adapt your processes, reviews, and metrics to a human-plus-agents way of working.