About a year and a half ago, I wrote a LinkedIn post called "Gen AI adoption blues." The argument was that the conversation about generative AI was running ahead of what most organizations had actually done with it. Bedrock was just becoming familiar. Most enterprises were still trying to get past the resistance to change, the skill gaps, the integration friction, and the legacy data limitations that gate every wave of new technology. I leaned on the comparison to public cloud adoption in the 2010s on purpose: the pattern repeats, but the lessons are learnable.
That post still holds up. Those gating challenges have not vanished. But the surrounding landscape has changed so much that the leadership question is no longer "should we adopt generative AI?" It is two related but distinct portfolio questions, and most engineering organizations are not yet structured to answer them clearly.
This post is my attempt to make those questions explicit. The framework applies regardless of cloud or model provider — the same substrate-and-portfolio decisions show up on Google Cloud with Vertex AI, on Azure with Foundry, or in any multi-provider setup. I've grounded the examples in AWS and Anthropic because that's where some of the most consequential 2026 changes have landed; read those specifics as the worked example, not the limit of where the thinking applies.
What Changed (and What Didn't)
The headline shifts since late 2024:
The AWS-Anthropic partnership has become structural. In March 2026, the two companies signed an agreement under which Anthropic commits more than $100 billion to AWS over ten years, securing up to 5 gigawatts of Trainium and Graviton capacity. Amazon is investing an additional $5 billion in Anthropic now, with up to $20 billion more to follow, on top of the $8 billion previously committed. Project Rainier, the joint compute cluster, already runs on roughly half a million Trainium2 chips. (Anthropic announcement)
Claude is everywhere on AWS. More than 100,000 customers run Claude through Amazon Bedrock today. Claude is the only frontier model available across AWS, Google Cloud, and Microsoft Azure, but the depth on AWS — silicon, billing, governance, audit — is in a different category than the other two.
The number of ways to consume Claude on AWS went from one to three. Claude Platform on AWS reached general availability on May 11, 2026. It sits alongside Amazon Bedrock and the direct Anthropic API as a third, distinct substrate, with its own tradeoffs. (AWS announcement)
Amazon Bedrock AgentCore hardened into a real agentic platform. Runtime, Memory, Identity, Gateway, Code Interpreter, Browser Tool, and Observability are all managed services now. AgentCore CLI ships with infrastructure-as-code support (CDK today, Terraform coming) in 14 AWS regions at no additional charge.
Claude Code has crossed the credibility threshold. KPMG made Claude available to its 276,000+ employees through Digital Gateway. PwC is rolling out Claude Code and Cowork to its consulting workforce. The adoption pattern at this scale, in regulated professional services, signals that AI coding tools have moved out of pilot territory.
What hasn't changed: the cultural, skill, integration, and data-platform challenges from late 2024 are still the gating constraints. Technology has moved faster than most organizations' ability to absorb it. That gap is where leadership matters more than tooling.
Two Decisions Every Engineering Leader Now Faces
If you lead engineering or technology at a mid-market organization in 2026, two portfolio decisions sit on your desk that simply did not exist in late 2024:
1. The substrate decision. Which way of consuming Claude (or another foundation model) does each workload actually need?
2. The portfolio decision. Where does generative AI deliver real value in your business, in what order, and at what risk?
Neither has a single answer. Both reward thinking in lanes.
Decision 1: The Substrate Question — Three Doors to Claude on AWS
For AWS-centric organizations, there are now three legitimate ways to consume Claude:
Door 1: Amazon Bedrock. AWS-operated inference, data stays inside the AWS security boundary, AWS-native features like Guardrails and Knowledge Bases, multi-model, and tight integration with AgentCore for agentic workloads. Bedrock is the right choice when data residency, multi-model architecture, or AWS-managed governance is part of the security review.
Door 2: Claude Platform on AWS. Anthropic-operated, but billed through your AWS account, authenticated through AWS IAM, audited through CloudTrail. You get the native Claude API with day-one access to features like Managed Agents, Agent Skills, web search, code execution, and the Files API — capabilities that often arrive on Bedrock months later, if at all. The tradeoff: data is processed by Anthropic outside the AWS boundary, which is a real consideration for regulated workloads.
Door 3: The direct Anthropic API. A separate billing relationship and credentials, full feature parity, the lightest path for prototyping. The right choice when AWS procurement is not a requirement, or when speed of iteration outweighs consolidation.
Per-token pricing is the same across all three doors. The differences are in feature timing, data residency, billing format, and how the security and procurement reviews land.
The wrong move is to default the entire enterprise to one substrate because it's familiar. The right move is to pick per workload and write the decision down. An internal research assistant with non-sensitive data and a need for Managed Agents probably belongs on Claude Platform on AWS. A customer-facing support assistant that needs to keep PII inside the AWS boundary probably belongs on Bedrock. A two-week prototype probably belongs on the direct API. Revisit the decision quarterly as feature parity shifts.
Decision 2: The Portfolio Question — Three Lanes of Value
The substrate decision answers "where does Claude run?" The harder decision is "what should it do, in what order, with what guardrails?"
At NextLink Labs, we frame this conversation with clients in three lanes, each addressing where generative AI delivers value, on a different timeframe and with a different governance shape.
Lane 1: AI-assisted development inside your existing environment. Code review, refactoring, test generation, ERP integration work, even controls and robotics code in industrial environments. The return is concrete, the audience is technical, and the productivity compound is daily. The KPMG and PwC rollouts both live in this lane. This is where engineering leadership earns the right to talk credibly about AI in any other part of the business.
Lane 2: Operational efficiency. Recurring, low-judgment work — generating reports, exporting and reconciling data, triaging tickets, preparing compliance documentation. The value math is straightforward: hours saved per week, multiplied by people doing the work, minus the cost of the tooling and oversight. This lane runs well on Bedrock because the workloads are largely inference and the data often needs to stay inside the AWS boundary.
Lane 3: AI-enabled products. Generative AI inside what you sell, not just how you build it. The business and compliance readiness required to ship AI in a customer-facing product is substantially higher than for internal use cases. This is the lane where AgentCore becomes most relevant, because production agents touching customer data need Identity, Observability, and Guardrails managed by the platform rather than bolted on at deploy time.
A Grounded Example
Picture a mid-market industrial manufacturer with a few hundred employees, a long-running ERP customization backlog, a QA team buried in compliance reports, and a leadership team curious about adding a predictive maintenance assistant to the product they sell.
Lane 1: Use Claude Code, accessed via Claude Platform on AWS, to chip away at the ERP customization backlog. Set up a shared CLAUDE.md template, policy hooks, and managed settings so every engineer is operating under the same guardrails. Measure pull requests merged, tests added, and rework rate.
Lane 2: Use Bedrock with Knowledge Bases over the QA team's compliance corpus to draft regulatory reports for human review. Inference-only, data inside AWS, AWS-managed guardrails, predictable cost line items. Measure hours returned to the team and the rejection rate of AI-drafted sections.
Lane 3: Defer the predictive maintenance assistant until Lanes 1 and 2 are producing. When ready, build it on Bedrock with AgentCore: Runtime for execution, Identity for customer authorization, Observability for support and audit, Guardrails for safety. Treat it as a product release with its own roadmap, support model, and SLA — not an experiment.
For this manufacturer, sequencing matters: the Lane 1 and Lane 2 work builds the governance scaffolding and team muscle that makes shipping Lane 3 safer. The right starting point varies by organization, but skipping straight to customer-facing AI without that foundation is where many adoption programs stall.
The Agent Layer Is Now a Real Platform Decision
A specific 2026 addition worth calling out: AgentCore changes what "running an agent in production" actually means. The pattern many teams hit through 2024 and early 2025 was a brittle agentic prototype that worked in a notebook and failed in production because there was no managed runtime, no identity model, no observability, and no graceful failure handling.
AgentCore closes those gaps. The new managed harness (preview) lets a developer define an agent by specifying a model, system prompt, and tools and run it immediately; when full control is needed, the harness orchestration can be exported as Strands-based code. The AgentCore CLI deploys agents through infrastructure-as-code with the same auditability you'd expect from any other AWS resource.
For leaders, the implication is straightforward: the platform layer for agentic AI is no longer something you build from scratch. It is something you choose, configure, and govern. That is the same arc compute, containers, and serverless went through, compressed into a much shorter window.
What I'd Do This Quarter
If I were standing up a Gen AI adoption program from scratch right now, three concrete moves before anything else:
1. AI adoption across the SDLC. Bring AI-assisted development into the day-to-day workflow of one or two engineering teams — code review, refactoring, test generation, PR analysis, and incremental modernization work. Use Claude Code under managed settings with a shared CLAUDE.md, and pick the substrate intentionally. Run it for at least six weeks against a real backlog, not toy projects. Measure pull requests merged, review cycle time, and developer satisfaction.
2. One operational efficiency pilot. Pick a single internal task that eats meaningful team hours each week — drafting compliance reports, triaging support tickets, summarizing meeting notes, reconciling data exports, generating release notes. Run it through Bedrock with Knowledge Bases over the relevant corpus, with a human review step before any output ships. Measure hours returned to the team and the rejection rate of AI-drafted output.
3. Governance baseline. Establish the controls that will eventually apply to every lane: a CLAUDE.md template, policy hooks that block risky commands at the tool layer, permission modes that match team maturity, and an explicit data-handling rule that no PII or production data goes to any AI tool that hasn't been governance-approved for it.
These three actions will not deliver the predictive maintenance assistant. They will earn you the credibility, the governance scaffolding, and the team muscle memory to deliver it later.
Where This Leaves Us
The 2024 adoption blues were real. The cultural, skill, integration, and data-platform challenges have not gone away. What has changed is that the technology has stopped being the bottleneck. The bottleneck is now organizational design — how leaders structure substrate choices, how they sequence value capture across lanes, and how they govern agentic systems at production scale.
If your platform team is still asking "should we use Bedrock or wait?", the gap between you and teams who have already moved into substrate-and-portfolio thinking is widening every quarter. The companies setting the pace are not necessarily smarter. They have just started running.
At NextLink Labs, we help clients walk this path: substrate decisions, lane sequencing, governance scaffolding, and the rollout work that turns generative AI into a sustained advantage instead of a perpetual pilot. If that conversation is on your roadmap this quarter, we should talk.
Arumugam Shanmugam
May 20, 2026
DevOps
Jordan Saunders
·
Mar 13, 2026
Digital Transformation
Cybersecurity
Jeremy Dodson
·
Jan 21, 2022