Share with your CTO
Only 23% of organizations are scaling agentic AI, and most of those are doing it in just one or two business functions, according to McKinsey’s November 2025 State of AI report. The bottleneck isn’t model quality. It’s coordination. Peter Hesse, a partner at custom software firm 10Pearls, makes the case that enterprises need a formal multi-agent orchestration framework before they scale, arguing that security, compliance, and observability problems compound faster than teams expect when agents start talking to each other across workflows and system boundaries.
What this means for your business
The organizations that stall at one or two agentic use cases almost always stall for the same reason: they built each agent as a standalone project, encoding security rules, compliance checks, and logging logic directly into each one. That works at pilot scale. It collapses when the fifth or tenth agent arrives and nobody can audit what any of them decided or why. Where you sit on this depends on whether your current agent deployments share infrastructure or are essentially independent science experiments dressed up as production systems.
Hesse’s core prescription is a centralized policy enforcement layer, a single governance plane that all agents pass through rather than duplicating compliance logic inside each one. This is the right instinct, and it maps cleanly to how mature API gateway architectures (the middleware that controls how software services communicate) handled a similar problem a decade ago. The argument gets slightly optimistic, as you’d expect from a consultancy that builds these systems for clients, on how quickly an organization can retrofit an enforcement layer onto agents that were never designed with shared infrastructure in mind. Agents trained to operate autonomously don’t always behave predictably when a new constraint layer appears between them and their tools.
The more durable point in Hesse’s argument is the architectural shift underneath it. Enterprise applications built for human users are organized around screens and clicks. Applications built for agents need to be organized around services and APIs that expose data and trigger workflows programmatically. That’s not a configuration change; it’s a rearchitecting of how you expose business logic. Teams that treat agent orchestration as a deployment problem and skip the underlying API modernization will hit a ceiling that no framework, commercial or open source, can lift for them.
The decision this reframes isn’t which orchestration framework to buy. AWS, Microsoft, and a cluster of open source projects will all compete for that budget, and the differences between them matter less than the state of the APIs they’ll be calling. The more useful question is whether your current application portfolio can actually support agent-readable services, and if the answer is mostly no, that’s a modernization roadmap conversation your architecture team needs to have before the next agent pilot gets greenlit.
Concept deep-dive: Policy enforcement layer
A policy enforcement layer is a centralized checkpoint that every agent interaction passes through before executing, rather than embedding rules inside each agent individually. Think of it as a shared traffic officer for AI workflows, applying security, compliance, and business logic consistently regardless of which agent is acting. Without it, enforcing a new regulatory requirement means updating every agent separately. With it, the change happens once. The business connection is audit-readiness and control at scale, not just cleaner code.
Based on reporting from Plan a multi-agent orchestration framework for scalable AI, originally published 2026-10-31 01:39:00.
