Part 7 of 9 — Technology Platform
When I asked Aurelia's platform team to inventory their AI stack, they came back with 17 tools, 7 frameworks, 4 vector databases, and 3 model gateways. They said it like it was good news. They were drowning.
This is the most common technology architecture I see in the early phases of agentic transformation. Each business unit chose its own stack. Each pilot bolted on whatever the team needed at the moment. The platform team, if there is one, is two or three quarters behind the pilots. The bill of materials looks like a shopping list, not an architecture. And in a conglomerate like Aurelia — Studios, Streaming, Networks, Parks, Voyages, Skies, Live, Consumer, Games — the sprawl multiplies fast.
This article is about the four capabilities that make up the Technology Platform focus area, and the consolidation work Aurelia did to stop paying the tax of tool sprawl and start moving at platform speed.
The Four Capabilities of Technology Platform
Four heavy-hitters:
Multi-Agent Architecture — the architecture supporting multi-agent reasoning, decision-making, and coordination, including agent-to-agent (A2A) patterns
AI Model Management — the lifecycle management of AI models: development, registry, deployment, monitoring, and version control
AI Platform — the underlying infrastructure, technology stack, people, and processes supporting agent development and deployment at scale
Agent Connectivity — the agents' ability to access data and take actions across the enterprise's systems of record, of engagement, and of automation
These are the things that determine whether your second hundred agents cost more or less than your first ten. If the marginal cost of building agent N+1 is roughly the same as agent 1, you have a platform problem. If the marginal cost is meaningfully lower, you have a platform.
What Level 1 Looks Like
Low-maturity Technology Platform has tells:
Each pilot chose its own framework, vector database, and orchestration approach — the Studios pilot picked one stack, the Parks pilot picked a different one, the Skies pilot picked a third
There is no shared model registry; each team tracks their own model versions in their own way
Multi-agent coordination is "hope and a Slack channel"
Connectivity to enterprise systems is point-to-point: every agent integrates with each system independently, with separate auth, separate permissioning, separate failure handling. Aurelia had agents independently integrating with the same property management system seven different times.
The platform team is reactive, building components after the pilots have decided they need them
"AI cost" is something the CFO has questions about and nobody has clean answers
Migrating an existing agent to a different LLM provider requires a small project
If you have more than three vector databases or more than two agent frameworks in active use, you are paying the tool sprawl tax whether you've measured it or not.
Aurelia's Starting Point
The 17-tools-7-frameworks-4-vector-DBs inventory was real. The financial impact was also real: Aurelia was spending roughly $34M annually on AI infrastructure and tooling, with about 40% of that estimated to be duplicative — different teams paying for overlapping capabilities, different vendors providing essentially the same service to different parts of the company. The Studios division had its own observability stack. The Parks division had a different one. Streaming had a third.
The cost was the easier problem. The harder problem was that build cycles were slow. Every new agent needed integration work that had effectively already been done — but for a different framework, with different conventions, by a different team. The marginal agent was almost as expensive as the first one.
The CDO and CTO together made the case to the executive committee for a platform consolidation, and got 9 months of explicit air cover to do work that, in the short term, would feel like a slowdown.
The Big Rocks Aurelia Had to Move
Rock 1: The migration off legacy tooling
Migration is always painful. The team that built on framework A has emotional and intellectual investment in framework A. They have learned its quirks. They have a body of code that works. Asking them to migrate to framework B is asking them to take real productivity loss in the short term in exchange for a long-term gain that may feel theoretical.
Aurelia's approach was honest about the cost. They committed to a 12-month migration window. They funded the engineering work centrally so the embedded pods didn't have to choose between migration and feature delivery. They migrated the highest-value agents first to demonstrate the platform's value, then migrated everything else on a stack-rank basis. Six agents were retired during the process — not migrated, just turned off — because the migration analysis revealed they were not worth the cost.
The 12-month window stretched to 14. That was the most accurate part of the plan.
Rock 2: The platform team versus embedded teams tension
Once the platform exists, the next problem is governance. Who decides what goes into the platform? Who decides what stays in the embedded pods? Who pays for shared infrastructure? Who is on the hook when a platform component breaks and ripples across 60 agents?
Aurelia's answer was a clear separation:
Platform team owns: the model gateway, the agent framework, the orchestration runtime, the eval infrastructure, the model registry, the shared connectivity layer, the observability stack
Embedded pods own: the agent prompts, the agent business logic, the BU-specific data sources, the BU-specific tool integrations, the change management and adoption work
Shared accountability: production reliability, with the platform team responsible for the platform components and the embedded pod responsible for the agent built on top
This is conceptually simple and politically hard. The hard part was funding. Aurelia moved to a chargeback model: embedded pods pay the platform team, in real budget, for usage. This forced both sides to be honest about value: the platform had to be good enough that the embedded pods would pay for it; the embedded pods had to use the platform thoughtfully because every call was a real expense.
Rock 3: Multi-agent orchestration
This is the newest and least mature capability of the four. Agent-to-agent coordination was, in 2024 and 2025, mostly held together with prompts and prayer. The discipline is starting to mature, but the patterns are still being written.
This was a particularly important capability for Aurelia because of the cross-BU nature of many guest journeys. A single guest might book a Voyages cruise that included two days at the Pacifica resort and a return flight on Aurelia Skies. The handoff across those three BUs — and the agents inside them — needed to feel seamless to the guest. That required orchestration patterns the platform team had to build deliberately.
Aurelia took a measured approach: they built one orchestration layer, supported a small set of well-defined coordination patterns (sequential delegation, parallel fan-out with aggregation, supervisor-worker hierarchies, and peer-to-peer negotiation for specific cross-BU cases), and refused to support patterns that were not in the catalog.
This was an unpopular constraint at first. By month 12, it was a treasured one. Every team that had been forced into the catalog patterns was building faster than the teams that had grandfathered themselves out of it.
Rock 4: Connectivity as a shared layer, not a per-agent project
The biggest hidden cost in low-maturity platforms is connectivity. Every agent integrating independently with every system of record means redundant auth, redundant permissioning, redundant error handling, and redundant trust assumptions. It is also a security nightmare.
Aurelia built a shared connectivity layer that handled: authentication, authorization, rate limiting, circuit breaking, retry, audit, and consistent error semantics across roughly 110 enterprise systems. The list reads like a tour of the company: the property management systems at the resorts, the central reservation system, the call center platform, the airline's PSS and crew rostering systems, the cruise line's port operations system, the studios' production scheduling and DAM systems, the broadcast traffic and ad sales systems, the streaming service's recommendation and CDN orchestration systems, the consumer products PIM and licensing systems, the financial systems of record, the workforce management systems.
Every agent at Aurelia accessed enterprise systems through this layer. Building the layer took 6 months. The payback was immediate: new agent connectivity work that previously took 4-8 weeks now took 4-8 days.
What "Leading" Looks Like
Eighteen months in, Aurelia's Technology Platform maturity looks like this:
One agent framework, one orchestration runtime, one model gateway, one model registry, one connectivity layer, one observability stack
A model registry with 31 actively governed models across providers, with deprecation calendars and migration playbooks for every model end-of-life
Multi-agent orchestration patterns are documented, tested, and supported; cross-BU agent journeys (Voyages → Pacifica → Skies, for example) work without bespoke integration each time
The connectivity layer covers about 110 enterprise systems; new system onboarding takes about 2 weeks instead of 2 quarters
AI infrastructure spend is down roughly 40% from peak even as the agent portfolio has grown 4x — from 14 agents to about 60
Average build time for a new agent — from kickoff to production — is 6-8 weeks; the comparable figure 18 months ago was 16-22 weeks
The shorthand is: the marginal cost of agent N+1 has dropped dramatically. That is the test of whether you have a platform. If your tenth agent costs as much as your first, the answer is no.
The RPI at the Other End
Platform maturity is the focus area where it is hardest to draw a clean line to Real People Impact, because the platform sits behind the agents that deliver the impact. But the line is real. Faster build cycles mean ideas reach front-line cast members and guests in weeks instead of quarters. Lower run costs mean agents can be deployed for use cases that wouldn't have justified the spend at higher cost. Better connectivity means agents can take real action in real systems instead of just answering questions and asking the cast member to do the work.
At Aurelia, the third major release of the Guest Concierge agent added integrations with the airline's seat selection system and the cruise line's stateroom upgrade waitlist. Those integrations had been on the roadmap for over a year but kept getting deprioritized because the per-agent integration cost was too high. After the connectivity layer went live, both integrations shipped in 11 days. Guests booking multi-BU itineraries stopped having to call separate help lines for each leg of their trip. That is roughly 14 minutes saved per multi-BU booking across about 1.4 million such bookings annually.
That is the platform RPI. Not faster builds. Faster useful things reaching real humans.
What to Do This Week
If you want to test where your Technology Platform maturity sits, ask your platform team three questions:
How many distinct agent frameworks, vector databases, and model gateways are in active production use across the company?
What is the median time, in weeks, from "approved use case" to "production deployment" for a new agent?
If we wanted to swap our primary LLM provider tomorrow, what would that cost in engineering effort and downtime?
The honest answers will tell you whether you have a platform or a portfolio of products that happen to be in the same building.
Next article: Data Foundation. The reason most agents hallucinate, and the work Aurelia did on roughly 14,000 spreadsheets, show binders, and tribal knowledge stores that the executives didn't want to fund.
This is Part 7 of a 9-part series on agentic enterprise maturity.