Spring AI SDK for Amazon Bedrock AgentCore Is Now GA

Amazon Web Services released the Spring AI SDK for Amazon Bedrock AgentCore as generally available on November 11, giving Java developers an open-source library that integrates AgentCore into Spring AI through annotations, auto-configuration and composable advisors. The SDK's @AgentCoreInvocation annotation auto-configures the POST /invocations and GET /ping endpoints AgentCore Runtime expects, while memory integrates through Spring's advisor pattern; AgentCore Runtime V2 expanded to 10 AWS Regions this week with 2-second cold starts, up to 8 vCPU allocation, scale to zero and sessions persisting up to 8 hours. AWS is targeting enterprise Java shops, which the article says make up 62% of enterprises using Java for AI functionality in production, as the CNCF's Q3 2026 report found 49% of cloud-native teams now run AI agents in production.

Java developers have been building enterprise backends for decades, but the AI agent revolution largely passed them by. Python-first frameworks — LangChain, CrewAI, AutoGen — dominated; Java got LangChain4j, a port that never quite fit. That changes now. AWS’s Spring AI SDK for Amazon Bedrock AgentCore went generally available on November 11 https://aws.amazon.com/blogs/machine-learning/spring-ai-sdk-for-amazon-bedrock-agentcore-is-now-generally-available/ , and it’s the first time Java developers get a production-grade agent stack that actually speaks their language. Not Just Another Wrapper The SDK is an open-source library available on GitHub https://github.com/spring-ai-community/spring-ai-agentcore that integrates Amazon Bedrock AgentCore into Spring AI using real Spring idioms — annotations, auto-configuration, and composable advisors. No Java bindings duct-taped onto a Python SDK. No boilerplate HTTP wiring. The entry point is a single annotation: @AgentCoreInvocation public String chat String userMessage { return chatClient.prompt .user userMessage .call .content ; } That annotation auto-configures the POST /invocations and GET /ping endpoints AgentCore Runtime expects, handles JSON serialization, and reports health status. Memory — typically the messy part — integrates through Spring’s advisor pattern rather than a bespoke memory object: ChatClient chatClient = ChatClient.builder chatModel .defaultAdvisors agentCoreMemory.advisors .build ; Spring’s auto-configuration takes care of the rest. If you’ve written a Spring Boot service before, the learning curve here is shallow. What AgentCore Actually Runs On The SDK is the developer-facing layer; the infrastructure underneath is worth understanding. Amazon Bedrock AgentCore provides hardware-isolated Firecracker microVM sessions — each user session gets its own VM with isolated CPU, memory, and filesystem. When a session ends, the microVM terminates and memory is sanitized. That’s not just a marketing bullet; it’s the kind of deterministic security model that enterprise compliance teams actually require. The Runtime V2 — which expanded to 10 AWS Regions this week, including Frankfurt, Stockholm, Mumbai, Singapore, and Sydney — delivers 2-second cold starts, up to 8 vCPU allocation, scale to zero, and sessions that persist up to 8 hours. For teams not ready to commit to the managed runtime, the same Spring AI code runs on EKS, ECS, EC2, or on-premises. No rewrite required to switch. Why Java Teams Are Actually Blocked Right Now The practical problem this solves: 62% of enterprises already use Java to power AI functionality in production, yet prototyping has been stuck in Python. Teams build agents with LangChain or CrewAI, demonstrate value, and then face a rewrite when the enterprise deployment target is a Java microservice fleet. That rewrite is expensive and kills momentum. The Spring AI SDK closes this loop — Java teams can prototype and ship in the same language and framework they already use. The KubeCon NA 2026 timing is a signal. The CNCF’s Q3 2026 report, released the same week in Salt Lake City, found that 49% of cloud-native teams now run AI agents in production https://www.cncf.io/announcements/2026/11/10/cncf-and-slashdata-report-finds-cloud-native-developers-are-more-ai-ready-global-population-surpasses-21-million/ . Those are largely enterprise Java shops. AWS is positioning AgentCore as the production runtime for that majority. Python Isn’t Going Anywhere To be clear: Python still runs 80% of AI agent implementations and continues to dominate prototyping. The Spring AI SDK doesn’t change that dynamic. What it changes is the operationalization story. Enterprise Java shops no longer need a Python sidecar, a framework translation layer, or a rewrite to ship agents into production. This is an infrastructure story, not a language war. The full AWS tutorial on building autonomous agents with Bedrock and Spring AI https://aws.amazon.com/blogs/machine-learning/build-autonomous-ai-agents-with-amazon-bedrock-and-spring-ai/ covers tool calling, memory, multi-agent orchestration, and streaming in depth. The GitHub repo https://github.com/spring-ai-community/spring-ai-agentcore has working examples. If your team runs Java in production and has been watching the agent space from the sideline, the excuse just expired.