In July 2026 we imported the Agentic Society OS role catalog into HiveMind, the command center that runs our agency. Ten roles and 185 skills, reviewed one by one against a live estate of 220 dashboard modules, 49 working skills, and 13 scheduled loops. This is the full record: what we did, what worked, what fought us, and what we would change if we were shipping the catalog ourselves. Written operator to operator, because the roles are your core offer and you asked what contact with a real operation looks like.
SwarmSystem is a done-for-you visibility agency for local home service businesses: we make sure that when a homeowner asks Google, ChatGPT, or Siri for a plumber or an HVAC company, our client's name comes up. The operation is one human operator plus an agent fleet, coordinated through a dashboard we call HiveMind: 220 frontend modules, 49 installed skills, 13 self-monitoring scheduled loops, a self-healing sentry, and an AI inbox watcher, all built over the past year.
The problem your catalog solved for us: all of that capability had no organizational layer. Skills belonged to nobody. Receipts landed in lanes, not on desks. Our stated goal for the next stage of autonomy was, in the operator's words, roles we can personify, so that we can call upon a role that calls upon its skills appropriately. Your ten-role taxonomy became the baseline for that org chart, and your skill catalog became the candidate pool for what each desk should know how to do.
Seven steps, two working days, every step leaving a written receipt. The whole run is reproducible from the registry files it produced.
185 skill entries and the ten role definitions from your OS went into a single registry file, every entry carrying source attribution back to its catalog slug. Nothing was installed. Import and adoption are different events.
Before judging a single import, we mapped the existing estate onto the ten desks: 102 native assets (skills, modules, scheduled loops, agents), each desk given a scope, an owned-asset list, an escalation lane, and a trust ledger. The imports would be measured against this, not against a blank page.
63 candidate skills got a deep review against what already runs here. 13 review agents made 247 reads of our repository, and every finding was adversarially verified by a second agent before it counted. Each review recorded five things: overlap, what it maps to, what handles it natively today, the delta we lack, and a recommendation.
47 adopted (27 of them scoped down to just the delta on top of a native system), 12 superseded because a native system already covers them fully, 4 held with written reasons, and 122 indexed for later. Zero entries left undecided.
Every adopted skill was rewritten as a SwarmSystem contract: what it does, when it fires, how it runs on our stack with named files and lanes, what it must never do, and what receipts it emits. A lint gate blocks placeholders, another company's infrastructure names, and formatting violations. Nine desk teams of writer plus verifier agents produced the set; final lint result was 47 clean, 0 failures.
Ten personas, each with a one-line reason for the name, each recorded as a signed event in that desk's trust ledger. The operator's approval message in chat is the stored receipt. Names turned out to matter: a receipt that lands on Marshall's desk is owned in a way that a receipt landing in a folder is not.
Adoption and activation are separate gates. All 47 retrofits document their planned activation path, but nothing executes until the dispatch conversation happens. The catalog UI says so honestly: the wiring step renders as WORKING, pending the operator's details.
The honest version, not the polite version. These are the parts of your system that survived contact with a live operation.
Ten roles covered a real agency's desks with exactly one substitution (more on that below). We expected to redraw the chart; we kept your skeleton almost untouched. An imported org model surviving a live estate nearly unchanged is rare, and it is the strongest evidence the roles are drawn from real operating experience.
"Recruit an employee" reads as marketing until you need autonomy. Then it becomes the right abstraction: a named desk with scope, owned assets, an escalation lane, and a receipt trail is exactly the accountability structure autonomous dispatch needs. Your framing got us to that structure faster than we would have found it alone.
Because each skill is structured prose rather than opaque configuration, we could review it, diff it against our estate, and rewrite it for our stack. The entire 63-skill audit was only possible because the catalog is legible. Keep that property at all costs as you grow it.
The 126 entries we indexed still earn their place: they are a searchable inventory of what running an agency involves. When a new need appears, we now check the catalog before building. That is durable value from entries we never installed.
185 skills across ten roles reads like someone actually sat down and enumerated the job. Coverage was the strongest first impression, and it is the reason we committed to a full review instead of cherry-picking five ideas.
Your lifecycle framing translated cleanly into our gate model: review, approve, retrofit, wire. Each stage became an operator gate with a written receipt. The shape was already right; we just made each stage auditable.
Six points of friction, each with the number that measures it. None of them are fatal. All of them cost us real hours, and every one is fixable at the catalog level.
There is no mechanism to diff the catalog against what a buyer already runs. For us, 12 of 63 deep-reviewed skills were full duplicates of live systems and 27 more overlapped partially: 39 of 63, roughly 62 percent, collided with something we already operate. Any buyer with existing automation either builds their own overlap review, as we did, or double-builds without knowing it.
References to Atlas Folder, Granola, the Company Brain, and the OS connector run through the skill bodies. Every adopted skill had to be rewritten before it could run anywhere else; our lint gate had to explicitly ban those names to keep them from leaking into our registry. The capability and its infrastructure binding live in one document today. They should be two layers.
Catalog entries are static: a skill simply exists. There is no proposed, approved, adapted, superseded, live. We had to invent a two-axis model (tier and state) before we could govern adoption at all, and it did real work: it is how 185 entries reached zero-limbo in two days.
Some skills are entire job descriptions; others are single tasks. Two of your skills measured the same economics at different grains (per-run cost versus per-role profitability), and only a manual expert pass caught that they must be paired rather than merged or double-built. Ungoverned grain is how buyers silently build the same thing twice.
Skills say what they do, not what evidence they emit or who reviews it. For autonomy work the evidence trail is the product: a skill that cannot say where its output lands cannot be trusted unattended. We added a mandatory receipts section to all 47 retrofits; the catalog gave us nothing to start from.
The model quietly implies persona agents that run as workers. In our environment, long-lived persona swarms are a proven failure mode (they died on context overflow), so we adopted personas as an accountability lens over existing assets instead, and it works beautifully. The catalog supports both readings but never says so, which will confuse buyers whose infrastructure cannot host resident workers.
Five design decisions carried the adoption. We are sharing the internals because they are, in effect, the adoption machinery we think the catalog should ship with.
The org chart file remains the only operational record of what each desk owns. The catalog API projects our 47 native skills into the catalog view at read time, tagged as LIVE, instead of copying them into the registry. There is no second source of truth to rot. When a desk gains an asset, the catalog updates itself. This one decision dissolved the hardest governance argument of the whole build: which file wins.
Every entry carries a tier (how much we want it: CORE, ADAPT, HOLD) and a state (where it is in its life). Tier is an opinion; state is a fact. Keeping them separate is what let 185 entries resolve cleanly.
| State | Meaning | Count today |
|---|---|---|
| PROPOSED | Imported, not yet reviewed | 0 |
| RETROFITTED | Approved and rewritten as a contract for our stack, awaiting wiring | 47 |
| SUPERSEDED | A native system already covers it fully; the entry points at what covers it | 12 |
| INDEXED | Cataloged as a capability reference, not adopted (4 of these formally held with reasons) | 126 |
| LIVE | Native skill projected onto the chart from the org record | 47 |
Every deep review is a small structured block, and the block is what makes verdicts auditable months later. Five fields did all the work:
| Field | What it captures |
|---|---|
| overlap | NONE, PARTIAL, or FULL against the native estate |
| mapsTo | The exact native assets it collides with, by id |
| nativeToday | What already handles this, in one honest sentence |
| delta | The part we genuinely do not have |
| recommend | KEEP, DELTA, COVERED, or HOLD, which maps mechanically to a state flip |
An adopted skill is not installed, it is rewritten. Each of the 47 files answers five questions in order, under frontmatter that names its desk, its triggers, what it touches, where receipts go, and its activation path:
| Section | What it must answer |
|---|---|
| What it does | The capability in plain words, grounded in our business |
| When it fires | Triggers and cadence, not vibes |
| How it runs in HiveMind | Numbered steps naming real files, tools, and lanes on our stack. Delta-scoped files open by naming the native system they extend |
| What it must never do | The hard boundaries, including when to stop and escalate |
| Receipts | Exactly what evidence lands where, and who reviews it |
A lint gate enforces the shape: required keys, no placeholders, no emojis, and no references to another company's infrastructure. Writers failed it 23 times on the first pass. That is the gate working.
Each desk has a name, and each name is an accountability surface with a signed event history. Autonomy is not a toggle here: it is a promotion history you can read. The one structural substitution we made to your taxonomy lives on this chart: Head of HR became Head of Agent Operations. A solo operator has no human staff; the workforce is agents, and that desk needed an owner for fleet health, heal loops, and agent economics. If your buyers skew toward solo operators with agent fleets, that substitution will likely generalize.
| Desk | Persona | Owns |
|---|---|---|
| Executive Assistant | Porter | Inbox watch, drafting in the founder's voice, daily carry |
| Chief of Staff | Marshall | Schedulers, the daily brief, cross-desk order |
| Chief Knowledge Officer | Quill | The brain: memory, lessons, retrieval, session logs |
| Chief Marketing Officer | Vega | Visibility engines, content systems, audience language |
| Chief Revenue Officer | Banks | Offers, proposals, revenue reporting and attribution |
| Client Success | Haven | Client reporting cadence, check-ins, retention signals |
| Producer | Mason | Deliverable builds: pages, reports, sites |
| Brand Director | Scarlett | The brand system and every pixel that ships under it |
| Skill Architect | Wright | Skill creation, vetting, and the registry itself |
| Agent Operations | Hale | Fleet health, self-heal loops, agent economics |
In the product, every desk renders as a proof page: identity, owned assets grouped by kind, charter, authority boundaries, and the trust timeline. Every skill renders as a card with its state, its review verdict, its activation path, and a wiring map that shows honestly which connections are live and which are planned. The page never claims more than the registry can prove.
Eight changes, ordered by how much pain each would have saved us. Every one of these is something we ended up building ourselves to complete the adoption, which is the strongest signal we can offer that the catalog should ship it.
Include the overlap review as a first-class step: a buyer-side pass that scores every candidate skill against their existing estate and records overlap, maps-to, delta, and a verdict of keep, delta, covered, or hold.
What it unlocks: the pitch changes from "replace what you have" to "we meet your existing systems," which is the only pitch an established operation can say yes to.
A portable capability contract (what it does, when it fires, hard boundaries, receipts) and a separate infrastructure adapter (the Atlas Folder and Granola specifics). Buyers on other stacks then retrofit the adapter, not the skill.
What it unlocks: adoption on any stack without the rewrite pass that consumed most of our build time.
Proposed, approved, adapted, live, superseded. Keep desirability (tier) and progress (state) as separate axes.
What it unlocks: the catalog becomes a governance surface, and every customer gets a progress dashboard for their own adoption for free.
Every skill declares what evidence it emits, where it lands, and who reviews it. No receipts section, no listing.
What it unlocks: autonomy sells on evidence. A role that can show its receipts is a role an operator will actually leave unattended.
Tag each entry as role grain, workflow grain, or task grain, and name its pairings when two skills measure the same territory at different grains.
What it unlocks: prevents the silent double-builds we caught only by hand.
Document two adoption modes: recruit (a resident runtime worker) and overlay (the role as an accountability lens over an existing estate). We run the second, and it delivered the trust structure without any resident processes at all.
What it unlocks: the large market of operations that already have automation and cannot or will not host resident persona agents.
Model each role's autonomy as a signed event history (hired, christened, promoted, scoped), not a settings toggle. The approval message itself can be the stored receipt; ours is.
What it unlocks: "how much do I trust this role" becomes auditable, which is the question every buyer is silently asking.
Stage the gates: review, approve, retrofit, wire, each closing with its own receipt. We held wiring deliberately and the system stayed honest about it in the UI.
What it unlocks: buyers keep control at every step, and you get natural onboarding milestones instead of one terrifying go-live.
Your role taxonomy is the real thing. It survived contact with a live, heavily automated operation almost unchanged, and the role-first framing moved our autonomy work forward by a genuine step. What the catalog is missing is the adoption machinery around it: overlap review for buyers who already run systems, a lifecycle for entries, receipts as a contract, portability between stacks, and an explicit second mode for personas as an accountability lens.
We built all of those pieces to bring your catalog in. They worked: 185 entries fully resolved, 47 skills rewritten and standing by for wiring, ten named desks with signed ledgers, zero entries in limbo, two working days. Those are the pieces we would most like to see the catalog ship with, because the next operation like ours should not have to build them. Thank you for building the roles. They are now load-bearing here.