A shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCore

來源原標題

A shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCore

作者

Shridhar Navanageri

原始標籤

Amazon Bedrock AgentCore · Customer Solutions

原始連結

https://aws.amazon.com/blogs/machine-learning/a-shared-agentic-platform-for-wood-mackenzie-on-amazon-bedrock-agentcore/

摘要原文

Building a working agentic prototype takes an afternoon. Getting it to production is where the work explodes. The moment an agent has to serve more than one user, a new layer of engineering appears and it’s critical to tell whether the agent is doing the right thing on real traffic. Concurrency, session isolation, identity, persistent state, scaling, and guardrails are all layers that most teams rebuild from scratch every time, even though a standardized platform for each agent is a more repeatable approach. The result is a wide gap between experimentation and production. Industry surveys through early 2026 put enterprise AI experimentation near universal while only about a quarter of organizations have scaled agents into production in even one function. Internally at Wood Mackenzie, we have found that 88 percent of AI proofs-of-concept never reach widescale deployment. The reasons are consistent across analysts, and they are mostly architectural rather than model-related. Forrester attributes agent failures largely to ambiguity, miscoordination, and unpredictable system behavior rather than ordinary bugs. The most-named single blocker is evaluation and observability: teams cannot reliably tell ahead of time when a non-deterministic agent will be wrong, and standard regression tests do not catch it. Governance and identity follow close behind, with a large share of executives reporting they could not immediately shut down a misbehaving agent. Underneath all of it is duplicated infrastructure: each team re-implements authentication, guardrails, memory, and tracing, and hardcodes a model so that swapping providers means rewriting code. This is the problem a shared agentic platform solves. Instead of every team rebuilding the same foundation, one runtime handles orchestration, safety, observability, identity, and connectivity, and teams spend their effort on the business logic that differentiates their product. In this post we show how we built APEX (Agentic Platform for Energy eXperience), a shared platform so every team can ship agents without reinventing infrastructure. APEX is built on Amazon Bedrock AgentCore , a platform to build, connect, and optimize agents at scale, with any framework or model. We cover why we selected AgentCore over self-hosted solutions, how the architecture is composed, how APEX Studio gives teams a single control plane to operate it, how we bring interactive AI into real applications for both internal users like Woody and external consumers like Lens. We will also dive into how the same infrastructure serves both under identity-aware entitlements, how we close the evaluation and governance gaps that stall most agent programs, and where the platform is heading as multi-agent systems become the default. Before APEX, three applications were each on their way to building their own agent stack: Woody, Lens AI, and the ST Trading App. Left alone, each would have stood up its own runtime, wired its own identity, bolted on its own observability, and hardcoded its own model. We would have paid the same infrastructure tax three times and ended up with three stacks that could not share memory, tools, or evaluation. AgentCore resolves this problem by providing a platform capable of meeting the needs of an enterprise scale agentic deployment. We evaluated AgentCore against the requirements of a production platform: hosting model, cost model, whether it is model agnostic, scalability, governance, and enterprise support. AgentCore provides us a managed platform rather than a library we would need to operate ourselves. It works with any open source framework, including Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK, OpenAI Agents SDK, and with any model whether or not it runs on Amazon Bedrock. It supports both the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol. That meant we didn’t need to choose between open source flexibility and AWS service security. This allowed us to standardize the platform layer while leaving each team free to pick its own framework and model. Five capabilities decided it for us: AgentCore uses consumption-based pricing with no upfront commitments or minimum fees. Each service is billed independently, so a team can adopt a single capability such as AgentCore memory, a capability of Amazon Bedrock AgentCore, without migrating its entire agent. Runtime billing is based on active CPU and memory consumption calculated per second, and CPU charges don’t accrue during I/O wait. This matters for agentic workloads, which typically spend 30–70 percent of their time waiting on model responses, tool calls, or database queries. With pre-allocated compute you would pay for that idle time. With AgentCore, you do not. APEX is organized in layers, shown in Figure 1. At the top, end users interact with three applications: Woody, Lens AI, and the ST Trading App. Those applications talk to the APEX frontend, which exposes a framework so product teams can drop agentic capabilities into a user interface without rebuilding the connection to the backend each time. The APEX backend is where AgentCore does the work. Two infrastructure tracks sit alongside the backend. The WM infrastructure as code (IaC) Framework uses the AWS Cloud Development Kit (AWS CDK) and GitHub to provision and version platform resources, with guardrails defined in code. The MCP layer connects the platform to third-party and external access, including AWS Marketplace and partner systems, over a standard protocol rather than bespoke integrations. Users reach three applications through the APEX frontend SDK. The APEX backend runs on AgentCore (Runtime, Identity, Gateway, Memory, Observability) with an Orchestrator, a vector database for retrieval, model access through the Amazon Bedrock model catalog, and Amazon Bedrock Guardrails. The WM IaC Framework provisions resources through AWS CDK and GitHub, and the MCP layer connects external systems. Figure 1: APEX reference architecture Inside the backend, a request flows through these components. User Authentication and AgentCore Identity establish who is calling and what they are entitled to do. Identity and entitlements are woven into every agent invocation rather than checked once at the edge, so an agent acting on a user’s behalf carries that user’s permissions through every downstream tool and data call. Federation to your identity provider of choice is also important. We use Okta as our source of truth. The Orchestrator routes the request and consults the Woodmac Agent Registry, a single place to discover, share, and reuse agents, tools, and skills across the organization with built-in governance and approval workflows. This is how one team’s agent becomes available to another without copying code. AgentCore runtime hosts the agent code in a serverless, session-isolated environment. Inside the runtime we run AI Agents Studio (built on Amazon Quick with Strands Agents, LangGraph, CrewAI, n8n, Vertex, and OpenAI), so each team keeps its preferred framework. The runtime invokes models through the Amazon Bedrock model catalog, which is where model agnosticism becomes concrete: the agent points at a model by name and we swap providers without rewriting the agent. Tools are exposed to the agent as composable building blocks. The architecture shows how Wood Mackenzie uses a Code Interpreter tool for secure code execution and an Amazon Nova Act web tool for browser actions. These tools are reached through AgentCore Gateway , a capability of Amazon Bedrock AgentCore, which turns APIs, AWS Lambda functions, and existing MCP servers into agent-compatible tools and provides a single secure endpoint for discovery and invocation. The Gateway pulls from a Tools Repository for discovery and invocation, and supports IAM, OAuth 2.1, and API key authentication.