Wood Mackenzie Builds Shared Agent Platform on Amazon Bedrock AgentCore

Wood Mackenzie has built a shared agentic AI platform called APEX on Amazon Bedrock AgentCore, giving teams a common foundation for deploying production agents instead of rebuilding runtimes, identity controls, observability and safeguards for each application.

The company’s account, published by AWS, describes APEX supporting three applications: Woody, Lens AI and the ST Trading App. The architecture is designed to let product teams choose different agent frameworks and models while relying on a standardized operational layer. That addresses a central problem in enterprise AI: prototypes can be built quickly, but operating non-deterministic systems safely across users, tools and data is substantially harder.

The same AWS blog cluster also documents Abnormal AI using AgentCore Code Interpreter in its email-security systems. Together, the examples show AWS positioning AgentCore not only as a development service, but as infrastructure for agents that need isolation, policy enforcement and controlled access to computation in live workflows.

A shared foundation for Wood Mackenzie’s agents

Before APEX, Wood Mackenzie says Woody, Lens AI and the ST Trading App were each developing their own agent stacks. That approach would have required separate implementations of authentication, scaling, tracing, model access and guardrails. It would also have made it harder to share tools, memory and evaluation practices between teams.

APEX centralizes those capabilities. Its backend uses Amazon Bedrock AgentCore Runtime, Identity, Gateway, Memory and Observability, alongside an orchestrator, retrieval infrastructure, model access through the Amazon Bedrock model catalog and Amazon Bedrock Guardrails. A frontend software development kit connects the platform to user-facing applications.

The design does not require every team to use the same agent framework. Wood Mackenzie says its environment can support Strands Agents, LangGraph, CrewAI, n8n, Vertex and OpenAI’s agent tooling. AgentCore also supports the Model Context Protocol, or MCP, and the Agent-to-Agent protocol, allowing external systems and agents to connect through standardized interfaces rather than one-off integrations.

That flexibility is a significant part of the platform’s appeal. According to Wood Mackenzie, teams can change models without rewriting application logic, use one model for planning and another for execution, or compare price and performance across providers. The company lists Claude, GPT-4.1, Amazon Nova, Mistral and Llama as accessible through the platform, although the post does not provide independent measurements of model quality or switching costs.

Identity and operations move into the platform layer

APEX treats authorization as a property of each agent invocation rather than a check performed only when a user enters an application. Wood Mackenzie says AgentCore Identity carries a user’s permissions through downstream tools and data calls, allowing agents to act on a user’s behalf or under separately defined access controls. The company uses Okta as its identity-provider source of truth.

The platform also includes a Woodmac Agent Registry, where teams can discover and reuse agents, tools and skills subject to governance and approval workflows. That registry is intended to prevent teams from copying code when an existing capability could be shared.

AWS describes AgentCore Runtime as a serverless, session-isolated environment that can scale from zero to thousands of concurrent invocations, with execution windows of up to eight hours. AWS also says AgentCore services support capabilities including Amazon Virtual Private Cloud, AWS PrivateLink, CloudFormation and resource tagging following general availability in October 2025.

For cost management, the service uses consumption-based pricing with no stated upfront commitment or minimum fee. AWS says runtime billing is based on active CPU and memory consumption per second, with CPU charges excluded during input/output waits. The company notes that agent workflows may spend 30% to 70% of their time waiting for model responses, tools or databases, making this billing model relevant to workloads that would otherwise leave provisioned compute idle.

Evidence is detailed but vendor-controlled

The strongest claims in the story come from AWS and Wood Mackenzie, not independent audits. Wood Mackenzie reports internally that 88% of its AI proofs of concept do not reach wide deployment. The post also cites industry surveys and Forrester research to argue that evaluation, observability, governance and identity are major barriers to scaling agents, but it does not provide enough source detail in the article to independently assess those broader statistics.

The architecture itself is described in practical terms, including the request path from authentication through orchestration, runtime, model access and tool calls. However, the post does not disclose APEX’s production traffic, agent count, latency, error rates, operating costs or measurable business outcomes. Buyers should therefore view the account as an implementation reference and vendor-backed case study, rather than proof that AgentCore will produce the same results in another enterprise.

The Abnormal AI example provides a separate scale claim. AWS says Abnormal AI uses AgentCore Code Interpreter for agents involved in real-time email threat detection across billions of messages, while the broader detection system applies progressively more expensive analysis only to harder cases. AWS also reports that more than 25% of the Fortune 500 use Abnormal AI, and that 80% of the company’s code changes involve an agent in some way. Those are company or vendor-reported figures, and the post does not offer independent verification.

Code Interpreter adds a different capability to the AgentCore story. It provides ephemeral MicroVM sandboxes where agents can run Python or Node.js code, process files, perform calculations, create outputs and verify generated work. AWS says sessions can last from 15 minutes to eight hours, support public networking or VPC mode, and provide logs through CloudWatch and CloudTrail. Abnormal AI’s use case illustrates why agents may need a controlled execution environment rather than relying on language-model reasoning alone.

What the platform means for builders and enterprises

For AI builders, the main change is a shift in where engineering effort is spent. Teams can concentrate on domain workflows, retrieval quality, tool design and evaluation while a shared platform handles recurring infrastructure concerns. That can shorten the path from a successful demo to a service that supports multiple users and concurrent sessions.

The trade-off is architectural dependence on a central platform team. A shared registry, common policy layer and standardized observability can reduce duplication, but they can also become bottlenecks if onboarding, approvals or framework support are slow. Wood Mackenzie’s decision to preserve framework and model choice reduces that risk, but it does not eliminate the need for careful interface design and platform governance.

For enterprises, identity propagation and session isolation are more consequential than a long list of supported models. An agent that can call internal tools needs permissions that remain understandable and revocable throughout a workflow. AgentCore Identity, Gateway policies and Cedar-based rules are intended to address that requirement, but organizations will still need to test policy behavior under unusual prompts, chained tool calls and partial failures.

The Abnormal AI deployment also reinforces a tiered-cost model for agent systems. Lightweight rules and classifiers can handle high-volume cases, while more expensive agents and code execution are reserved for uncertain or complex cases. That pattern may be more practical than sending every task to a large model, particularly where latency and per-operation cost matter.

What to watch next

The next meaningful signals will be operational rather than promotional. Wood Mackenzie’s APEX would be more assessable with published data on adoption across its applications, agent failure rates, evaluation coverage, latency, policy violations and cost per workflow.

Builders should also watch whether AgentCore’s framework and model agnosticism remains practical as teams move from isolated experiments to shared tools and multi-agent workflows. Support for MCP and Agent-to-Agent connections could expand reuse, but it may also increase the number of trust boundaries that platform teams must monitor.

For enterprise buyers, the important follow-ups are independent customer references, clearer pricing under sustained concurrency, incident-response controls and evidence that agents can be disabled or rolled back without disrupting connected applications. Code Interpreter deployments warrant additional scrutiny around data retention, network access, package control and generated-code isolation.

Creati.ai perspective

Wood Mackenzie’s APEX is notable less because it introduces another agent application than because it treats the missing production layer as a reusable product. The company’s account suggests that enterprise teams are moving toward internal agent platforms that standardize identity, runtime behavior, observability and policy while leaving business teams room to choose their own models and frameworks.

The evidence remains vendor-controlled, and there is no disclosed performance or financial data to establish APEX as a proven template. Still, the architecture points to a practical direction for enterprise AI: agent adoption is likely to depend less on producing another impressive prototype and more on making permissions, evaluation, isolation and cost visible enough to operate every day.