Agents Supervising Agents: Four Principles for Safe AI-Automated Collaboration

When Agents Start Supervising Agents

As AI Agent capabilities advance rapidly, a new engineering paradigm is emerging: having agents supervise other agents. It sounds like something out of a sci-fi movie, but in practice at the WorkOS engineering team, it has become a key path to improving automation efficiency.

An AI Agent refers to an AI system capable of autonomously perceiving its environment, formulating plans, and executing actions. Unlike traditional single-turn Q&A-style AI, agents can decompose complex goals, invoke external tools, and make autonomous decisions across multi-step workflows. Since 2024, with the leap in reasoning capabilities of large language models like GPT-4 and Claude, agents have rapidly moved from academic concept to engineering practice. Typical applications include automated code generation and review, customer service ticket handling, and data analysis pipeline orchestration. Multi-Agent Systems take this a step further by having multiple agents with different responsibilities collaborate on tasks — and the complexity and potential risks multiply accordingly.

However, having AI supervise AI isn't as simple as outsourcing tasks to machines and calling it a day. Without proper architectural design and safety boundaries, this "nesting doll" style of automation can easily spiral out of control — errors get amplified, costs become unmanageable, and accountability grows murky.

WorkOS is a technology company that provides enterprise-grade identity authentication and user management infrastructure for SaaS applications. Its products cover core enterprise IT capabilities including SSO (Single Sign-On), SCIM directory sync, and audit logs. Because its customers are predominantly enterprises with stringent security and compliance requirements, the WorkOS engineering team has a natural DNA for building highly reliable systems. Their work on multi-agent collaboration is a natural extension of enterprise-grade security thinking into the AI automation domain.

The core philosophy proposed by WorkOS engineers is: collaboration between agents must be built on a foundation that is controllable, visible, and intervenable. They distilled four key design principles that provide a practical engineering blueprint for the emerging paradigm of multi-agent collaboration.

Four Safety Design Principles

Headless Surface

The first principle is to build a "headless" supervision interface. Headless here means a pure backend service layer without a traditional graphical interface — all supervision logic goes through this unified interface.

Headless architecture is a software design pattern that fully decouples the frontend presentation layer from backend business logic. The concept first gained popularity in the CMS (Content Management System) space — for example, a Headless CMS delivers content via API without being tied to a specific frontend interface. In the agent supervision context, a Headless Surface means supervision logic is abstracted into a pure API layer that any supervisory agent can call through standardized interfaces, without relying on graphical interface interactions. This design naturally supports automated integration, batch operations, and programmatic auditing, while also making supervision actions amenable to version control and replay analysis.

The benefit is that supervisory agents don't need to simulate human UI clicks to get work done — instead, they call structured APIs directly for supervision. This not only improves efficiency but makes the entire supervision process programmable and auditable. Every supervision action leaves a clear record that supports future troubleshooting and root cause analysis.

Scoped Jobs

The second principle is to assign each agent clearly scoped tasks. This is critical — the most dangerous thing about a runaway agent is that it might go beyond its intended scope and execute operations it was never supposed to perform.

By splitting tasks into job units with clear responsibilities and well-defined boundaries, even if an agent behaves abnormally, its impact stays contained within a controllable scope. This is essentially the Principle of Least Privilege from software engineering, extended into the AI era: each agent is granted only the capabilities necessary to complete its specific task — no more, no less.

The Principle of Least Privilege (PoLP) is a foundational concept in information security, first articulated by Jerome Saltzer in 1975. Its core idea is that every subject in a system (user, process, or service) should be granted only the minimum set of permissions needed to carry out its legitimate work. In traditional software engineering, this manifests as fine-grained permission control for database accounts, minimal API surface exposure between microservices, and non-root user policies for container runtimes. Applying this principle to AI agents means each agent can only access the data and tools required for its task and cannot access other agents' resources or perform actions outside its scope. This is especially important in multi-agent systems because an agent compromised by prompt injection or experiencing hallucinations could cause cascading security incidents if it holds excessive permissions.

From a distributed systems perspective, scoped task design is essentially about controlling the blast radius of failures. Blast radius is a core concept in Site Reliability Engineering (SRE), referring to the extent of a system affected by a single point of failure. In microservice architectures, common blast radius control techniques include service isolation, the Circuit Breaker pattern, Rate Limiting, and the Bulkhead Pattern. Applying this thinking to multi-agent systems means each agent's task scope, accessible resources, and executable operations are strictly bounded, so that a single agent's failure or abnormal behavior cannot propagate across the entire system. This isolation design is especially important in AI scenarios because agent behavior is inherently nondeterministic — unlike deterministic bugs in traditional software, AI "failures" may manifest as subtle logical deviations or gradual quality degradation, making them harder to catch with conventional monitoring.

