Wood Mackenzie replaced three independent agent stacks with a single shared agentic platform—APEX—built on Amazon Bedrock AgentCore. The change consolidates runtime orchestration, identity handling, observability, and guardrails, letting teams focus on business logic instead of re‑implementing core infrastructure.
Why engineers should care
Surveys in early 2026 show most enterprises experiment with AI agents, yet only about a quarter have moved any agent into production. At Wood Mackenzie, 88 % of proofs‑of‑concept never scaled. The primary blockers cited are lack of reliable evaluation, insufficient observability, and fragmented governance. Each team previously rebuilt authentication, memory, tracing, and model integration, inflating operational cost and increasing the risk of inconsistent behavior across agents.
Architecture of the shared agentic platform
APEX leverages the managed AgentCore service, which provides:
- AWS‑managed compute that automatically scales without a dedicated cluster.
- Pay‑per‑use pricing, removing the need to provision capacity.
- Model‑agnostic support, allowing any open‑source framework (LangChain, LangGraph, LlamaIndex, CrewAI, etc.) and any model, even those not hosted on Bedrock.
- Native guardrails and policy enforcement via Amazon Bedrock Guardrails.
- Support for the Model Context Protocol (MCP) and Agent‑to‑Agent (A2A) protocol, enabling inter‑agent communication.
APEX Studio acts as a single control plane where teams register agents, configure identity‑aware entitlements, and define observability pipelines. Because the runtime is shared, memory and tool integrations can be reused across agents, and evaluation metrics are collected centrally.
Operational and security implications
From an operations perspective, the shift eliminates duplicated infrastructure: no separate authentication services, no per‑team scaling logic, and no custom tracing stacks. The managed service handles patching, availability, and scaling, reducing the SRE burden. The pay‑per‑use model aligns cost with actual traffic, simplifying budgeting.
Security benefits stem from the native guardrails and policy framework that enforce usage limits and content filters at the service level. Identity handling is centralized, allowing consistent entitlement checks for internal users (e.g., Woody) and external consumers (e.g., Lens). However, practitioners should still consider the separation between service‑level guardrails and any application‑level validation they may need, as the source does not describe application‑level authorization.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Teams should evaluate whether a managed agent runtime like AgentCore can replace custom stacks, especially if they are already using multiple frameworks or models. Consolidating around a shared platform can reduce duplicated effort in authentication, observability, and guardrails, and provide a clearer path from prototype to production. When adopting, verify that your chosen frameworks are compatible with the MCP or A2A protocols and that your evaluation pipeline can ingest the centralized observability data provided by the platform.
