Spring AI and Bedrock AgentCore: A Java Agent in Production with One Annotation and Two Endpoints
A Java agent prototype usually stalls not on the model, but on the surrounding plumbing: scaling, security, memory, monitoring. AWS shows how to close those gaps by combining Spring AI and Bedrock AgentCore. A single @AgentCoreInvocation annotation brings up the required endpoints, and the rest of the code looks like an ordinary Spring service. The examples include a travel assistant and multi-agent document processing.
AI-processed from AWS Machine Learning Blog; edited by Hamidun News
If you run an enterprise Java team, the story with agents usually goes like this: someone built a demo in Python, everyone liked it, and then it turns out it doesn't fit into your CI/CD, monitoring, and access model. In a new walkthrough, AWS proposes a different path: don't change your stack, but connect agents through Spring AI and Bedrock AgentCore.
How an agent differs from a model call
A regular chat completion generates text, but it doesn't decide what to do next, doesn't reach into external systems, and doesn't remember yesterday's conversation. An agent combines three things: planning (breaking a goal into steps and revising the plan along the way), tools (APIs, databases, a code interpreter), and memory (within a session and across sessions).
A RAG application is not an agent here: it has retrieval, but no planning loop. An agent works in a loop until it completes the task or decides it can't continue.
What it looks like in code
AgentCore is a managed AWS platform that is not tied to a particular framework or model. The runtime requires only two endpoints from your service: POST /invocations for requests (JSON or streaming SSE) and GET /ping for health checks. If a task is long-running, the service must respond with HealthyBusy, otherwise the runtime may scale it down.
The Spring AI AgentCore SDK hides this contract behind the @AgentCoreInvocation annotation: it creates both endpoints itself, serializes JSON, and formats SSE. The same service can serve REST for a React interface, so a separate backend for the agent isn't needed.
Tools are wired in the same Spring-like way. You mark a method with @Tool and a description, register it in ChatClient via defaultTools, and the model decides on its own when to call it. For a structured response, you ask for a Java record, and for documents you attach a file to the user message. Memory is connected through advisors: interceptors add context to the prompt before the model is called. The memory section in the source text cuts off, so see the original for details.
From one agent to several
The second example is a document processing system with five specialists: legal, mortgage, insurance, tax, and a general agent. A classifier determines the document type and passes it to the appropriate specialist. The specialist returns structured JSON with a confidence score. Then SpEL rules from application.yml decide what to do: send an ALERT, block the document, or send it for manual review.
There are three patterns here: a router (dispatch only, no domain logic), an evaluator (business rules on top of the answers), and parallel fan-out. The last one is not implemented in the base solution: batch processing runs sequentially. If you add fan-out, analysis time will be determined by the slowest agent rather than the sum of all calls.
Limitations
First: this is AWS material, and it is tailored to the AWS ecosystem. Bedrock Converse API, AgentCore, Graviton, and Terraform modules are all in one bundle. Portability to other clouds is not discussed in the article.
Second: structured output into a Java record was tested on Claude Sonnet 4.5. Spring AI adds the schema to the prompt and parses the response, but the model sometimes returns data that doesn't follow the schema. For strictness, you need a provider with native schema control or validation with a retry request.
Third: for multi-argument tool calls, the authors advise assembling the response with a blocking call() and then slicing it into chunks so that arguments bind reliably. This reduces the value of true streaming.
What to do
If you have a Java stack and are already on AWS, start with the travel assistant: one agent, tools, and memory. Check how your model behaves on structured output, and only then add the router and rules. The requirements are strict: JDK 21, Spring Boot 4.1 with Spring AI 2.0, Terraform 1.5+, and Docker with Buildx for an ARM64 image. Make sure in advance that your project can withstand such an upgrade.
- Nov 12, 2026Claude will join your calls and update documents on its own: what's new in Team and Enterprise
- Nov 12, 2026AWS shows how to evaluate AI agents in 3 modes: from debugging to production
- Nov 12, 2026AWS Open-Sources UAEF: A Free Test Suite for AI Agents Covering 36 Metrics
- Nov 12, 2026How to Lock Down AI Agent Code: subprocess, Docker and microVM — Three Levels of Protection
Key Questions Answered
How an agent differs from a model call?
A regular chat completion generates text, but it doesn't decide what to do next, doesn't reach into external systems, and doesn't remember yesterday's conversation. An agent combines three things: planning (breaking a goal into steps and revising the plan along the way), tools (APIs, databases, a code interpreter), and memory (within a session and across sessions). A RAG application is not an agent here: it has retrieval, but no planning loop.
What it looks like in code?
AgentCore is a managed AWS platform that is not tied to a particular framework or model. The runtime requires only two endpoints from your service: POST /invocations for requests (JSON or streaming SSE) and GET /ping for health checks. If a task is long-running, the service must respond with HealthyBusy, otherwise the runtime may scale it down. The Spring AI AgentCore SDK hides this contract behind the @AgentCoreInvocation annotation: it creates both endpoints itself, serializes JSON, and formats SSE.
What are the key details on From one agent to several?
The second example is a document processing system with five specialists: legal, mortgage, insurance, tax, and a general agent. A classifier determines the document type and passes it to the appropriate specialist. The specialist returns structured JSON with a confidence score. Then SpEL rules from application.yml decide what to do: send an ALERT, block the document, or send it for manual review.
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.