Build autonomous AI agents with Amazon Bedrock and Spring AI

Java teams have established JVM tooling, continuous integration and continuous delivery (CI/CD) pipelines, and operational patterns, yet taking AI agents from prototype to production is hard: agent frameworks do not solve scalability, governance, security, and operational concerns by default. Amazon Bedrock and Spring AI close those gaps, so Java teams can build autonomous AI agents that plan, call tools and APIs, and maintain context across multi-turn conversations. Agentic AI is moving beyond prompt-response interactions toward autonomous systems that execute complex multi-step tasks. Java remains one of the widely used programming languages in enterprise software. Teams have existing CI/CD pipelines, operational expertise, and established patterns built around the JVM. Spring AI brings AI capabilities to the JVM through familiar Spring patterns: auto-configuration, dependency injection, and composable advisors. Developers can build AI agents using the same idioms they use for REST APIs, security, and data access. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. With AgentCore, you can build, deploy, and operate AI agents at scale. It is framework-agnostic and model-agnostic: you bring your preferred agent framework and foundation model (FM). With AgentCore, you can access the production infrastructure you need: managed runtime, memory, browser automation, code execution, and identity management. In this post, we show you how to build autonomous AI agents in Java using Spring AI and Amazon Bedrock with spring-ai-agentcore . We explore the key implementation patterns for two systems. The first is a single-agent travel assistant that demonstrates tool calling and memory. The second is a multi-agent intelligent document processing (IDP) system that shows how specialist agents, a rules engine, and alerting work together. Prerequisites To follow along with this walkthrough, you need the following: Java – JDK 21 (required) Spring Boot – 4.1 (with Spring AI 2.0 and spring-ai-agentcore 2.0) Maven – 3.9+. Node.js – 18+ (for the React frontend) Terraform – 1.5+. Docker – with Buildx for multi-architecture builds. AWS Command Line Interface (AWS CLI) – v2, configured with credentials. An AWS account . What makes a system an agent A chat completion call can generate text, but it can’t decide what to do next, reach into external systems, or remember what happened yesterday. An agent can, because it unites three capabilities: Planning – Given a goal, the model breaks it into steps, prioritizes them, and revises the plan as new information arrives. Tool use – Beyond generating text, the model can select and invoke external functions such as APIs, databases, and code interpreters to act in the world. Memory – Context carries across turns (short-term) and across sessions (long-term), so each decision builds on what came before. A Retrieval Augmented Generation (RAG) application has limited tool use (retrieval) but no planning loop. An agent has all three, operating in a goal-directed loop until the task is complete or it determines it cannot proceed. The following diagram shows these capabilities in an end-to-end agentic pipeline, from request to grounded answer. Figure 1: Agentic reference architecture. A request flows through the runtime, guardrails, classification, a specialist agent, tools, the foundation model, memory, rules, and human review to a grounded answer, with resilience and observability as cross-cutting concerns The pipeline has 11 stages. A client submits a document and question. The request passes through a runtime gateway for authentication and rate limiting, then input guardrails screen for harmful content. A router classifies the document and routes it to a specialist agent, which plans its workflow and calls tools, the Amazon Bedrock foundation model, memory, and a rules engine as needed. Low-confidence or flagged results go to a human review queue before the grounded answer returns to the client. Resilience, observability, logging, and least-privilege AWS Identity and Access Management (IAM) apply across all stages. Solution overview The solution consists of two deployable systems that share common patterns: Travel agent – A single autonomous agent with tool calling (weather lookups, itinerary search), streaming responses, conversation memory, and resilience patterns. This is the recommended starting point. IDP multi-agent system – A multi-agent intelligent document processing platform with five specialist agents (Lawyer, Mortgage, Insurance, Tax, General), rules and workflow engine, alerting, and observability. This demonstrates production patterns at a scale. Both systems share the following architecture: Spring Boot application with Spring AI ChatClient, Spring AI agentcore and Amazon Bedrock Converse API. AgentCore runtime, a capability of Amazon Bedrock AgentCore, defines the contract (POST /invocations , GET /ping ) for managed deployment. Conversation memory through AgentCore memory, a capability of Amazon Bedrock AgentCore, for both short-term and long-term context. Tool calling with @Tool annotated methods. Structured output mapped to Java records. ARM64 container image optimized for AWS Graviton. Modular Terraform for infrastructure provisioning. The travel assistant is the recommended starting point. The following diagram illustrates how a Spring Boot agent interacts with AgentCore runtime, tools, memory, and models available on Amazon Bedrock. Figure 2: Single-agent travel assistant. The Spring Boot application exposes both REST endpoints for the React UI and the AgentCore runtime contract, calling Amazon Bedrock through the Converse API while tool calling, streaming, and memory run inside one code base. The travel assistant runs a single Spring Boot application with two entry points, the /invocations and /ping contract required by AgentCore runtime. Spring AI orchestrates calls to Amazon Bedrock through the Converse API and resolves tool invocations locally inside the same process. Server-Sent Events stream tokens to the client as they are generated. AgentCore memory supplies both short-term context within a session and long-term context across sessions, so the agent retains conversation history without external state management. The following diagram shows the architecture for the IDP multi-agent system. Figure 3: IDP multi-agent system architecture. Specialist agents process documents through a shared ChatClient pattern, with results flowing through a rules engine and alert service. The IDP multi-agent system routes documents through five specialist agents (Lawyer, Mortgage, Insurance, Tax, and General), each built on a shared AbstractDocumentAgent template. A ClassifierAgent reads each document and forwards it to the appropriate specialist. The specialist extracts structured JSON with confidence scores using the multimodal Converse API of Amazon Bedrock. A rules engine evaluates Spring Expression Language (SpEL) expressions from application.yml against the extraction. ALERT or BLOCK severity rules dispatch through the AlertService . Low-confidence documents go to human review. Metrics, audit trail, resilience, and observability apply across all stages. Agent collaboration patterns When multiple agents work together, how they coordinate determines system behavior. This solution uses three patterns: The following diagram compares the three coordination patterns used in this solution. Figure 4: Agent collaboration patterns Three patterns shown side by side. The router dispatches each request to one specialist by document type. The evaluator passes specialist findings through a rules engine that applies to severity levels and dispatches alerts or blocks for human review. The parallel fan-out sends one request to multiple specialists concurrently and aggregates results before the rules engine runs. Router pattern: A lightweight orchestrator examines the incoming