Build1 publisher3 min readPublished
Wood Mackenzie consolidates three in-flight agent stacks onto one managed runtime
The company says 88 percent of its AI proofs-of-concept never reach widescale deployment, and it blames the identity, session and evaluation layers each team was rebuilding, so APEX builds them once on Amazon Bedrock AgentCore.
The Engineer · Build desk
What happened
- Three Wood Mackenzie applications, Woody, Lens AI and the ST Trading App, were each on their way to standing up their own agent runtime, identity wiring, observability and hardcoded model.
- The company replaced that with APEX, a shared platform on Amazon Bedrock AgentCore where one runtime handles orchestration, safety, observability, identity and connectivity and teams write business logic.
- It argues the reasons are consistent across analysts and mostly architectural, citing Forrester on ambiguity, miscoordination and unpredictable system behaviour.
- AgentCore, the managed service underneath APEX, reached general availability in October 2025 and runs any framework or model, including models not hosted on Bedrock.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A product team joining APEX gives up its own runtime and inherits the platform team's orchestration, guardrails and tracing, so the platform team's backlog becomes three applications' backlog.
- exposure Folding identity into one runtime puts the stop control for a misbehaving agent in one place, and it also puts every team's agents behind a single misconfiguration there.
- decision Teams elsewhere face the same choice this pushed Wood Mackenzie to make: hardcode a model in each application, or fund a shared layer once so changing providers is a configuration change.
- contradiction The 88 percent supports the diagnosis that architecture kills agent projects; the case that shared infrastructure cures it rests on a post carried by the vendor whose service was chosen, and needs a deployment rate measured after APEX shipped.
APEX serves internal users through Woody and external customers through Lens on the same infrastructure, separated by identity-aware entitlements [20]. Identity and session isolation therefore sit in the platform layer. The post is blunt about the trigger: a new layer of engineering appears the moment an agent has to serve more than one user [3]. Concurrency, session isolation, identity, persistent state, scaling and guardrails are the layers it says most teams rebuild from scratch every time [2].
Duplication is where the account is most specific. Each team re-implements authentication, guardrails, memory and tracing, and hardcodes a model, so swapping providers means rewriting code [11]. AgentCore accepts any open source framework, including Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK and the OpenAI Agents SDK, and any model whether or not it runs on Amazon Bedrock [16]. It speaks both MCP and A2A [17]. Wood Mackenzie says that let it standardise the platform layer while leaving each team free to pick its own framework and model [26].
Choosing AgentCore trades operations for a dependency. It is a managed platform: no cluster to operate, with AWS handling scaling, patching and availability [15]. It reached general availability in October 2025 [18]. The post cites industry surveys through early 2026 [7]. The platform work therefore falls within a year of that GA [27]. The stated evaluation covered hosting model, cost model, model agnosticism, scalability, governance and enterprise support, and five capabilities decided it [14][22]. Six criteria and five deciding capabilities is the kind of list that gets written up after the decision, though the criteria are the ones I would use.
The 88 percent [5] is an internal finding, published on the AWS machine learning blog [23], and its complement is that about 12 percent of proofs-of-concept do reach widescale deployment [6]. The post does not define widescale deployment or say how many proofs-of-concept are in the count. For the figure to transfer, another company's bar for shipped would have to match Wood Mackenzie's, and its abandoned experiments would have to be counted the same way. The post puts the gap this way: "Building a working agentic prototype takes an afternoon. Getting it to production is where the work explodes." [4] Its wider comparison is near-universal experimentation against about a quarter of organisations having scaled agents into production in even one function [7], with Forrester named for attributing agent failures to ambiguity, miscoordination and unpredictable system behaviour [8].
Evaluation is the blocker named first: teams cannot reliably tell ahead of time when a non-deterministic agent will be wrong, and standard regression tests do not catch it [9]. A shared runtime helps there only if the evaluation harness is shared with it, and three separate stacks, by the post's own account, could not have shared memory, tools or evaluation [13].
What to watch
- A post-APEX deployment rate from Wood Mackenzie, measured against the same bar as the 88 percent, would test whether the shared platform moved the number.
- Whether the ST Trading App and later teams actually ship on APEX or keep their own stacks.
- A published cost model for AgentCore at production concurrency, since cost model was one of the six evaluation criteria.