Building AI Ageants with Spring AI, Embabel and Amazon Bedrock AgentCore - Part 1

Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore

Building AI Ageants with Spring AI, Embabel and Amazon Bedrock AgentCore - Part 1

Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore – Part 1 Introduction to the series

Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore – Part 1 Introduction to the series

Introduction to the series

In my article series Building AI Agents with Spring AI and Amazon Bedrock AgentCore, we’ve already covered how to build AI Agents with Spring AI and Amazon Bedrock AgentCore. You’ll need to go through at least its first 4 parts to be able to follow this article series. I’ll reuse that sample application for this series. Why might the abstractions provided by Spring AI frameworks alone not be enough? Let’s look at the prompt that we sent to our application in Provide MCP tools for Conference application via AgentCore Gateway article:

“Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today. Also, provide me with the list of my talks with this topic in the title. Finally, for each conference and talk retrieved, apply individually for the conference.”

The prompt is highly unstructured. We set here at least 3 pairs of requests to the LLM and their responses:

  1. Request: “Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today”. LLM responds to it.
  2. Request: “Provide me with the list of my talks with this topic in the title”. LLM responds to it.
  3. Request: “For each conference and talk retrieved, apply individually for the conference”. This request means that the LLM uses its responses from the first 2 requests as the request and responds to it.

The thing is that we, as humans, can think logically, but not every LLM can break this prompt down into such individual pieces. So, it might require a strong and more expensive model to be able to do it. If we can automatically break down the problem into subtasks so the prompt will become structured, the LLM will have better chances at doing its job right. Spring AI has a function CallResponseSpec.entity method for the synchronous LLM call to at least convert the response to structured output. But again, this is not enough, as we need to break down the initial prompt into a set of structured subtasks first.

The next challenge  is that in the same article, we exposed 7 MCP tools through the Bedrock AgentCore Gateway. And we gave all of them to the LLM all at once. Because LLM can’t respond to any request without using the correct tool. And there is always only 1 correct tool out of 7 per request. There is a high chance that the LLM will hallucinate. I won’t only break down the prompt correctly, but also select the wrong tool to respond to the request.

Wouldn’t it be better if we could break down the prompt as described above and give the LLM exactly the correct tool per request? See the parts 2 and 4 to see how we defined and exposed those MCP tools. For the first request, it will be the “conference search tool by topic, date, and call for papers open” tool. Then, for the second  tool – “get talks by title substring” tool. For the third – “apply to conferences with conference ID and talk ID” tool.

With Spring AI, we can filter the tools, as we explained in part 3. But it’s not enough as long as we can’t break down the big prompt into individual subtasks, which may require suitable tool(s). If we implement prompt handling in a not structured way, it’s not trivial to implement the tool filtering. This is because different prompts may require different tools depending on their content.

The same challenges have another prompt from the same article: “Please create a talk with a cool title (max 60 characters long) and description (max 300 characters long) about using Spring AI on the Amazon Bedrock AgentCore service. Then provide me with the list of conferences, including their IDs, with Java topics happening in 2026 and 2027, with the call for papers open today. Finally, for each conference, apply individually for it with the talk just created.”

The only difference from the previous prompt is that we ask the LLM to create a new talk instead of extracting the existing talk(s). For this, the LLM will need to use the “create new talk” tool.

Also, our application has 2 different actors. First, these are conference attendees who are interested in searching for and attending the conference. Second, these are the conference speakers who apply to the conference with their talk(s). Maybe those actors should use a different LLM model that suits each role the best.

Welcome to the Embabel.  It’s a framework for authoring agentic flows on the JVM that seamlessly mixes LLM-prompted interactions with code and domain models. It supports intelligent finding the path towards goals. Embabel builds on the Spring AI framework.

I give some links to the resources, which will help you to grasp the concepts of this framework quickly.

We’ll explore in the next articles, Embabel is capable of addressing and solving those challenges that we described above. Throughout this series, We’ll improve the agent developed in the Provide MCP tools for Conference application via AgentCore Gateway article using the Embabel framework. First, we’ll use the Embabel shell, then the web application. You can already look at my GitHub embabel-0.x-conference-app-agent-local repository for the example.

The reasons I decided to create a separate series for using the Embabel framework are:

Stay tuned!