Architecture

Pantheon runs agent teams across a mix of Anthropic and local models, coordinated across networked machines. There is no shared harness, no central cloud, and no single point of control — each machine runs the component suited to its role.

Three-role topology

Every machine in a Pantheon fleet takes one of three roles. A machine may hold more than one role.

┌──────────────────────────────────────────────────────────┐
│  Client front  (Iris)                                    │
│  Your laptop / dev workstation                           │
│  • Intercepts outgoing Anthropic API calls               │
│  • Routes to fleet or falls back to Anthropic            │
│  • Holds per-teammate routing policy                     │
└──────────────────┬───────────────────────────────────────┘
                   │ hermes RPC
                   ▼
┌──────────────────────────────────────────────────────────┐
│  Orchestrator host  (minotaur)                           │
│  Most capable local host — GPU workstation, homelab node │
│  • Receives routed work from Iris                        │
│  • Schedules tasks across model backends                 │
│  • Owns work-host auth boundary                          │
│  • Runs hermes (fleet message bus)                       │
└──────┬───────────────────────────┬────────────────────────┘
       │ Ollama API                │ Ollama API
       ▼                           ▼
┌─────────────────┐   ┌─────────────────────────────────────┐
│  Model backend  │   │  Model backend  (remote)            │
│  (local)        │   │  Any Ollama-compatible host          │
│  Ollama :11434  │   │  reached over Tailscale / LAN       │
│  hydra :8080    │   │  hydra :8080                        │
└─────────────────┘   └─────────────────────────────────────┘

Client front — Iris

Iris runs on the machine where agents live: typically your laptop or primary dev workstation. It intercepts outbound calls to the Anthropic Messages API and applies your routing policy before a packet leaves the machine.

When a teammate issues a request, Iris checks the policy table:

• Local route — forward to the orchestrator host via hermes; minotaur picks a model backend.
• Anthropic route — pass through to api.anthropic.com with your API key.
• Fallback — if the fleet is unreachable, fall back to Anthropic automatically.

Iris requires no changes to agent code. It presents a local socket that speaks the Anthropic Messages API.

Orchestrator host — minotaur

minotaur runs on your most capable local host. It receives work routed by Iris, resolves which model backend can handle the request (based on model class and fleet topology from hermes), and dispatches.

minotaur also owns the auth boundary for work coming from off-LAN clients. Requests must carry a valid bearer token; minotaur validates before forwarding to any backend.

minotaur co-locates with hermes. The message bus and the orchestrator share a host so fleet topology is always locally available.

Model backends — hydra

Each model backend runs Ollama (:11434) and hydra (:8080). hydra is a protocol bridge: it accepts Anthropic Messages API requests and translates them to the Ollama /api/chat format, then maps responses back.

hydra is stateless and transparent. Clients (or minotaur) point at hydra’s port and interact with local models using the same API they use for Anthropic.

Fleet coordination — hermes

hermes is the fleet message bus. It runs on the orchestrator host and provides:

• Capability discovery — backends register their loaded models at startup; hermes maintains a live capability table.
• Topology propagation — Iris learns the current fleet state from hermes at install and via periodic refresh.
• Message routing — component-to-component RPC over a lightweight publish/subscribe protocol (default port :7677).

hermes does not carry inference traffic. It carries control messages only — routing decisions, health signals, capability updates.

One install flow, three configs

The install script detects (or asks) which role a machine will play, then installs and configures only the components that role needs:

Role	Installed	Configured
Client front	Iris	Local socket, policy table, hermes endpoint
Orchestrator host	minotaur, hermes	Auth, model-class policy, backend registry
Model backend	Ollama, hydra	Model pulls, hydra port, hermes registration

A machine can hold multiple roles (e.g., orchestrator + model backend on the same GPU workstation). The script handles this with a multi-select prompt.

Routing policy

Routing policy lives in Iris’s config (written at install, editable after). The minimal policy is a model-class map:

[routing]
default = "local"          # local | anthropic | auto

[routing.overrides]
"claude-opus-*"   = "anthropic"   # Opus always hits Anthropic
"claude-sonnet-*" = "auto"        # Sonnet: local if available, else Anthropic
"*"               = "local"       # Everything else: local fleet

auto means: try local first; if no backend has the model class loaded, fall back to Anthropic. Iris logs every routing decision for inspection.

Security boundary

• LAN-local: hermes and Ollama are LAN-local by default. They do not listen on public interfaces.
• Off-LAN: Tailscale (or equivalent) is the recommended transport for multi-site fleets. minotaur’s auth boundary applies to any request arriving from outside the trust zone.
• Anthropic keys: API keys live only on machines running Iris. Model backends never see them.