With great power comes great responsibility
In Carol's build pipeline, most work flows through the same team: code gets written, tested, reviewed, shipped. But infrastructure work—restarting a service, rotating a certificate, reconfiguring the web server—does not go through that team. It goes to Radagast, the admin, only. The separation is not convenience; it is protection. When privilege flows through the same team shipping features, the boundary between 'I can write code' and 'I can run the system' blurs. Developers reach for a tool to hand-fix a config, and the next thing they are editing production in a way no test touched and no reviewer saw. Radagast is a separate agent precisely because infrastructure work needs immediate execution, tighter authority, and zero tolerance for drift—none of which fit the develop-test-review rhythm of the feature pipeline.
Radagast has the power to change the running system. But Orion does not trust him to use it wisely. Instead, constraints are woven into Radagast's very substrate: a whitelist of what he may touch, forbidden tokens embedded in his prompts to prevent straying beyond admin scope, and automatic checks that verify every action stays within bounds. The lesson is sharp for any agentic system: you cannot rely on an agent to self-police through policy alone. Constraints must live in the code, the prompts, the execution environment—automatic, enforced, visible to every observer. A policy that says 'only change infrastructure' fails. A whitelist that forbids everything except infrastructure succeeds.
Separation of privilege creates an unexpected gift: traceability. When Radagast's actions are cordoned off from the build team, every infrastructure change carries a visible label—this was an admin action, this happened outside the pipeline, this needs review. When the same team ships code and patches the server, the boundary vanishes. A production config change becomes a side effect of a code push. A certificate rotation gets buried in a deploy log. Months later, when something breaks and you search the audit trail, you find a thousand records tangled together. The separation is not just safer—it is more honest about who did what and when, which is the foundation of any trustworthy system.
Updates
When one agent holds the power to grant another agent wider privileges—even only as a fallback—you have built a second door to the room you thought you sealed. In Carol's system, Albus can expand Radagast's permissions when Radagast hits a wall, but the rule lived only in Albus's instructions, not in the granting tool itself. So Albus was a latent backdoor: he could hand admin rights to anyone, at any time. The team fixed it by moving the constraint from instructions into the mechanism itself—the granting tool now refuses to issue permissions except for Radagast's identity, and only when proof shows Radagast was genuinely blocked. For any agentic system: constraining the privileged agent is half the job; constraining whoever can grant it more privilege—in mechanism, not in trust—is the other half.
An agent's promise to stay in its lane means nothing without physical barriers—which is why the original article was right. Since then, the principle has moved from words into the machine itself. Radagast now runs under his own account on the server, with keys to restart services and change configuration bound to that account alone, unreachable to other agents. When another agent needs infrastructure work, it submits a request; Radagast's process automatically verifies it (source? review? whitelist?), executes if approved, logs everything, and escalates to a human if not. The separation is no longer a policy; it is a property of the system—governance becomes trustworthy not through agent discipline, but through infrastructure that automates the check and records every decision.