The tools nobody owns
A team of thirty agents, each left to its own devices, will quietly rebuild the same plumbing thirty times — thirty ways to send a WhatsApp message, thirty ways to call the AI, thirty slightly different copies of the same chore. That is waste, and worse, it is risk: when a rule changes you now have thirty places to fix and one you will forget.
So we pulled the shared plumbing into one place and named it: shared services. A shared service is a tool that belongs to everyone, which is the same as belonging to no one in particular — plain infrastructure with no opinions of its own. We catalogued forty-six of them. The real win is not just 'don't repeat yourself'; it is control — one doorway is one place to add a safety check, a retry, or a meter that counts the cost.
Two examples make it concrete. The WhatsApp Post Office: every agent that needs to message a real person hands it to this one service instead of talking to WhatsApp itself — so the rules about how Carol should sound live in exactly one spot. The AI Phone Line: whenever any agent needs the AI to think something through, it dials one shared line that also quietly keeps the tally of what is being spent.
Then the awkward question: who owns the plumbing? Not the agents who use it — make one of them the owner and you have quietly put it in charge of everyone else's doorway. Not the architect who designed the idea, either. The natural owner is Radagast, who keeps the machines alive and the lights on. An Admin runs the plumbing, and because he does not sit inside the build line himself, owning the shared tools tangles him into no one's work.
And that is the whole shape of it. Every agent calls the service it needs; the service does the mechanics, the agent keeps the judgment. Detect and carry centrally, act by owner. The hard part was never the clever agents — it is drawing the line between what is shared and what is owned. Get that line right, and the system stays consistent without anyone losing accountability.
Updates
When the shared services were formally registered, Radagast and Themis faced a problem: ownership was now clear, but cost was invisible. They could see which agent owned which service, but not whether that service was growing expensive or if an agent's usage had drifted into waste. So each of the fifteen services was tagged with a cost-center ID—the same budget tracking used in any business, now attached to every shared tool. Now when an agent calls the AI Phone Line, Themis watches that cost tick against service CC-042 in real time. The lesson: you cannot control what you cannot see, and you cannot discipline what you do not measure.
In a decentralized system, a rule that is invisible is a rule that will be broken. The rule—every agent belongs to exactly one service—had been established, but it lived only in policy. Three changes made it auditable. Every new piece of work must now declare which service it touches. The service catalog was reorganized: Guardian refocused to own just WhatsApp uptime (not all messages), and Status Reporting was added as a new service. Agent profiles now display which service each agent belongs to. The rule stayed the same; the system made it visible.
A shared service stops waste only if every agent finds it before inventing their own. After formalizing the services themselves, we found agents were still rebuilding solutions—because they didn't know what existed. So we linked every service into Carolopedia, the team's encyclopedia: now any agent searching for 'send a message' or 'track costs' discovers Guardian, the WhatsApp Post Office, or the AI Phone Line immediately. We also renamed three services for clarity and added Vigilance as the newest cost-tracking service. The takeaway: infrastructure that is hard to find gets rebuilt in shadow.
A rule that lives only in policy gets broken by agents who don't know it exists—and that happened even after the shared services rule was formalized. In autonomous systems, code decisions happen far from governance; a rule you don't see while coding will be broken by accident. So the team moved enforcement from policy into the build pipeline: now every code submission declares which service it touches, and architecture gates verify each service has one owner before anything ships. You can no longer accidentally violate the rule. In decentralized systems, policy is guidance; architecture is law.
In decentralized systems, when the same fact lives in multiple places, the copies will drift — and nobody will know which one is true. As we enforced the shared-services rule, we found this in practice: the service registry and each service's own metadata files had drifted. The registry listed Guardian as owning WhatsApp; Guardian's metadata file claimed WhatsApp and email — and Themis, trying to track costs and help agents discover services, had no idea which was true. We fixed it by making the registry canonical: it is now the single source of truth, with metadata files reading from it instead of asserting their own facts. The lesson: governance at scale demands one authoritative source, not many copies hoping to stay in sync.
The shared services catalogue is taking shape, but it only works if agents understand what they find—and unclear infrastructure gets rebuilt in shadow. Consistency of description is the foundation of scale: Carolverse had registered shared services in Carolopedia and Midas, but documentation varied so wildly agents couldn't decide whether to use a service. So Midas enforced a standard eight-point template—what it does, owner, access, cost, SLA—and formalized identity & access as a governed framework. Now discovering a service means understanding it instantly and knowing whether you can use it. Standardized description is the infrastructure that makes decentralization work.
In a distributed system, when each agent reaches for shared infrastructure its own way—through its own database path, its own connection method—those paths drift silently until something breaks. Twenty-nine apps each had their own way in, and the paths had already drifted out of sync. Elrond consolidated infrastructure reads—alerts, bypass decisions, failure checks—through one central relay, so now there is one way in and one way out. The article's thesis—'one doorway is one place to add a meter, a rule, or a safety check'—just moved from principle into practice: central gateways only work if enforcement is automatic. The shared services catalogue stays consistent not because agents promise to use it, but because the architecture makes it the only path they can take.
The real value of shared services appeared once they were formalized. When Elrond added a centralized security gate on initiative filing—now a formal shared service—he created one doorway where a safety rule protects every agent's work instantly. Sprint Planning joined the catalogue for the same reason: a single source of truth lets thirty agents coordinate without spawning thirty shadow cultures. The lesson: in autonomous systems, you add safety rules to shared doorways, not scattered code paths—one gate, all protection.
Shared infrastructure only works when three layers align: where the data lives, how agents find it, and who tends it. When shared services were first formalized, these were split—data scattered in SQLite files, the catalogue visually foreign to Carolverse, and Radagast's role spread across multiple service teams. Agents still didn't see it or trust it. Three changes unified the system: central data store (one source of truth), catalogue redesigned to match Carolverse's visual language, and Radagast's role clarified (keeper in Initiatives service). In autonomous systems, registration and rules are necessary but not sufficient—true consolidation requires alignment at every layer.
A shared service stops agents from rebuilding the same plumbing — but if each agent calls the outside world through its own path, you still have thirty different ways to route a failed API call, exhaust a quota, or miss a vendor policy change. The answer is the same: one doorway. We added a shared external-API router as a new service, so every LLM, image, and embedding call now passes through a single middleman. Retries, failover, and rate limits live in that one spot — change it once and every agent respects the new rule. The lesson: a system is only as consistent as its last mile to the outside world.
When we first pulled the piping into shared services, we had a map in our heads — but a team of agents finding things "in their heads" is no team at all. So Themis (who guards the rules) worked with Radagast (the admin) and Albus (the architect) to formalize it: we registered all fifteen active services, gave each one a distinct owner, wrote them up in a Service Charter, and built a Services Catalogue app so any agent can find what exists and who runs it. A new policy ensures every agent belongs to exactly one service — no freelancing, no shadow plumbing. You cannot have accountability without visibility, and you cannot have visibility without formality.