A shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCore
When a promising agent stalls in production it rarely fails loudly. It goes quiet: sessions time out, tool calls flake, and nobody can answer the simple question, “can we tell when it stopped working?” Wood Mackenzie frames that silence as a systemic problem, often the model is fine, but the surrounding architecture is not.
Why a shared platform matters
Wood Mackenzie built APEX (Agentic Platform for Energy eXperience) on Amazon Bedrock AgentCore to make a point: moving agents from prototype to production is mostly an architectural problem, concurrency, identity, guardrails, observability, scaling, persistent state, rather than a pure model-capability problem. Standardizing a single platform layer (runtime, gateway, identity, memory, observability, evaluation) lets product teams focus on domain logic instead of rebuilding the same plumbing.
Wood Mackenzie cites two headline signals: “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, ” and its own telemetry shows “88 percent of AI proofs-of-concept never reach widescale deployment.” Forrester, the team notes, has also observed that agent failures tend to stem from “ambiguity, miscoordination, and unpredictable system behavior” rather than ordinary bugs, with evaluation and observability named as the single biggest blocker.
“Most agent programs stall not because the model is inadequate but because the infrastructure around it is missing: no shared runtime, no consistent evaluation, no governed identity, and duplicated plumbing rebuilt for every use case.”, Wood Mackenzie
Why AgentCore?
Wood Mackenzie chose Amazon Bedrock AgentCore for pragmatic reasons: it is offered as AWS-managed infrastructure, is model-agnostic at the runtime layer, supports automatic scaling, integrates guardrails and identity natively, and carries AWS enterprise support. AgentCore reached general availability (GA) in October 2025.
Key AgentCore capabilities Wood Mackenzie relies on:
- Runtime, session-isolated, serverless execution with session windows up to 8 hours (as described in AgentCore documentation and the Wood Mackenzie deployment).
- Gateway, a single secure endpoint that turns APIs, Lambda functions, and MCP servers into agent-compatible tools.
- Identity, integration with IAM, VPC isolation and enterprise IdPs so agents act under user or agent entitlements.
- Memory, short- and long-term context stores that can be shared across sessions and agents.
- Observability, OpenTelemetry-compatible telemetry exported to Amazon CloudWatch covering session count, latency, duration, token usage, and error rates.
- Evaluations, built-in evaluators for helpfulness, tool selection and accuracy plus support for custom model-based scoring.
AgentCore’s model catalog is presented as model-agnostic: example models reachable include Claude, GPT-4.1, Amazon Nova, Mistral and Llama. It also supports the Model Context Protocol (MCP), a tool/agent interoperability spec, and the Agent-to-Agent (A2A) protocol for agent collaboration.
How APEX is put together
APEX is layered. The frontend uses streaming transports and a declarative UI specification. The backend runs on AgentCore’s runtime and gateway. CI/CD and infrastructure-as-code live in GitHub and AWS CDK, and a gateway implements a hub-and-spoke integration pattern so internal products don’t build N×M point-to-point connectors.
Notable design elements:
- Hub-and-spoke Gateway, a single AgentCore Gateway speaks MCP to fan out to internal data services (Lens Direct, Short Term Trading, Digital Content, P&R Dataset). That centralization enforces guardrails, identity checks and observability once instead of per-team.
- APEX Studio (control plane), a developer UX offering “Golden Path” templates (starter patterns to accelerate best-practice adoption), previewing agents, automated tests and one-click deployment. Studio also supports “vibe coding” (natural-language authoring integrated into the development lifecycle) to speed iteration while keeping tests and review in the loop.
- Frontend protocols, AG-UI (a bi-directional, event-driven transport for streaming tokens, tool calls and state updates) and A2UI (a declarative generative-UI specification: JSON blueprints rendered by a trusted widget catalog). CopilotKit is a launch partner for A2UI components.
- Framework interoperability, examples use Strands agents (stateful agent framework), but the platform integrates with LangChain, LangGraph, LlamaIndex, CrewAI, Google ADK, OpenAI Agents SDK, Vertex, n8n and others.
- Identity federation, Wood Mackenzie uses Okta as the identity source-of-truth, federated into AgentCore Identity so actions are auditable and least-privilege enforced per invocation.
Observability, evaluation and the practical economics of waiting
Agentic workloads behave differently from traditional web workloads: they spend appreciable wall-clock time waiting on model responses, tool calls and database queries. Wood Mackenzie reports that agentic workloads typically spend “30-70 percent” of their time waiting on those external operations. That I/O-heavy profile changes both cost and design decisions.
AgentCore’s billing is consumption-based: per-second active CPU and memory charges. The platform documentation says CPU charges don’t accrue during I/O wait. For I/O-heavy, long-running agent sessions that can be material. Teams should validate the billing semantics against their expected patterns and request details from their cloud contact.
Observability and evaluation are table stakes. AgentCore emits OpenTelemetry-compatible traces and metrics to CloudWatch (session counts, latency, duration, token usage, error rates). Pair those signals with Evaluations (quality scorers for helpfulness, tool selection, accuracy, and custom scores) and you get ways to detect degradations on real traffic and trigger remediation, shadowing traffic, rolling back model changes, or escalating to humans.
“does it work”, and the harder question: “can we tell when it stops working.”, Wood Mackenzie
Examples in the wild
Wood Mackenzie describes two practical patterns that APEX supports:
- Embedded conversational assistants, agents surface answers, interactive Vega-Lite charts and tool-driven actions into product UIs using AG-UI and A2UI, while the gateway enforces access and provenance for any data called.
- Operational agents, agents that coordinate model training, GitHub branch actions and data pipelines under guarded identities, with audit trails and automated evaluations running on real traffic.
The platform uses Bedrock Knowledge Bases for Retrieval-Augmented Generation (RAG) to ground model responses in enterprise content, and exposes internal services as MCP tools so agents call the same governed APIs as other clients.
Designing for multi-agent futures
APEX is built to evolve beyond single-agent assistants. With MCP for consistent tool interfaces and A2A protocols for discovery and delegation, AgentCore supports multi-agent orchestrations where agents can discover, delegate and collaborate across bounded domains while preserving entitlements and audit logs. A2A governance has moved into broader community stewardship (the Linux Foundation is referenced in the platform notes), which matters when agents exchange responsibilities across organizational boundaries.
Tradeoffs and risks
- Managed versus control, a managed runtime eliminates a lot of operational toil, but it shifts some debugging and incident mechanics to the provider model. Teams lose some low-level control and must rely on provider SLAs and support.
- Model-agnostic in theory, pragmatic in practice, runtime-level model-agnosticism reduces code churn, but latency, tokenization differences, streaming behavior and provider SLAs still affect user experience and TCO. Benchmark models before a live swap.
- Billing semantics, consumption pricing and “no CPU accrual during I/O wait” can lower cost for I/O-heavy workflows, but billing definitions matter. Confirm exact measurement windows and billing rules with the provider.
- Cross-organization A2A governance, technical support for A2A exists, but legal, contractual and liability questions remain when agents act across companies. Policies, audit trails and clear entitlements are essential.
- Migration and exit, components like RAG knowledge bases, custom tools and connectors create friction when moving platforms. A model-agnostic runtime helps, but a migration plan for data and connectors is still necessary.
Practical checklist for platform and product leaders
- Map identity: federate your corporate IdP (e.g., Okta) into runtime entitlements and enforce least-privilege per invocation.
- Centralize guardrails: convert policy into enforceable rules (Cedar is an example used in AgentCore) rather than advisory documents.
- Instrument end-to-end: correlate traces, metrics and token usage with session IDs across model, tool and DB calls (OpenTelemetry is a practical standard).
- Define evaluation thresholds: decide which Evaluations scores trigger alerts, traffic shadowing or rollback.
- Template the Golden Path: provide starter agents (summarizers, RAG assistants, tool-based workflows) so teams don’t start from an empty repo.
- Model-agnostic, but benchmarked: keep code model-agnostic at the API layer, but benchmark latency, reliability and cost for candidate models before production swaps.
Questions executives will actually ask (and short answers)
- Will a shared platform speed productionization?
Yes. Standardizing runtime, gateway, identity, memory, observability and evaluation reduces duplicated work and removes many common architectural blockers. - Does AgentCore remove vendor lock-in?
It reduces code-level lock-in by supporting multiple models at runtime, but operational differences (latency, pricing, SLAs, feature gaps) still require planning when you swap providers. - How do we catch agent failures?
Instrument sessions end-to-end, run Evaluations on live traffic, and set automated thresholds that alert, shadow traffic, or rollback changes; observability tied to evaluations is the best defense against silent failures. - Is this expensive to run?
Agent workloads are I/O-heavy, Wood Mackenzie reports 30-70 percent wait time, so a consumption-based model that avoids charging CPU during I/O can be cost-efficient. Still, run a pilot to model your own usage and costs. - Can agents safely call internal systems?
Yes, if you enforce per-invocation identity, least-privilege access and policy guardrails at the gateway; platform-level enforcement is crucial for auditability and compliance.
Three practical next steps
- Run a focused 6-8 week pilot: pick one RAG or tool-heavy workflow, federate identity, instrument traces and evaluations, and measure time-to-production, cost and failure modes.
- Define SLOs and evaluation thresholds: decide what evaluation scores and telemetry trends require human review, automated rollback or partial traffic routing.
- Ask the vendor three questions: how is CPU billed during long waits, what models are available in your region, and what incident/rollback support is included under enterprise SLAs?
Wood Mackenzie’s APEX on Amazon Bedrock AgentCore reframes the central challenge of agentization: the hard part isn’t only the model’s cleverness, it’s the messy, cross-cutting engineering around it. Invest in a single, governed, observable layer and models become components in a resilient system rather than the whole system.