Wood Mackenzie built the agent platform APEX on Amazon Bedrock AgentCore
Wood Mackenzie built the shared platform APEX on Amazon Bedrock AgentCore to standardize AI agent infrastructure (identity, security, observability, state management). According to the company, 88 % of internal agent prototypes never reach production; the platform is used by the applications Woody, Lens AI…
Wood Mackenzie built the shared platform APEX (Agentic Platform for Energy eXperience) on Amazon Bedrock AgentCore to standardize infrastructure for deploying AI agents into production across the company. The platform handles shared layers that each team would otherwise have to build separately — identity, security, observability and state management — and is both model-agnostic and framework-agnostic. APEX is currently used by three applications: the internal tool Woody, Lens AI and ST Trading App; without the shared platform, each would build its own infrastructure stack separately.
According to Wood Mackenzie, 88 percent of internal AI agent prototypes (proof-of-concept) never reach production deployment. The source cites industry surveys from early 2026, according to which AI experimentation in enterprises is almost universal, while only roughly a quarter of organizations have deployed agents into production in even one function. According to Forrester, agent failures are caused primarily by ambiguity, poor coordination and unpredictable system behavior, rather than conventional programming errors; the most commonly cited single obstacle is evaluation and observability — teams cannot reliably predict in advance when an unpredictable (non-deterministic) agent will make a mistake, and standard regression tests will not catch it.
When selecting the technology, Wood Mackenzie compared Amazon Bedrock AgentCore against self-hosted alternatives such as LangChain, CrewAI and n8n on hosting, pricing model, model independence, scalability, governance and enterprise support. According to the company, AgentCore supports any open-source framework (including Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK, OpenAI Agents SDK) as well as the MCP and A2A protocols, and offers a consumption-based pricing model billed by active CPU and memory usage per second — without charging for time spent waiting for a response from a model or tool, which, according to the company, accounts for 30 to 70 percent of the total time in agent tasks.
The description of the APEX architecture (frontend, backend and infrastructure-as-code layers) in the source article continues with further technical details that are not available in the accessible text. You can find the details in the source article.
Why it matters
The case shows a concrete solution to a problem faced by a large proportion of enterprises building AI agents: the transition from prototype to production is hindered primarily by a lack of standardized infrastructure (identity, security, observability) and an inability to reliably evaluate the behavior of unpredictable (non-deterministic) systems, rather than by model quality. For teams planning their own agent projects, the relevant choice is between building infrastructure separately for each team and deploying a shared, model-agnostic platform with consumption-based billing that, according to Wood Mackenzie, does not charge for time spent waiting for a response from a model or tool — which accounts for a large share of runtime in agent tasks.
Two audiences, two different impacts
What this means
For individuals
For developers of agent applications, the case study shows that the main obstacle to production deployment is often a lack of evaluation and observability for non-deterministic systems, rather than the quality of the model itself.
For a business
Companies running multiple agent applications can reduce duplicate infrastructure (identity, security, observability, state management) by consolidating it on a shared platform; Wood Mackenzie replaced three separate stacks with a single solution that charges only for compute actually used.
DevelopmentCheck the original
Event sources
only one source so far · 1 publisher, 0 independent. We count feeds from the same owner only once.