Control Tower or Subway Station? A Vendor-Neutral Framework for Enterprise AI Agent Orchestration

An enterprise AI agent orchestration strategy is the set of decisions that govern how autonomous agents identify themselves, what they’re permitted to do, and how their actions are audited across your tools. The right strategy keeps agents interoperable rather than locked to one vendor, by standing up a shared identity, permissions, and audit layer before adopting any single vendor’s orchestration product.

Every major platform vendor now wants to sell you the layer that sits above your AI agents. Atlassian, Microsoft, Salesforce, and ServiceNow are each pitching some version of a “control tower” for the agents running through your business. The pitch is seductive because the problem is real. But the framing deserves scrutiny, and the most useful pushback on it came from a vendor itself.

Why agent sprawl, not model quality, is the real bottleneck

The constraint holding enterprises back is no longer how smart the model is. It’s how many ungoverned agents are now acting inside your systems with unclear identity and no audit trail. Atlassian reported more than 10 million human-agent collaborations on its platform every month, double the level of six months ago, with its Model Context Protocol server handling 15 million tool calls a day. Multiply that kind of volume across Jira, a CRM, a help desk, and a dozen SaaS tools, and the question stops being “can the agent do the task” and becomes “who authorized this agent, on whose behalf, and can we prove it later.”

This matters because sprawl compounds quietly. If you’re running pilots in three departments, each wired to a different vendor’s assistant, you don’t have an AI strategy — you have three disconnected automation silos that will fight over permissions the moment they touch the same data. The organizations pulling ahead are the ones treating orchestration as infrastructure, not as a feature bundled into whichever tool they happened to buy first.

Control tower versus subway station: two orchestration models

There are two competing mental models on offer, and the difference determines how locked-in you’ll be. The control tower model says one vendor sits above everything, owns the orchestration layer end to end, and directs every agent through its hub. The subway station model, as Atlassian co-founder Mike Cannon-Brookes framed it on the company’s Q1 FY2027 earnings call, is different: a highly connected point where humans, agents, and workflows converge with shared context and clear identity, but without any one vendor owning orchestration end to end. His words: “Our goal is to help you get things done as a customer. It is not to be in control of your world. It’s your world.”

Cannon-Brookes also made a sharp observation about the crowded field. Many vendors are using identical vocabulary — “agent identity, permissions and audit” — to describe very different things, because, as he put it, the terms mean “a lot of different things to a lot of different customers.” That’s the buyer’s trap. Most vendors staking out agent identity are extending outward from something they already own: an identity system, an HR system, a system of record. The architecture you inherit depends entirely on where your vendor started, not on what your business actually needs.

The three non-negotiables: identity, permissions, and audit

Whatever you buy or build, three capabilities are non-negotiable, and they should live in a layer you control rather than inside any single application. First, agent identity: every agent needs a durable, verifiable identity distinct from the human it serves. Second, permissions: an agent’s authority must be scoped and governed, not inherited wholesale from a user’s credentials. Third, audit: you need a traceability model that shows where a human acted, where an agent acted on a human’s behalf, and which agent was operating for whom.

Atlassian’s Agentic Multiplayer Protocol (AMP) is one implementation of exactly this — a collaboration layer offering shared context, clear identity, attribution, and governed authority, described by the company as built across its platform rather than sold as a separate product. The design point worth stealing regardless of vendor is that these three controls should be interoperable across tools. An agent authored in a coding CLI or in Figma should carry the same identity and audit trail when it touches your work. If you’re a regulated business, this is the same discipline you already apply to compliant digital identity and KYC systems — agents are simply a new class of actor that needs the same rigor.

Build versus buy: when to adopt a vendor protocol and when to build

Here’s the honest version of the decision. Adopt a vendor’s orchestration protocol when most of your agentic work already lives inside that vendor’s ecosystem, when their protocol is offered as part of the platform rather than as a costly add-on, and when their connector coverage spans the third-party tools you actually use — Atlassian cited more than 80 out-of-the-box connectors and a Teamwork Graph linking more than 250 billion objects. If 87% of your relevant work happens in one suite, fighting that gravity is wasted money.

Build a custom identity, permissions, and audit layer when your agents span several vendors that each want to be the hub, when lock-in to one ecosystem would raise your switching cost to an unacceptable level, or when compliance obligations demand controls no single vendor fully satisfies. The middle path — and usually the right one — is a thin custom orchestration layer that owns identity and audit, while delegating execution to vendor protocols underneath. That keeps you portable. For most enterprises this is an integration and API problem more than a model problem, and a short, even-handed read on the tradeoffs lives in our custom AI versus off-the-shelf SaaS comparison.

When should you not build? If you’re pre-pilot, if your agent usage is confined to one tool, or if you lack the engineering capacity to maintain an audit layer under compliance scrutiny, building is premature. Adopt the vendor layer, learn where it chafes, and build only the seams that lock you in.

Scoring your current agent architecture

A quick self-assessment beats a vendor demo. Score your current setup on five questions, one point each. Can you list every agent operating in your environment and name a human owner for each? Does each agent have an identity separate from the user it acts for? Are agent permissions scoped, or do they inherit full user rights? Could you produce an audit trail of agent actions for a regulator tomorrow? If your top vendor vanished, could your agents keep working across other tools?

Four or five points means you can safely lean into a vendor protocol. Two or three means build the identity and audit layer first, then adopt. Zero or one means stop adding agents until the basics exist — more sprawl only raises the cleanup bill.

What good orchestration actually returns

The ROI signals that matter are not the vendor’s revenue metrics. They’re yours: reduced time to safely deploy a new agent, fewer permission-related incidents, and audit evidence produced in hours instead of weeks. Atlassian noted that deep Rovo adopters grow ARR more than twice as fast as light users — a vendor metric, useful mainly as a signal that depth of adoption tracks with value. For your own business, watch whether orchestration lets you add the second and third agent without a linear increase in governance overhead. That flattening curve is the whole point. We expect the next 18 months to separate enterprises that built a portable identity and audit layer from those that let one vendor own their orchestration — and the second group will pay a painful switching cost to escape it.

If you want a vendor-neutral read on your own setup, book a free AI agent architecture consultation and we’ll score it against this framework.

FAQ

Q: What is enterprise AI agent orchestration? A: It’s the governing layer that manages how autonomous AI agents identify themselves, what actions they’re permitted to take, and how their behavior is audited across your tools. Strong orchestration keeps agents interoperable and traceable rather than siloed inside individual applications or locked to a single vendor.

Q: Should we adopt a vendor’s agent protocol or build our own layer? A: Adopt a vendor protocol when most agentic work already lives in that ecosystem, the protocol ships with the platform, and connector coverage matches your tools. Build a custom identity and audit layer when agents span multiple competing vendors or when lock-in and compliance risk are unacceptable. A thin custom layer over vendor execution is often the safest middle ground.

Q: What’s the difference between a control tower and a subway station model? A: In the control tower model, one vendor owns orchestration end to end and routes every agent through its hub. In the subway station model — Atlassian’s framing — a connected point provides shared context, identity, and audit without any single vendor controlling orchestration, keeping agents portable across tools.

Key Takeaways

• Treat agent identity, permissions, and audit as infrastructure you own — not as features bundled inside whichever tool you deployed first.
• Score your architecture on the five-question test before buying anything; a score below three means fix the foundation before adding more agents.
• Be skeptical when every vendor uses the same “identity, permissions, audit” vocabulary — confirm what each one actually means for your workflows.
• A thin custom orchestration layer over vendor execution protocols preserves portability and caps your switching cost.