← Back to dsouza.eu
Infrastructure note

The agent layer doesn't care which model answers.

Hermes Agent, the framework running my automated GEO/AI-visibility operation, talks to Google Gemini, local Ollama models, and Anthropic, OpenAI, and dozens of other backends through one routing gateway, all behind the same OpenAI-compatible interface. Swapping the model underneath doesn't touch a single agent's logic.

01 — how one call reaches any backend

Hermes Agent task / skill layer one chat call Provider router config.yaml, no code path change on swap Ollama local · fully offline Google Gemini hosted, default OmniRoute gateway → Claude, GPT, 30+ more
Every arrow leaving the router carries the identical request shape. Adding a new model, or falling back to one when another is down, is a line in a config file, not a rewrite of the agent that's calling it.

02 — proof this isn't theoretical: 12 agents, already running

Citeworthy Ops, the GEO/AI-visibility delivery pipeline described on the main site, is a 12-agent chain of command running on this exact infrastructure, not a demo: the thing that does the client work.

01
Account Manager — intake, payment, credentials, go-ahead
02
Project Manager + Skill Release Manager — engagement safety gate; canary-tests agent changes before they touch a client
03
Orchestrator — sequences the 7 technical agents below per client
04–10
7 technical agents — shared task queue in, shared changelog out
Technical Health
Metadata & SEO
GEO Visibility
Analytics
Content
Reporting
Backlink Authority
11–12
Two dashboards — internal progress tracker, client-facing score report

03 — what changes going from 12 to 100

12
agents, one org chart, live today
50–100
agents, same router, same gates

Nothing about the chain of command changes shape: it's still an account gate, an orchestrator, and a bank of agents reading from a shared queue. What scales is the width of that bank, and the router is what makes the width cheap. Routine agents (metadata checks, changelog writes) run on a fast local Ollama model at zero marginal API cost, while reasoning-heavy agents (content strategy, client reporting) route to a frontier model through OmniRoute. Same pattern, more lanes.

Where it actually gets hard: not "can you wire up more models," it's routing discipline (matching task weight to model cost) and provider failover once you're running dozens of agents concurrently. That's the part worth designing carefully, and it's the same design already proven at 12.