Skip to content
AgentPod

What AgentPod is

AgentPod manages the environments AI agents live in, wherever they run.

An agent needs a place to work: a filesystem, a config file, somewhere its logs go, a process that can be started and stopped. Once you have more than one agent, on more than one machine, that place stops being something you can hold in your head. AgentPod is the console for those places.

It is attach-first. You point it at runtimes you already have and it detects them where they sit. Nothing moves, and nothing is rewritten to a new format.

What it gives you per runtime

Section titled “What it gives you per runtime”
  • Filesystem — browse, read and write the workspace
  • Logs — tail them live
  • Terminal — an interactive shell, through the hub
  • Config — edit the harness’s own configuration file
  • Health — whether it is up, and what it reports about itself
  • Lifecycle — start, stop and restart
  • Cleanup — plan a disk reclaim, inspect the plan, then apply it
  • Changesets — what the agent has actually changed in its working tree
  • Activity — an audit trail of what was done to the station, and by whom
  • Skills — what a station actually has, installed under review and verified in a session
  • Plugins — reviewed harness plugin changes, planned and applied
  • Provisioning — create new runtimes on Docker, Cloudflare, Modal or Fly

Not every station offers all of these. Each one is gated on a capability the harness declares, and a station that does not declare it is refused before the request ever reaches the machine.

And a way to talk to them

Section titled “And a way to talk to them”

The console is for operating the ground an agent stands on. The other half of AgentPod is for working with the agent: turn on the bridge and every adopted station gets a chat identity and a room of its own.

You message it from a client you already have. The agent’s reply comes back as that agent. It can be sent a voice note and answer with one; it asks for permission before running a tool and you reply with a number; when a turn fails you get the provider’s own sentence rather than silence. The harness itself never learns any of this is happening.

See Talking to an agent in a room.

Three tiers

Section titled “Three tiers”
   Operator (web console)
            │  HTTPS + WSS
            ▼
   ┌───────────────────────────┐    outbound WSS tunnels (NAT-friendly)
   │       AgentPod Hub        │◄────────┬────────────┬──────────────┐
   │  (Bun + Hono + Postgres)  │         │            │              │
   │  • node/station registry  │     node-agent   node-agent    node-agent
   │  • connection broker      │     (VPS)        (laptop)      (provisioned)
   │  • enrollment + auth      │
   │  • provisioning drivers   │
   │  • audit + activity log   │
   └───────────────────────────┘

node-agent is a single static Go binary, installed per host. It dials out to the hub and executes contract verbs locally. It opens no inbound ports, which is why a laptop behind CGNAT is reachable at all.

The hub is the registry, the connection broker, and the place authentication and audit live. It is a Bun + Hono service over Postgres, and you host it yourself.

The console is a static SvelteKit app: node list, then the station tree under each node, then the panels above.

What it is not

Section titled “What it is not”

It is not a harness, and it does not run your agents. Claude Code, Codex, Hermes and the rest do that. AgentPod manages the ground they stand on.

It is not an orchestrator. Deciding what work an agent should do next is a different job in a different plane — that is what SuperPipeline is for. AgentPod answers “where does this agent live, and is it healthy”, not “what should it work on”.

The two do join up: AgentPod can claim work from a board and run it on a station, and the decisions that work stops on come back to a room where you can answer them. That is a bridge between two planes rather than one plane growing into the other — see Working a board.

Next

Section titled “Next”