# The agent fleet

The co-op runs **more than one agent**, each as its **own Unix user** on the agent
host (`ov-0f018e`, `179.237.103.165`) with its **own Hermes gateway unit** and its
**own LiteLLM team**. Any document that describes "the agent" as a single thing is
now wrong.

## The three agents today

| Agent | Unix user | systemd unit | Gateway team (budget) | Model | Presence |
|---|---|---|---|---|---|
| **Inferencebot** (steward) | `ubuntu` | `hermes-gateway.service` | *(co-op account team)* | per `~/.hermes/config.yaml` | Matrix `@inferencebot:inference.coop`; digests, newsletters, membership/key plumbing |
| **infrastructure-bot** | `infrabot` | `hermes-gateway-infrabot.service` | `agent:infrastructure-bot` ($5/30d) | `greenpt/glm-5.3-flash` | Matrix `#infrastructure` (answers only when mentioned); infrastructure scope |
| **socialbot** | `socialbot` | `hermes-gateway-socialbot.service` | `agent:socialbot` ($5/30d) | `greenpt/glm-5.3-flash` | Matrix `#social-drafts`; drafts the co-op's AT Protocol (Bluesky) account `inference.coop` |

All three gateways run on the one host; each is a separate process, a separate
`.env`, and a separate set of rooms. There is **one LiteLLM gateway** (the Cloudron
app) that all three draw on — the agent host runs no gateway of its own.

### Who is who (do not conflate them)

- **Inferencebot** is the **steward** and the fleet administrator: full Cloudron
  token, gateway master key, member-data plumbing. It is NOT a member-facing chat
  persona.
- **infrastructure-bot** is a **lower-privileged** infrastructure agent. Per its
  own SOUL it has **no sudo, no Cloudron admin token, and no member data**; when a
  task needs more privilege it hands up to the steward rather than working around
  it. Its gateway key has a small monthly budget and a flash-tier allowlist.
- **socialbot** has **no Cloudron, portal or member-data access** and no power over
  Matrix rooms; its only writable surface is the `#social-drafts` room, and it
  **never publishes an unapproved draft** — silence is its correct failure mode.

## Member bots — TIER 2 (planned, not yet provisioned)

The intended path for **member-facing** bots is a second tier: each member bot is a
**Hermes profile under the `infrabot` Unix user**, sharing **one** gateway process
(the infrabot one), with its own gateway team/key. This is tracked as **co-op/support#33**.

**Status (2026-11-04): not yet provisioned.** `/home/infrabot/.hermes/profiles/`
holds only a `.deleted` directory with two probe files — there are **no active
member-bot profiles**. Record this honestly: the design exists, the instances do
not.

## Why one Unix user per agent — and the limit of it

**Profile isolation is organizational, not security.** Run one OS user (or a
rootless container) per agent from day one: **on a shared Unix user, sibling
Hermes profiles can read each other's `.env`.** So tier-2 member bots sharing the
`infrabot` user are isolated from *members* but **not from each other** — that
sharing is accepted for member bots, not extended to the privileged agents.

## Backup coverage is automatic — but prove it

The nightly restic run (see `maintenance/backups.md`) enumerates `/home/*` **as
root** and stages every agent home, so a new agent is covered without editing any
list. Coverage is still **unproven until that agent's files show up in a
snapshot**.

## Gateway teams (member vs agent)

From `GET https://gateway.inference.coop/team/list` (2026-11-04): 97 teams — one
`member:<email>` team per member (mostly $15/30d), `member:info@inference.coop`
($135/30d, the co-op account), the two `agent:*` teams above, and
`sandbox:librechat-test` ($3). Agent teams carry a **small budget and a flash-tier
model allowlist** enforced at the gateway.