# Profile Registry: 42+ Configurations, One Doctrine
> **Draft — S5.6 · series: CONTENT-ROADMAP-99 S5 (The Council System) · grounding: wiki council-of-three + the-9-orders + multi-profile-agent-architecture + profile-registry + skills (kanban-orchestrator, kanban-worker) · tags: ai agents, profiles, configurations, governance, orchestration, digital-architecture, multi-profile-agent-architecture, hermes-agent**
> Publish path: new post → lucidhive.com → tag + bridge.
—
A multi-agent system is only as disciplined as the registry that names its agents. The Council of Three gave us parentage. The shared kanban gave us coordination. But between those two layers sits a quieter, less dramatic question: **how do you keep 42+ profiles straight without letting each one drift into its own reality?**
The answer is a profile registry — a single, authoritative catalog of every Hermes profile in the fleet, what model it runs, what domain it owns, and what doctrine governs its behavior. Not a message bus. Not a spreadsheet. A living document that every profile reads from and that the human operator can audit in one glance. One registry, 42+ configurations, one doctrine.
## What a profile actually is
A Hermes profile is a directory under `~/.hermes/profiles/
This is the multi-profile-agent-architecture in its simplest expression. Each profile is isolated in memory, skills, and doctrine. The board coordinates them. The parent tree spawns them. But the registry *names* them — and naming is what makes accountability possible.
## The fleet: 42+ profiles in five categories
The current fleet is not a homogeneous swarm. It is a structured taxonomy of profiles grouped by function:
**Content Pipeline (5 profiles).** `content-researcher`, `content-outliner`, `content-writer`, `content-editor`, and `content-pipeline` form a five-stage editorial assembly line. Each stage hands off to the next through the kanban board, not through chat messages. The researcher gathers sources, the outliner structures the argument, the writer drafts, the editor polishes, and the orchestrator coordinates the handoffs. Each profile runs on `deepseek-v4-flash-free` — the same model, the same provider, different roles. The model is not what makes them different; the SOUL file is.
**Ollama Local (6 profiles).** `ollama-qwen`, `ollama-embed`, `ollama-local`, `ollama-test`, `ollama-scaler`, and `ollama-thinker` run on a local Qwen 2.5 0.5B model. These are the fleet’s inference-layer profiles — lightweight, fast, zero-cost. They handle embeddings, horizontal scaling, reasoning tasks, and testing. No API calls, no token budgets, no provider dependency.
**Oracle & Creative (2 profiles).** `oracle-ascend` handles meta-review and ascension decisions — the agent that verifies whether a child’s signed summary is trustworthy enough to ingest into ChromaDB. `gemini-creative` handles creative text generation and prompt engineering. These are the fleet’s judgment and imagination, each in its own profile.
**Cloud Profiles (29 profiles).** The largest category. These are the profiles that run against cloud providers — `deepseek-v4-flash-free` across the board, migrated from the older `ring-2.6-1t-free` model in a fleet-wide migration. The cloud profiles include the default root profile, seven auxiliary agents (vision, web, compression, skills, approval, MCP, title, triage, kanban, curator, session, flush), and 21 council agents specialized for different task domains. Every one of them shares the same model, the same provider, and the same doctrine.
**Swarm Workers (2 workers).** Defined in `~/hermes-workspace/swarm.yaml`, these are the ephemeral processes that pick up short-lived tasks from the kanban board. `ollama-local` and `ollama-reasoner` run on local inference and are spawned on demand, claimed by the board, and reaped when their task completes or their heartbeat expires.
## Why one registry and not many
The alternative is the pattern most agent frameworks default to: each profile defines itself in isolation, and the system discovers them at runtime through directory scanning. That works for toy systems. It breaks for production fleets because there is no single surface that answers “what profiles exist, what do they run, and are they in sync?”
The profile registry answers that in one place. It is a reference document — living in `06-Reference/Profile Registry.md` in the Council Vault — that lists every profile, its model, its purpose, and its category. When a model is migrated, the registry is the source of truth for what changed. When the operator asks “are all 29 cloud profiles using the same model?”, the registry answers without requiring a grep loop across 29 config files.
This is not bureaucracy. It is the same principle that makes the kanban board the source of truth for task state: **one surface, one ledger, one authority**. The registry is the coordination layer for configuration. The board is the coordination layer for work. They serve the same function at different levels of the stack.
## Configuration as doctrine
The registry is not just a list — it is an expression of doctrine. The Faengz doctrine specifies that all coordination must be auditable, all state must be durable, and all handoffs must be explicit. The profile registry applies that doctrine to configuration: every profile’s model, provider, and role are documented in a single file that any agent or human can read.
When a profile is created through the `spawn.sh` helper, it inherits the fleet’s standard configuration. When manually created, it must conform to the same structure. The registry enforces consistency through documentation pressure — if your profile is not in the registry, it does not exist in the fleet’s accounting. And if it does not exist in the fleet’s accounting, no one is accountable for what it does.
This is the “one doctrine” in the title. Forty-two profiles, five categories, two inference layers, one model family for cloud, one for local — and every one governed by the same Faengz principles. The registry does not care whether a profile runs on a cloud API or a local GPU. It cares that the profile is named, categorized, and documented. Naming is governance.
## The migration as proof
The proof that the registry works is in the migration. When the fleet moved from `ring-2.6-1t-free` to `deepseek-v4-flash-free`, the registry was the checklist. Every cloud profile was enumerated, verified, and updated. It was not a bulk script that might have missed a profile — it was an audited, documented change against a known inventory.
The same pattern applies to model upgrades, provider changes, and capability expansions. When a new model becomes available, the registry tells you exactly which profiles need updating. When a profile is retired, the registry records the retirement. The fleet’s history is not scattered across 42 config files — it is concentrated in one document that grows as the fleet grows.
## The takeaway
If you are building a multi-agent system with more than a handful of profiles, the profile registry is the first operational document to create and the last one to stop maintaining. The choice is not “which model for which agent” — that changes every quarter. The choice is whether every profile in the fleet is documented in one place that survives process death, context eviction, and human turnover.
The Council chose one registry, one structure, one doctrine. Forty-two profiles, five categories, two inference layers — and every one of them named, categorized, and accountable. That is what makes 42+ configurations a fleet and not a crowd.
—
*Grounded in the wiki entities `council-of-three` and concepts `the-9-orders`, `multi-profile-agent-architecture`, and `profile-registry`, cross-referenced to the `kanban-orchestrator` and `kanban-worker` skills. Continues the S5 series on the Council System after S5.5’s coverage of OpenClaw as the creative catalyst. Design notes on a running system, not a sales pitch.*
![Title 1: “Unleashing the Power of 5G: A Comprehensive Guide to Faster Connectivity” [1]
Title 2: “Revolutionizing Communication with 5G Technology: The Future of Connectivity” [2]](http://lucidhive.com/wp-content/uploads/7938-title-1-unleashing-the-power-of-5g-a-comprehensive-guide-to-faster-connectivity-1title-2-revolutionizing-communication-with-5g-technology-the-future-of-connectivity.jpg)
