The AgentCore verdict: buy, build, or both

Part 3 dissected a managed agent platform component by component. This closing chapter assembles the verdict, and its method matters more than its conclusions: score the platform against the same twelve gates as anything hand-built, name the DIY equivalent and crossover for each component, and measure lock-in by what survives leaving. The worked example is AgentCore; the method applies unchanged to Anthropic's Managed Agents, the LangGraph platform, or whatever ships next quarter, which is the point of having a method.

The matrix

For each component: what this book builds instead, where the managed version stops being the obvious choice, and what you keep if you walk away.

ComponentDIY equivalent (and where)Managed wins until...Portable on exit
RuntimeFargate/Lambda workers + session bookkeeping (Parts 4, 6)Fleets saturate workers 24/7, where flat per-hour beats per-sessionYour container and loop run anywhere; session semantics rebuild on Part 4's skeleton
MemoryEvent-store capture + extraction jobs + vector retrieval (Part 7)Your domain needs provenance-first or unusual extraction the strategies cannot expressRaw capture stays in your ledger either way (keep it there); extracted memories export as data
GatewayHand-written MCP servers (the 150-line lab) + your authTool count stays small and static; a handful of hand-written servers is less than a factoryEverything: targets are your APIs; MCP is an open protocol; any client keeps working
IdentityOAuth flows + a secrets vault + egress injection (Part 8 patterns)Never cheap to DIY well; this is the component to buy longestProvider registrations and consent grants transfer; the pattern (tokens never transit the model) is yours to re-implement
Code Interpreter / BrowserFirecracker sandbox service (Part 5)Egress policy, custom images, or fleet-scale economics force the buildInterface is narrow (run code, drive page); swapping backends is days, not months
ObservabilityOTEL emission + your trace store + ledger jobs (Part 9)Rarely worth fully replacing; OTEL means you add backends insteadTraces are OTEL: re-point the exporter
PolicyCedar embedded in your gateway, or IAM-onlyRarely; authoring ergonomics are the productCedar policies are Apache-licensed text: take them
EvaluationsJudge harness + golden suites in CI (Part 9)Your rubrics and gates mature past the built-insSuites and rubrics were always yours; traces re-run anywhere

Read down the "portable" column and the pattern from the decoder ring completes itself: because this platform is assembled from open substrates (Firecracker, MCP, OTEL, Cedar), exit costs are mostly operational (you now run things), not translational (you rewrite things). That is materially better than the lock-in shape of prescriptive platforms, where the agent's very structure belongs to the vendor. It is also, historically, why the prescriptive predecessor lost: Bedrock Agents Classic, which dictated agent shape through action groups, is closed to new customers, and its documented migration path is the open one (action groups become Gateway-served MCP tools). When a platform's own vendor migrates it toward open protocols, believe the direction.

The scorecard

The production bar, applied to a maximal buy (all components adopted):

GatesVerdict
2 Isolation, 9 ObservabilitySubstantially inherited: microVMs per session, OTEL traces flowing
1 Identity, 10 Human control, 11 Blast radiusStrong assists: Identity's token vault, Policy's outside-the-loop rules; your design still decides scopes, gates, and worst cases
8 EvalsAssisted: graders supplied; suites, calibration, and CI gates yours
3 Budgets, 4 Replayable state, 5 Failure semantics, 6 Resumability, 7 Throughput discipline, 12 OperabilityYours, entirely. Nothing in the platform knows your budget, your ledger, your idempotency keys, your quota citizenship, or your runbooks

Half the bar is not for sale, and it is precisely the control-plane half this book's remaining parts build. That is the deepest reading of Part 3: managed agent platforms sell excellent execution-plane answers, and the reference architecture's other planes are why a book like this exists even in a world of good platforms.

Three teams, three verdicts

  • The product team (an agent feature, no infrastructure appetite): buy everything above, spend the saved quarters on tools, evals, and the domain. Revisit at real scale, with the ledger as evidence.
  • The platform team (Hive-shaped: fleets, tenants, hard budgets): buy Identity, Observability, and sandboxes; build execution and state on Parts 4 through 7, because budgets, leases, and resume are the product. This is the capstones' mix.
  • The constrained team (regulated, air-gapped, or egress-strict): the open substrates are the consolation prize: Firecracker, Cedar, OTEL, and MCP all run wherever you must, and this book's DIY parts are, not coincidentally, a construction manual for exactly that stack.

Don't be confused: framework-agnostic vs framework-free. AgentCore hosting "any framework" does not mean frameworks stopped mattering; it means the runtime stopped caring, which moves the framework choice back to you. The next tier of that choice (Strands, LangGraph, or Part 1's bare loop grown up) is Part 10's business, and everything in Part 3 works identically under all three.

👉 Next, per the map: the swarm chapters (Part 6) and the serverless skeleton beneath them (Part 4), where the half of the scorecard that is not for sale gets built.