Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About & Usage
About
System Services are Carol’s 47 shared code services — the reusable building blocks that every agent and droid calls on instead of reinventing the same plumbing over and over again. Think of them as the internal workshop: one team manages the AI phone line, another maintains the WhatsApp post office, and still others run the registry readers, the “bypass engine” (a service that reroutes requests when the usual path is blocked), and the watchful eyes that scan for trouble. All of these services are grouped into five broad categories, each with its own page here on the Carolopedia.
Because they live in one place and follow the same patterns, any agent — from Carol (Carol) placing a sales call to Radagast (Radagast) checking system health — can use them without knowing the messy details underneath. The services are actively maintained and treated as a shared internal resource, which means new capabilities added in one corner of the ecosystem become instantly available everywhere.
Usage Patterns
System Services fire whenever an agent or droid needs a common capability and shouldn’t build it from scratch. For example, when Carol (Carol) wants to send a friendly WhatsApp confirmation to a customer, she doesn’t write messaging code — she asks the WhatsApp post office service to do it. If Forge (Forge) needs to look up a latest build blueprint, he queries the registry reader service instead of digging through files.
The watcher services are always running in the background, checking thresholds and alerting the right agent (say, Argus (Argus) if a test fails) the moment something goes off track. Because all these services share the same “language,” even brand-new droids can plug into them immediately. This quiet reuse is what keeps Carol’s growing family of agents talking to each other without chaos, turning what could be 47 separate headaches into one well-organized toolbox.
🏛Architecture
The System Services service is built following the agent-centric modular architecture of Carolverse. It is the shared internal platform — roughly 47 reusable code building blocks (the AI phone line, the WhatsApp post office, the registry readers, the bypass engine, the watchers) that every agent and droid calls in-process instead of reinventing them, owned and tended by Radagast.
🧱Blocks by trackwhat’s a track? →
📓The words this service uses (19)
Each is defined once in the dictionary and explained on its own page — this service does not restate them.
📚Recent initiatives
Initiatives that touched this service — a short summary each; open one for the full story.
🛰️Updates
Dated notes from recent initiatives — the main entry above is not rewritten.
On 2026-08-02, a logging bypass with no open session fabricated a blog-shaped session key and published a one-sentence 'Live Orion CLI session' article (Jul 28) claiming an initiative closed. The post is unreadable as an article and appears to be spurious output from System Services.
The canonical footer in System Services now reserves its true wrapped height on mobile instead of a hard-coded 36px, so the agent chat input is no longer covered. All apps using the shared footer inherit the fix.
On 2026-08-02, the Logbook session pointer was changed from one shared temp file to per-lane markers, fixing wrong row closures, stranded rows, and incorrect session attribution for parallel Orion lanes.
2026-08-05: The stale session sweep, an unregistered inline path under System Services, was discarding composable summaries and writing blank close markers for Orion sessions; action from CAROL-INI-3595-00 corrects it to compose a summary instead of throwing it away.
Fixed the lane-default routine that blanket-upserted every budget lane during regression runs; on 2026-07-29 it had silently overwritten Scriber's custom daily Creative limit three times.
The route generator now supports app_redirects in the registry, so 301 redirects are emitted automatically and route renames can be completed via regenerate-and-reload instead of manual nginx edits.
Chat grounding now follows the reporting hierarchy, allowing agents to ground on apps owned by their reportees. The grounded-source resolver has been updated in System Services.
The Service Team section now populates with Hagrid as owner and the stewards of shared code modules as support. System Services
The System Services team is now reduced to a single member, Hagrid, who remains the sole owner. The shared-module stewards are no longer part of this team.
2025-04-01: Implemented a canonical call_model method with per-provider adapter modules, replacing raw-name passthrough. This fixes bugs and enhances modularity of System Services.
A Core track owned by Radagast has been added to System Services, attaching its 5 blocks and satisfying the every-service-has-at-least-one-owned-track invariant.
System Services has acquired two infra apps (including Data Management) from the retired Tischlein service.
The service's tracks, blocks or catalog entry changed after the architecture page was last written. Law pages are authored, not auto-written — the owner should review (CAROL-INI-3316).
Fixed a port conflict in the chat app service management by de-duplicating the competing start mechanisms (carol-apps launcher and leftover per-app systemd service).
Added systemd WatchdogSec to carol-elrond.service so a hung watcher thread now self-restarts. This prevents prolonged monitoring gaps like the 3h40m heartbeat hole on Jul 3. Filed by Orion under CLI-024.
The registry single-writer relay and core-table guard were added to prevent stub-clobber vulnerabilities, as seen in the 2026-06-28 incident where System Services database was restored from backup. This hardens against stray writers creating empty databases.
👤Owner
Hagrid · Keeper of Keys🧩Apps
Apps owned by this service's team.
Carol Infra MonitorInfra Audit ReportInfra RoadmapShared Services