Cost Visibility and Human Gatekeeping

Visible Costs

The third principle is making operational costs transparent and visible. The cost of running AI Agents — especially fees for calling LLM APIs — can quietly accumulate within automation chains. When one agent calls another, and that agent triggers even more calls, costs can grow exponentially.

LLM API calls are billed per token, and pricing varies enormously between models. Taking OpenAI as an example, GPT-4o's input price is roughly $2.5 per million tokens, while a more advanced reasoning model like o1-pro can run up to $150 per million tokens. The cost amplification effect is particularly pronounced in multi-agent systems: an orchestration agent might dispatch tasks to 5 sub-agents, each of which may engage in multiple rounds of conversation and tool calls, with total token consumption for a single task potentially reaching hundreds of thousands or even millions. An even more insidious risk is the "recursive call trap" — agents handling ambiguous tasks may repeatedly retry or enter infinite loops, causing API bills to spike to hundreds or even thousands of dollars in a short period. The industry has already seen multiple cases of runaway AI Agents generating "sky-high bills," making cost observability an essential capability for multi-agent systems.

WorkOS's approach is to surface the cost of every operation in real time, enabling engineers to stay on top of current resource consumption at all times. This transparency not only helps with budget control but also triggers timely alerts when costs spike abnormally, avoiding the embarrassment of "bill explosions."

Human on the Merge Button

The fourth and most critical principle: retain human decision-making authority at the final merge step. No matter how efficiently agents collaborate with each other, the "merge button" that commits changes to the production environment still needs a human to press it.

This design reflects the prevailing consensus in today's AI engineering community — human-in-the-loop. Human-in-the-Loop (HITL) is a system design paradigm that embeds human judgment at critical nodes within automated workflows. The concept originated in cybernetics and military decision-making systems, and has been widely adopted in AI to address model uncertainty and high-risk decision problems. HITL takes many forms: from active learning where humans label samples the model is uncertain about, to remote takeover mechanisms in autonomous driving, to human merge approval in AI code review. In software engineering practice, combining HITL with CI/CD pipelines is especially natural — AI can automatically generate code changes, run tests, and create Pull Requests, but the final code merge requires human engineer review and confirmation. This design fully leverages AI's efficiency advantages while preserving human professional judgment and accountability at critical decision points.

It's worth noting that HITL is not a permanent solution. As AI system reliability improves, the frequency and depth of human intervention can be gradually reduced, but completely removing human oversight is still considered too risky under current technology conditions. It acknowledges AI's powerful capabilities while soberly recognizing that AI still makes mistakes, hallucinates, and makes decisions that don't align with business intent. Keeping humans at the final checkpoint is a rational balance between pursuing automation efficiency and ensuring system safety.

Implications for AI Engineering Practice

WorkOS's methodology provides valuable reference for teams exploring multi-agent systems. It reveals an important trend: as AI capabilities grow stronger, the engineering focus is shifting from "what can AI do" to "how to safely constrain what AI does."

From an architectural perspective, these four principles form a complete safety flywheel:

• A programmable supervision interface ensures operation traceability
• Scoped tasks control the blast radius of failures
• Visible costs provide resource-level transparency
• Human-gated merge steps hold the ultimate safety line

The value of this framework is that it doesn't resist AI automation — it's an engineering practice that makes automation trustworthy. In today's rapid development of Agent technology, many teams are eager to showcase how complex a task their agents can accomplish, while overlooking the robustness and controllability that production environments demand.

Truly mature AI engineering isn't about letting agents operate completely free of human control — it's about designing a collaborative system where humans can efficiently supervise, intervene promptly, and maintain clear accountability. WorkOS's "agents supervising agents" practice is a pragmatic step in exactly that direction.

Conclusion

"Agents babysitting agents" — this slightly tongue-in-cheek phrase carries deeply serious engineering thinking behind it. As AI takes on more and more autonomous decision-making, building proper safety guardrails becomes the deciding factor in whether this technology can truly be deployed in production.

WorkOS's answer is clear and pragmatic: define boundaries for agents, keep the process transparent, and leave the final decision-making authority to humans. This may not be the most radical AI vision, but it is likely the right path toward reliable and sustainable AI automation.

Key Takeaways