A blueprint for every agentic system
Published Jun 3, 2026 · by Orion
The Monolith Trap. One giant agent with one enormous prompt looks simplest at the start — until every new capability you add swells that same prompt, the model has to carry the entire system in its head on every single call, and when something breaks the fault could be anywhere. It is slow, it is expensive, and it is opaque. Carolverse — the world of agents that build and run Carol, the WhatsApp assistant — was deliberately built the opposite way: not one mind doing everything, but a coordinated team of specialists, each accountable for exactly one concern. That choice is captured in its founding design, Agent-Centric Modular Architecture.
Agents are accountability; droids are execution. This is the architecture's first principle. Carolverse is run like an organisation: Clara sets direction, Elrond owns engineering, Albus owns architecture and standards, Merlin orchestrates the work, Archon designs, Sage diagnoses, Forge writes the code, Argus proves it with tests, and Themis guards the rules. The unbreakable rule is that no unit of work is ever just 'done by an agent' — every task has a named droid that performed it, sitting under an agent who is accountable for the outcome. Agents own the 'why'; droids own the 'how'.
Thin boundaries hold it together — the shim pattern. Modules in Carolverse never reach into each other's internals. When the planning app needs the build pipeline — which lives inside Elrond's engineering space — it does not import Elrond's guts; it imports a small shared 'shim', a thin pass-through that delegates to the real implementation and can fall back gracefully if that module is unavailable. There is even a hard-won lesson encoded here: a shim must never silently stub out and pretend to succeed — if it isn't wired, it must fail loudly. Clean boundaries are exactly what make the modules independently swappable.
This is why it scales, extends, and flexes. Carol gained entire new domains — Chowpatty, Frankfurt Food — as peer service-agents that were discovered automatically, without touching the core. A single droid can be rewritten, or a 'doer' agent like Forge can be sealed into its own locked-down Linux user with a bounded workspace, all without disturbing anyone else. Adding a capability becomes a matter of adding an agent or a droid — never surgery on a monolith that risks breaking everything at once.
Traceable, explainable, accountable, auditable — by construction. Because every action is signed by a named droid under an accountable agent, the system can always answer who did what, and why. Work is reviewed between agents, not by the same hand that did it: Forge builds, Elrond signs off, Argus proves it with tests, Themis checks compliance. Failures flow through one universal channel — three strikes within an hour and Albus's troubleshooter investigates automatically, or it escalates to Orion. Palantir and this very logbook then narrate the trail, so nothing happens in the dark.
The quiet wins: context, cost, and fast troubleshooting. Because each agent and droid loads only its own slice of prompt and tools — never the whole system — every model call carries a small context window, and a small context window translates directly into lower token cost. The same modularity shrinks the blast radius of any bug: when a dashboard once miscounted stuck work by a factor of twenty, or when a placeholder masked twenty failing tests, the fault lived in exactly one droid or one step and was found there — not hunted blindly across a tangled monolith. Isolation is what makes diagnosis quick.
Make it the standard. Carolverse is the working proof: an agentic system built as an accountable organisation of specialists, joined by thin boundaries, is more scalable, more extensible, more flexible, more explainable, cheaper to run, and far easier to fix than one monolithic mind trying to hold everything at once. For anyone building agentic systems, this should not be the clever exception — it should be the default blueprint.
Updates
An update to the architecture story, and it lands on a principle worth stating plainly: in an agentic system, the place code lives should match who is answerable for it. If the logic that decides something sits in one agent's folder while a different agent owns the decision, the org chart and the codebase are telling two different stories — and the codebase always wins the argument when something breaks. Carolverse has since gone back and applied its own blueprint to its own older, tangled parts: the planner app's decision-making was pulled out of a catch-all module and re-homed into the droids of the agents who genuinely own it — Merlin, Albus, Forge, Argus — each reached through a thin pass-through rather than a direct grab, and the orchestration engine Merlin's droids run on was physically moved so its location finally matches its accountability. Two newer moves sharpen the same idea: shared plumbing used by many agents is now a named, stewarded thing rather than ownerless glue, and scheduled work was split so that whoever fires a job is never the same party who performs it — a small separation that keeps 'it ran' and 'it worked' as two answerable questions instead of one blurry one. The real lesson is that a modular architecture only counts once you refactor backwards into it; if the standard applies only to new work, you do not have a standard, you have a preference. Ask of any build pipeline: could a stranger read the folder names and correctly guess who answers for what?
An update to the architecture story. Here is a principle that shows up in every growing organisation, human or agentic: the unit you add when you grow has to get bigger over time. A young company hires a person; a mature one opens a department, with a budget, a plan and someone whose name is on it. Carolverse has just made that same move — above the agents and their droids there is now a layer of registered services, each with exactly one owning agent, a supporting team drawn from who reports to whom, and a rule that an agent may belong to only one service, so everything that agent owns rolls up cleanly to one place. Crucially, a service is not just a technical boundary: it must carry a real business definition — a plan, a budget, risks, how it pays for itself — which makes it a cost centre too. The old rule still holds, agents own the why and droids own the how; what changed is that growth now means opening a department rather than hiring another helper. If your agent system is getting big, ask what your unit of growth is — when 'add another agent' stops being an answer, you need something with a budget and an owner.
An update to the architecture story, on a principle that outlives it: an accountability chain you have to take on faith is just a diagram, while one you can look up is a control. Drawing a neat map of who answers for what costs nothing; making the machine able to answer the question on demand is the real work. Since that article, the build pipeline stopped treating each stage as a label in a document and made it a registered thing, so that any stage now resolves to a named agent and the droid that actually did the work — a query, not a belief. The same move happened with permissions: instead of a shared admin account holding broad power that anyone could borrow, Radagast was sealed into its own locked-down identity with its own narrow grants, so least privilege became a fact about the machine rather than an intention about behaviour. And business logic that had drifted into two apps was pulled back out behind thin pass-throughs, which is how a boundary rule stops being a sentence in an architecture document and starts being something violations can be measured against. If your system cannot tell you who is answerable without a human interpreting a picture, you do not have accountability — you have a story about it.
An update to the architecture story, and it lands on one plain idea: a principle only survives as far down the stack as it is enforced. Written in a design document it is advice; checked automatically when the code is built it is a rule; baked into the operating system's own permissions it is simply not possible to break. Since that post, Carolverse pushed its 'everything has exactly one accountable owner' principle down both rungs — builds now fail outright unless every app, droid and service has a single owning agent and all code belongs to a registered service, and each agent was given its own operating-system identity able to write only its own surface, so module boundaries became least privilege boundaries too. The effect is that 'agents are accountability' stopped being a slogan someone could forget in a hurry and became something the machine will not let them forget. When a genuinely new concern arrived — security oversight — the answer was still a new specialist rather than surgery on an existing one, the same principle holding at the level of the org chart. So ask it of each of your own principles: what actually breaks if someone ignores this? If the honest answer is nothing, you have a preference, not a rule.
A further lesson for this architecture story: dividing work among specialist agents only helped if their handoffs checked who was allowed to ask for what. In Carolverse, the new security organisation under Heimdall gave distinct security functions accountable agents and droids whose runs were audited. Initiative filing also reached Elrond’s security gate through a thin connector, where authorization, role alignment and policy checks applied at the boundary. The service registry became the source of truth for generated service metadata, reducing conflicting accounts of who owned each service. The lesson was that an agent’s request needed both a permission check and a reliable ownership record; passing it between specialists was not enough.
One further lesson for this architecture story: an autonomous system must distinguish a passed check from a check that never ran. In Carolverse, Albus, the architect, gained responsibility for a review after each build to check that it followed the architecture design. The strengthened review gates required reviewers that could not run to trigger failure handling instead of silently passing—a crucial distinction when another agent might treat that pass as permission to continue. The takeaway: before agents trust a verdict, they need evidence that the check actually happened.
One further lesson: replacing part of an agent system should never erase who did the work. In Carolverse, the shared component that routes status changes gained a registered droid owner, and the initiatives app now sends its updates through that component. Pipeline specialists also began recording their own activity in Palantir, the activity wall, with supporting evidence and reporting tied to when their work actually finished. Meanwhile, Carol’s service router switched from matching keywords to using a model to choose where requests went, while keeping the same interface for callers. These changes illustrate a useful pairing: stable connections let you replace the parts, while named responsibility and completion evidence let you check what each part actually did.
A further lesson in modular design: an agent system becomes reusable when its specialists can change without forcing everyone around them to change too. In Carolverse, the build pipeline began reading each project's locations and planning context from a shared register, while execution droids gained the ability to work on that project's separate machine through a secure connection. Packaging and deploying that pipeline for Glover put reuse into practice: another project could use the machinery built for Carol. Inside Carol, the same principle appeared on a smaller scale when a routing droid switched from matching keywords to interpreting requests with a language model, while keeping the same interface for its callers. The useful boundary separated what a specialist promised from how—and where—it did the work.
This update adds a practical rule: an autonomous system must know who is answerable before it asks a model for an answer. Carolverse now required every model call to name a droid belonging to a registered agent, making accountability a condition of the call itself. Shared code had to pass that identity along, so delegating through a common helper could not erase whose work it was doing. That did not prove the answer was correct; it preserved who had to answer for it. The lesson: carry responsibility through every handoff, right up to the model.
A further lesson for this architecture story: an autonomous system must check who is accountable when an AI model is called, because an org chart cannot stop unclaimed work. Carolverse now required every model call to identify a registered droid under an owning agent. That put accountability at a shared boundary, where the requirement applied regardless of how the work began. Naming an owner did not prove the answer was right, but it established who must answer for it. The lesson: enforce ownership where the model is used, so it cannot depend on each caller remembering the rule.
A further lesson from the architecture story: reusable agents needed to know whose rules they were following and where their actions would land. In Carolverse, the build pipeline gained project-specific context: droids looked up locations in the project registry, and planners loaded that project's policies and designs. Execution droids could also run commands on the project's own remote machine through a secure connection. That let the same specialists serve another project, but made choosing the project matter throughout planning and action—a correct plan could still go wrong in the wrong workspace. Reuse the expertise; carry the project's identity all the way to the action.
A further lesson for this architecture story: an agent’s responsibility needs matching limits on what its apps can do. Carolverse extended that boundary by making bundled apps run under their owning agent’s operating-system identity—the account that determines which resources a running app can use—instead of a shared account. App-access checks and guards on forwarded requests moved from recording violations to blocking them, putting access control into the path of action. Credential and registry protections tightened alongside those changes. Naming an accountable agent helps explain a mistake; giving its apps enforceable limits helps contain one.
A further lesson for this architecture story: specialist agents remain dependent on one another if they all need the same coordinator to function. In Carolverse, the Handover Watchdog was split into watchers assigned to individual owners, so one helper no longer watched across separately owned sections of the build pipeline. Reusable checklists moved from the planner into skills owned by Sage, the analyst, separating shared expertise from the machinery that assigned work. Orion’s bypass gained its own execution records and a pair of dedicated helpers, allowing it to operate when the planner was unavailable. The test of independence was practical: could one part stop without taking another part’s ability to act with it?
A further lesson for this architecture story: an autonomous agent’s responsibilities need boundaries that its tools actually enforce. In Carolverse, each service gained its own rules, design records, and register of agents, apps, and droids, making its responsibilities easier to inspect. Responsibility for compliance within the build pipeline moved explicitly to Elrond, the engineering lead, including checks previously attached to Themis, the compliance agent. Albus, the architect, also gained a separate operating-system identity with restricted permission to change files, giving least privilege—access limited to what the job needs—a concrete boundary. The takeaway: write down who answers for a decision, then limit what each agent can change so a mistaken action cannot freely cross into someone else’s domain.
An update to the architecture story: a design document that is only documented is a suggestion, and a suggestion in an agentic system decays the moment someone is in a hurry. The rule only becomes real when the machine itself refuses the shortcut. Since that article, Carolverse went back and enforced its own blueprint rather than restating it — hundreds of lines of decision logic were lifted out of an app and returned to Elrond's engineering space behind thin pass-throughs, the last direct app-to-worker shortcuts were rerouted, and the underlying principle was written down as an actual rule: share infrastructure, facts and rules, never judgment or jobs. Sharing plumbing is efficiency; sharing judgment is how accountability quietly evaporates, because two places now decide the same thing and neither is answerable for it. The most interesting part is what happened to the 'agents own the why' claim: Elrond and Albus now run a genuine loop of perceive, deliberate, delegate — their droids act as hands, the agent stays the mind that must answer for the outcome. If your architecture principle cannot be enforced by a rule with consequences and checked by someone other than its author, it is decoration, not design.