Building Agents with Spring AI, Sergi Almar

This talk focuses on Spring AI, an innovative project in the Java ecosystem that enables developers to build AI applications without leaving the JVM. The speaker, an experienced Spring developer and organizer of Spring I/O, discusses the rapid growth of AI in the tech landscape and introduces the key features of Spring AI, including auto-configuration, memory support, and tool calling capabilities. He emphasizes the importance of abstractions such as advisors and agent workflows, which allow for more complex interactions with language models. Further, he explains the upcoming features in Spring AI 2.0, including support for structured outputs, enhanced memory storage, and durable workflow orchestration. By utilizing tools and patterns like user prompting, task management, and skills, developers can create sophisticated agentic systems. The talk concludes with a look at how these concepts are supported by protocols like MCP and A2A, further expanding the possibilities for AI integration in Java applications.

Okay, okay. So, as usual, we are 2 minutes late. But, uh Okay, let's go ahead. So, before starting this conversation, how many of you are using Quarkus? Yes. And now the best question, how many of you use Spring? That's why we are here, absolutely. So, um we're going to talk about the best thing happening to Java world, which is called Spring. And um we'll make it even

better because uh it's going to have AI on it. So, finally, let's go back to real life after wonderful Venkat session about Java. And real life is Spring with AI, and I'm extremely happy that for this particular session, we are having I believe one of the most influential persons in Spring world, the organizer of Spring I/O Barcelona. Sergey, please warm welcome. Thank you for being here. >>

All right, thank you Dimitri for the introduction. Uh let's do this. Let's continue our agentic journey. Is anyone overwhelmed by AI? Everyone here, right? So, this is the AI landscape, really similar to the cloud native landscape, right? And as you see, we can even read anything here, right? And this is also dated from last year, so you can imagine that this year this has grown uh substantially

as well. But as you know by now, um the good news is that we don't have to leave the JVM to build agentic or uh gen AI applications, right? And that's basically what I'm going to talk about today, about the Spring AI, right? All right. AI is one of the most interesting projects in the ecosystem right now. Really fast growing. And it's basically what will allow you

to build these agentic and also right at JNAI applications. It's basically having the same principles as all the Spring ecosystem giving you some abstraction layers in that case to connect with different providers, different LLMs, even local models. It has all the auto configuration that you're used to in the Spring ecosystem. And it contains all the building blocks to build these AI applications. Uh being tool calling, memory

support, rack vector store support, and so on and so forth. So, my name is Sergi. I've been doing Spring for the last or more than 20 years now. So, I've been helping a lot of clients building better Spring applications. I'm also delivering the official trainings for Spring. back in 2010 because I was really passionate about Spring, I started the Spring IO. And that's basically the place you

have to be if you are a Spring developer, right? So, it's basically the conference for for Spring developers, which is still right ongoing. So, if you haven't used the Spring AI so far, that's your sign to start using it cuz next week will have the 2.0 release, right? So, 2.0 will go GA. That's basically the release that is fully compatible with the Spring Boot 4 and the

Spring Framework 7, the next generation of of the framework. It also has native support for the the Java SDKs from the different providers. It has like better native features. So, for instance, if a LLM has already support for structure output, it will use the native support for that instead of like just building on top of of that, right? It also has a lot of a lot of

refinements on the chat client. So, the 2.0 was an opportunity to clean up right the chat client. If you have used other parts of the Spring like I don't know the JDBC client or the REST client, so that's going to be more or less the same programming model But applied to LLM's and and AI, right? And also MCP has basically taken some of the community contributions that

like MCP annotations and basically now are part of of the core and the 2.0 release will also be released along the MCP JDK SDK, sorry, 2.0. So that's building the foundations, right? So next week we'll have already right the GA 4.0. Hello, but in November we're going to have the the next iteration of a Spring AI, right? And that's going to be the 2.1 and that's what

will focus on the agentic workflows and support, right? And we'll have a new module called Spring AI agent. And that's what will give you the abstractions that you might be willing to have right there on top of the the chat client. It will also have durable workflow orchestration. That means that if your agent goes down, it can recover, it can start from where it left off. That

will leverage some of workflow engines like a temporal and dapper probably. It also has a better memory story, right? With the session API. So currently the the the memory support is quite basic, right? And you know the messages are kept until a certain point, but the session API will allow you to do some kind of compaction right and many other interesting things. It also will have support

for a stateful APIs, right? So for instance, open AI response API and Gemini interactions API, right? So it's a good time right to start with with a Spring AI. yeah, if you ask people different people right there what an agent is, probably you'll get different um definitions, right? But a a good definition could be this one which is it's using the model to interact with its environment

in order to solve a user defined task, right? So at the end of the day uh we need several several things, right? So, we need to to plan, to take actions, we need some memory. And in the world of AI, right, this planning is done by the LLM itself, right? So, it's basically the brain that coordinates everything or decides what to do next. But, as ourselves, right,

our brain might say, "Hey, could you please take this uh cup of coffee?" Well, we need something to to grab the cup of coffee. We We need a hand, right, an arm. Then, the brain will basically give give the actions to um to the the arm, right, to to grab the cup of coffee. And this in the AR AR world will be the tools. So, the LLM

will basically plan, right, so take actions, and it will use those tools, right, to perform the the tasks. And of course, we also need memory, right? Because we need to remember what we've done and continue with the tasks that we that we have in in the plan. So, my idea today is to basically start with the foundations for the ones that don't know Spring AI, right? A

little bit about the foundations because we need those to build on top, right, in the next section, right? So, where we're going to see a little bit of agent workflows and patterns. We'll talk a little bit about the agents and also about some protocols, specifically MCP and 2A. So, your starting point will be the chat client. As mentioned, this is really similar to JDBC client, right, the

REST client, things that you have already used in Spring, right? So, we'll have a builder. We can define some some defaults for that chat client like the system prompt. And then, we basically use it like this way, right? So, we say, "Hey, I want to provide a user message. I want to call the LLM and then give me the response back." In that case, we're going to

get a string response back, but we're going to see later on that we could even map that into some kind of record or class, right? So, we can have a structured output in here. But, I would say that one thing that you have to understand is the concept of the advisors, right? So, the advisors are nothing more than interceptors. If you're used to, I don't know, web

applications, we you have been doing this for a long time, right? So, servlet filters, interceptors. In Spring, we also have, you know, all these proxies, right? And they all underneath have the the same um the same concept, right? So, in that case, the advisor is something that allows allows us to intercept the original prompt, right, before reaching the LLM, and then also intercept the response from uh

the LLM before reaching the user, right? And we're going to use the advisors for everything. To add a memory, for instance, to enable RAG, to uh well, we'll we'll see a lot of patterns, right? To basically call tools, as well, right? So, everything is built on top of a an advisor in uh the chat client, right? So, the chat client can be configured with multiple advisors. They

can be ordered, and you can say, "Hey, let's apply memory here. Then let Then Then let's apply a logging. Then let's apply this, this, and this." So, all of them can contribute, right, to this um to this prompt. And uh and basically inspect it, augment it, and also, on the other side, it can also uh get the response from the model and transform it. Maybe I want

to transform the text into, I don't know, uh an object. Maybe I want to uh mask something from from the uh LLM. So, that's basically uh the advisor. So, the concept of the advisor will be present with us, right, for the entire presentation. And uh yeah, if you use the Spring AI, everything is modeled as an advisor. The other thing that we have mentioned uh is that

the uh the agents, right? need these tools, right, to uh perform the actions. And uh Spring AI supports tool calling. And uh basically, what we're we're going to do, or what the chat client will do, is uh instruct the LLM, or pass the LLM, the available tools that we have. So, it will pass the name, the description, the schema, right, of uh the tool, how it's called.

And uh that will be added into the um into the call, right? So, it will reach the the LLM. And if the LLM decides that we need this tool, it will go go back to us, uh tell us that we need to execute a particular tool, and this tool will execute on our application, right? So, it's not the LLM executing the tool, the tool will be executed

on our application. So, the LLM will instruct us to execute those tools. And well, we we might have to execute multiple tools at for a particular prompt, right? And eventually, we'll get If you have a lot of tools, you might pollute, you know, that prompt time and specifically or especially when you use a MCP servers that might expose a a lot of tools, you might yeah, pollute

a lot of the the prompt, right? On the LLM. And also, when the LLM has a lot of tools available, um it might get it wrong, right? Because some tools might look really similar. It would know which one to to call. So, um in order to save tokens, in order to reduce the context, in order to make it more specific, uh we should avoid sending, right, a

lot of tools. And in Spring AI, we have something called the tool search tool, right? So, which is basically a tool, right, that it's initially passed to the LLM saying, "Hey, if you need any extra tool, just ask me." Right? And this tool will be called whenever the LLM decides that it needs something extra, right? And this tool in our application will at the same time find

the right tools for that particular request, right? So, and finding these tools might be based semantic search, might be based on on regular expressions, right? So, the idea here is to not expose all the tools, but just one tool that eventually the LLM will uh will call to discover, right, the tools for that particular use case, right? Because if you don't know what tools you might need

for that particular use case, sending all the available tools that you have might be pointless because you will you will not use them, right? Um for that particular task. All right. So, let me um quickly jump into a into a demo real quick, right? Really simple demos. Um first of all, uh let's just interact with an LLM, right? So, a simple just one line. So, as you

see here, we are using the chat client builder to build a chat client. And what I'm doing is basically having this while loop and getting, you know, whatever I type in here and passing it into the chat client. I pass that the prompt. I call it and then I get the the the content back. So, if we execute that, I say, "Hi, I'm Sergi, for instance." I'm

going to going to get the response. But notice that the LLMs are stateless, right? So, it will basically get a response. "Hi, Sergi. Nice to meet you." But if I ask, "What's my What's my name?" You'll see that the LLM doesn't remember my name because this is stateless, right? The Wi-Fi dots are with me and this um gets back. But yeah, the idea here is that you

know, playing, right? Um Ooh. Let's repeat that. Hi, I'm Sergi. Okay, what's my name? Type was in there. Okay, so I don't know your name yet, right? So, that's because we don't have any any memory in here. All right. So, um you can instruct the LLM to to work in a a particular way. And when you um interact with the LLM, you can pass what we call

the system prompt, right? So, in this example here, I uh instruct the LLM that it's a helpful assistant, but always answer in Catalan. So, That's English, but I'm expecting it to answer in Catalan because that's basically what I instructed in here. Okay. So, as mentioned, this is basically giving us just the text back, but sometimes and usually what do you want to do is to map that

into something, right? Into maybe a class, a record. And what we do here is to basically call the the LLM. I'm going to ask, "Give me the best tourist attractions in Sofia." And I want to map it into a record, right? So, that's called the structured output. So, a record contains a name, contains an address. So, I'm expecting that when I call the LLM to map the

output string into this particular record, right? And as you see here, it has come back to me and said, "Hey, the best tourist attraction is Alexander Nevsky Cathedral and it's in Sofia, Bulgaria." Right? And your application is actually being able to to to get the tourist attraction, do something else with it, right? So, we don't deal with simple strings, but records in that case. What else do

we have? All right. So, let's get into memory. So, as mentioned, everything is built on top of advisors, right? And in this case, I'm configuring the chat client with the default advisor, which is the chat memory advisor. Chat memory advisor has a number of messages stored, right? And when these messages leave the the maximum number of messages, they are lost, right? So, maybe I want to keep

the last 100 messages in the conversation. And these messages will be added into the context, right? Of the LLM. So, we don't want to add all these the history because this will consume a lot of tokens, but we're going to restrict the number of messages send from from the history. you would test that and let's repeat the um, what we've done. Hey. Hey, I'm Sergii M. All

right, nice to meet you. So, what's my name? Now, it should remember my name, right? Because that context, it's part of the uh, the prompt as well. Okay? So, um, adding all these it's as simple as adding the advisors, right? And that's why the concept of an advisor is uh, so important, right? Because we are going to, yeah, uh, modify the prompt, add anything to the prompt.

And another example will be um, a a guardrail, right? So, in a production application, you don't want to let the user ask uh, what whatever they want. You want to add some guardrails so the uh, LLM is answering just for its particular questions. And in that case, I'm defining an advisor. It's a built-in advisor. You can build your own advisor. Really simple advisor for uh, guardrails. And

I'm specifying some sensitive words, right? So, if the user um, adds any of the sensitive word, we're going to not even reach to the LLM. We're going to avoid reaching to the the So, let's uh, try that. Um, hey, I want to kill an ant. How can I do it? All right. So, as you see, right? That this responded real fast because it didn't even reach the

LLM. So, the advisor uh, took the uh, the prompt. It basically noticed that it has some uh, sensitive word and it prevented the call to reach to the LLM. The last thing uh, from this foundations is basically the tool calling, right? And as mentioned, we need some some tools. And a tool is nothing more than a method that you might have might have, right? So, in my

example here, I have a method called get temperature. It's using uh this service Open-Meteo, right? It's basically connecting to Open-Meteo to get uh some weather. And I'm just exposing it as a tool with this add tool annotation. So, what I can do when I build the uh chat client, I say, "Hey, you have here some default tools, right? Everything which is annotated with a tool, uh take

it." And as you see, the tools uh contain a description, contain a name, right? And uh also it will pass some schema to the LLM. So, Spring AI will just take all this data, it will pass it along with your your prompt, and the LLM will decide whether this tool needs to be executed um or not. Okay. So, what's uh what's the current uh weather in Sofia?

So, hopefully this will um execute and get our um tool executed. Actually, I have a in my lock statement check temperature for whatever. And as you see here, we have this lock uh uh statement here. So, let's check temperature for Sofia. Notice that what I'm expecting in this method is basically that latitude and the longitude of a particular city, right? So, the LLM has taken the latitude

and longitude from Sofia and has passed these into my my tool. So, it can return that the temperature current temperature is 18 um degrees Celsius, right? Which more or less, right? That matches the outside uh of today. All right. So, that was the foundation, right? Easy, right? So, just one a single line, we get into the LLM, we uh can add advisors for memory, for guardrails, right?

For tool calling, right? And many other things, right? You can build your own advisors. So, these are really powerful uh pattern. But now, when you want to build uh uh agentic systems, you need to have more than this foundations, right? So, um we have to differentiate between uh agentic workflows and autonomous agents, I would say, right? So, the workflows are more deterministic, so that's you deciding how

to call those LLMs. Maybe you want to call the LLM and when with the response you want to call yet another LLM and so on and so forth. So, the flow is kind of determined by by you. But, it's more predictable, right? Uh you have uh uh control over it, right? And usually and if you know what you need to do, the different tasks that need to

be done, that would be the best approach, right? So, the more deterministic, the better, right? But, uh sometimes for more complex tools, the things that you don't even know what uh what requires, right? You might want to delegate to the agent to decide uh what to do, right? So, and this agent might decide to delegate to another agent, right? Or execute these tools and and so on

and so forth, right? So, that's basically um the two options that that we have here. If we take a look at the workflows, um we have the different patterns, different workflows. Uh the first one is the chain workflow where uh you basically call an LLM, right? You you wait and probably with the response you decide to call yet another LLM and maybe another LLM and so on

and so forth, right? So, you basically chain these LLM calls. Another option would be to parallelize the um the calls, right? So, when you know that uh the tasks don't have anything to do with each other and you want to call the different LLMs or the same LLM multiple times, uh you can just uh parallelize that, right? And basically basically aggregate the result at the at the

end. We also have the routing workflow, right? So, based on uh maybe uh prompt, the response of an LLM, you then route to, right? Uh another LLM, right? And uh this is useful because uh you might want to add specific tools to that particular call, uh change the prompt, right? Uh do it more specific and so on and so forth. We also have the orchestrator orchestrator workflow.

This might be more um towards these agentic um uh or a a autonomous agents, right? That where the orchestrator orchestrator decides which agent, right? Or which LLM to to call, right? So, it's basically uh delegating dynamically, right? Uh to the different um LLMs. And then we also have uh another pattern called the evaluator optimizer workflow, which uh you call an LLM and then may there might be

another LLM that decides whether that response is correct or not. It evaluates the response and then we enter into this flow of re-evaluating, adding the uh evaluation into into the original prompt to repeat it if it didn't meet the expectations and so on and so forth. So, we won't be seeing any examples of these today, but I just left uh here, right? Uh some uh or a

GitHub repo which you can check where all these patterns are implemented with a Spring AI, right? So, everything is um in that repo. I want to focus more uh today on um a project inside the uh the Spring AI community organization. Actually, AI is moving extremely fast, right? And uh the Spring AI community was created to let anyone who has anything to contribute to the uh Spring

AI ecosystem to basically uh start a project. An examples of that could be the Spring AI agent core, so the guys from uh Amazon just contributed that. So, there could be vendors contributing their support for a particular LLM, but uh other stuff like uh A2A support, right? Or MCP security and things that are moving fast, but uh we cannot put into the the the core because, you

know, the release cadence of the core is maybe slower than what we need, right? Because uh AI is moving so fast. So, the Spring team is uh or Spring AI team is also using the Spring AI community to add all these projects as proof of concepts, uh which might then make it into the core. And that happened with the MCP annotations, for instance. And um today I'm

going to going to focus on this Spring AI agent utils, which uh will give us a bunch of uh utilities uh or tools, right? Uh which um allows us to even implement uh kind of a cloud code, right? Application. And I'm going to focus on on three of them. There are actually more, right? But I'm going to, uh, cover three patterns, the ask the user pattern, the

structure planning, and the skills as well. So, we start with the, uh, ask pattern, right? You know that when you send a prompt into the LLM, if you're not specific enough, it might guess, right? It might make assumptions of what's of what's next, right? And sometimes these assumptions might not be what you have in your head, right? You might have something different, but of course, the LLM

just moves on, right? And at the end of the day, it gives you the the result, and then you're like, "Ah, I don't like that, right? Let me just, uh, iterate over that, right? There's no way to to pause that, you have to wait, and, well, trust the LLM that it will, uh, make the the right assumptions. So, why not letting the LLM know that you want

to be interviewed, right? So, please ask me, right? If you don't know, don't assume anything, right? And that will give you a better response, right? Because, uh, yeah, the LLM won't make assumptions that, uh, you might have in your head, right? So, uh, this pattern is basically, uh, giving you or prompting or interviewing you, right? And giving you like a multiple questions with multiple choices or free

text responses, and then the LLM decides when, uh, to ask you, right? For clarification. And this is basically how it works. As mentioned, everything is, uh, modeled as an advisor. That's nothing more than a tool, right? So, the the tool calling that we have, uh, already covered is what we're doing here, and and we're adding a new tool called the ask user question tool. So, this is

part, right? Or that's that's basically part of the Spring AI agent utils, right? That uh, that repo. So, now, when, uh, you sent, um, a prompt to the LLM, let's say, "What are your countries to visit next?" Well, the LLM could, right? Uh, decide by himself, right? But probably, uh, in order to make a a better uh, decision, uh it needs to clarify some questions. So, it

will come back to you and say, "Hey, um could you please ask these questions to the user?" And this ask user question tool, it will uh be configured with a question handler. So, basically, how do you show these questions to the user? Could be in the console, could be in a UI, could be uh anywhere. And then, the tool will just come back to the LLM with

the responses, so the LLM can continue, right? With uh with the task. So, this is a quick uh quick demo on um on this. All right. So, as you see here, uh we're using the same uh chat client builder, but now we're going to uh specify this default tool, right? So, the default tool is the ask user question tool. Notice that we are defining this question handler.

I want to handle the questions uh by the LLM from the command uh we we basically use it the the same way we did it before. And so, let's um start uh this and see how it works. I want uh to go on vacation. Um where uh where uh should I go? All right. So, hopefully, it won't make a guess. And here you go, right? So, we

got some questions uh uh asked, right? it first asked about the budget. What do we want? Well, I want uh I don't know, a balance option. Let's say it's two. Now, we get another question, right? So, what type of uh trip do you want, right? So, you want to relax? I'm from Barcelona, I have enough beach, so let's go for uh adventure as well. Timing. When do

you want to travel? Uh let's say this year as well. Notice that with all these answers, and uh you can see here, right? Um the um the tool being uh executed, all these answers are going to be sent to the LLM, say "Hey, I you asked me to answer to to ask the questions to the user. Here are the answers, and now move on and complete your

your task." So, with all my answers, it has suggested Portugal, Costa Rica, Patagonia, Iceland, and so on and so forth. So, I guess that any of them would work at this time. So, next is the to-do right tool. as you know, the LLMs do struggle with complex tasks. Right? So, if you ask a really complex things, right, which involves a lot of tasks, well, it might fail

in completing all the tasks, the intermediate tasks, because well, the task is so so so big that yeah, probably it will skip or miss some of these tasks. So, what we're asking the LLM is to define an execution plan. Right? So, I want you to break down these tasks into multiple to-dos and follow these to-dos. So, for each items in the to-do, I want you to tackle

the item, right, and basically telling me that you are tackling that item, completing the item, and so on and and so forth. Right? So, that gives you visibility on what the LLM is doing. Right? So, it's not like I'm prompting the LLM and I'm waiting and I eventually I'm going to get a an answer back. I want the LLM to be responsible of the of the different

tasks and be able to um see, right, how far we are doing. And again, that's nothing more than another tool in um in a spring eye. So, this is the to-do right tool. And at the end of the day, when we send a we're going to ask the LLM to create this plan. So, we're going to keep asking the LLM to execute the items of the plan,

right, and for every single item, it will give us, you know, the the the progress, right, so whether it's in progress, whether it's uh and so on and so forth, right? So, uh that's basically what we see here. Uh we're going to tackle the first uh uh task, which is in progress. Uh this will get back to us, right? Uh because we want to get the um

um or show the user the uh the evolution of these tasks, right? So, that's why we can an event handler that uh will, I don't know, render the UI, show it into the console, and so on and so forth. So, every time that we move on, uh they will going to uh get a call. So, if we're in progress, we're going to get a call, then uh

we're going to get that this task is completed, and we're going to move on into the next task, and so on and so forth, right? So, we're going to repeat this over and over again until we finish with the particular plan. So, let's see that uh in action. Yep. So, again, this is nothing more than another tool that we define in our chat client. So, in that

case, the to-do write tool, and I'm going to configure this event handler. In this example, I'm just going to send um an event, right? Uh if you're familiar with the application events in Spring, you can send an event, and then you can register an event listener. That's basically a an in-memory event. So, you can register an event listener to react to this to this. So, when there's

an an event from the LM saying, "Hey, I have this in progress. I have this completed." I'm going to going to publish an event, and then I have uh down here um an event listener, which basically takes the the event and prints it, right? So, it will print the progress, right? So, if it's completed, it will uh uh write a tick. If it's in progress, it will

write that arrow. And if it's pending, it will just uh leave it empty. Great. So, let's see that in that in action. Right? And by the way, you can mix and match all these patterns, right? The idea here is that you use the user ask uh question tools plus uh the uh to-do um tool, and so on and so forth, right? So, you can mix and match

those So, uh let's say uh give me the best Then rate them and write report. Let's see if this breaks down this prompt into multiple tasks. As you we got three tasks, right? So, that's basically decided by the LM and we're going to keep track on the of these tasks, right? So, first we need to research the top tourist attractions, then we need to rate the attractions,

and then write a concise report with the recommendations. Um one thing to to notice here is that apart from the tool that I mentioned that the the to-do right tool, I just gave my my chat client another tool, which is the Brave web search tool, right? So, that basically gives the ability, right? To search the internet, right? To my to my tool, to my chat client. So,

we have here the first interactions. As you see here, we have multiple backs and forth into the Eventually, well, it has completed the the research. It will go and rate each attraction. Right? Blah blah blah. And then it will basically write the report, again, this was a really simple prompt, right? But the idea here is that if you give it a complex task, it needs to break

down the task and and have accountability of each of the tasks. Okay. Next thing is skills. And I guess that you have heard about the skills. Uh really popular. Uh what is a skill? A skill is nothing more than package capability, right? Uh in its minimal representation, it's just a markdown file, right? This could be this skill.md, right? So, it contains some instructions on how to perform

a particular task. But it could be more than this. It could be containing a could be could be containing references, assets, right? And you basically configure these skills under folder in your application, right? And those skills will be will be passed to the So, the the LLM might ask for a particular skill, right? If it needs it, right? So, if you go to HN skills that I

use that's the spec, right? You'll see here, you know, how to build a skill on the the form of a of a skill. But yeah, in Spring AI we have support for that. And we have a new tool, right? That called skills tool. Which allows us to use those those skills. So, notice that in our application you'll have a directory maybe in source main resources with a

skills folder. Each of the skills will be in in its own folder. It might contain a simple MD file with instructions, might contain uh more stuff like like scripts and so on and so forth. But the idea here is that those skills will be exposed, right? To the And the LLM decides when to use those skills like a simple tool call, right? So, we have here all

the available skills passed to the LLM. The LLM decides, "Oh, I need that skill." And the skill tool will basically look at the skill and execute the skill or actually use that skill and execute anything which is needed, right? If it's needed, right? And then we can go back to the LLM and complete the response. The idea here is that these skills should be reusable, should be

versioned, right? So, if you have a skill, you might use these a skill for your entire team, right? And you might want to version that a skill as well. There's an an an initiative called the skills jar, which allows you to package these skills in a jar file, right? So, you'll have here in that website a bunch of the skills already that might come from Tropic and

many other vendors that package as a skill. So, you can just take this and add it as a dependency into your project and use that particular skill. The good thing is that it's going to be versioned, that you can reuse it, and so on and so Okay. So, let's take a look at the at As always, we're going to add a new tool. That's going to be

the skills tool, and I'm going to specify where I have my skills. I need to define a directory, right? In my case, that's under resources, skills, and as you can see here, right? I have a bunch of the skills. The content research writer, docx, right? If I want to build a a Word document, a fact checker, the GH or GitHub CLI, if we want to do anything

with with GitHub, PowerPoint, and weather, and so on and so forth. So, all these are going to be added into the context as well. Apart from that, for this demo, I've added a bunch of skills more, right? Or tools more, right? So, the grep tool, the shell tool to execute anything on the shell, the file system tool, right? Which can execute or write or read from the

file system. I also added the smart web fetch tool to be able to fetch websites, right? The content of a web website. Notice that it it's um um basically yet another tool, and the brief web search tool, which allows us search, right? On the internet. So, if you think about agents or coding agents like Cloud Code, right? These are how they're configured, right? So, they need to

have access to the file system. They need to be able to search the internet, right? Fetch data from the internet, execute things, right? On the shell, right? And with this, you have a really complete agent, right? Okay. So, let's execute that. First of all, I'm asking the LM, "What skills do you have and how can you help me with my request?" Let's um the LM and here's

basically the response. I have these available skills, the content research writer, GLIC alive, PPD, which matches what we have in our project, right? Now, let's um ask something. I have prepared some prompts. So, the first prompt here is this one here. Get the random news from this website. I'm not sure if this is a reliable website or not, right? And what I'm going to do is I

want the LM to check if the facts that are stated in the news are true, right? I just want the LM to create a Word document and store it under a temp directory. So, my intention with this is a bunch of skills. The first one is the fact checker, right? So, I want the LM to first execute one of the or use one of the tools, which

is the um smart web fetch tool, right? To be able to Well, actually, first of all, this is search tool, so it search for for news, then it fetches the news, right? And it executes one of the skills, which is the fact checker. Notice that the fact checker is just an empty file and say, "Hey, you need to verify the information, blah blah blah." And it's giving,

you know, all the instructions on how this needs to work. And then, as I want to create a Word document, I want to execute this particular skill, right? So, this is a skill from Entropic. And as you see here, apart from the empty file, we have more stuff like a scripts. And that's a scary because that is great. Notice that it contains some Python scripts, right? So,

everything here will execute on your machine, right? So, you shouldn't trust the just because, right? So when you get a skill, make sure that um it's um you can trust it, right? Or execute it in a a boxed environment, right? So you don't have any any problems. Right, so uh with my uh request, uh you see here that uh we have a a bunch of tool calling

for web search. It basically uh goes on the internet. It might go to other websites as well. Uh like this one here to check for the facts, right? Uh going to other uh websites to see whether this is true or not. Blah blah blah, right? And eventually if I go back it says, "Hey, I just left the uh doc file, right? Uh here under temp." So let's

see if that's true. Well, here we go. We have this Sophia Globe fact check. So let's open that. Let's see what uh we And here we go. So that's our fact uh checker. So it selected two news, right? Uh this one here um from May the 2025 and this one here. And it's basically going to uh tell me uh whether these facts are or these news are

correct or not. Right, uh first actual article, second article, and um the end result which it says, "Hey, uh broadly factual and consistent with the official sources of corroboration." So basically these two news, right? Are uh correct. Right? But uh as you see here, we have used like multiple tools, uh multiple skills, right? Um so um it's basically, right? Uh doing what we uh intended. Right? where

are we? Let's try um something else. And that's the uh skill application. So I'm going to skip that one. Yesterday during the keynote right the organizer had mentioned that well, there's a hackathon, right? And um anyone who want to participate need to create a an application for the conference agenda. So, let's try to use agent, right? To build that conference agenda. And as you see here, I

just uh defined a problem. I'm a J Prime. We're at a hackathon and we need to implement a conference app include the agenda, speakers, and sponsors, and any other feature that you might be interested. Uh create a project from a scratch under temp. It needs to be a a progressive web app in a spring boot four visually appealing blah blah blah. And actually you could have added

the user ask tool as well. So, it could actually ask for for stuff, right? But we didn't do it. It's ongoing, right? And as you see here, it's uh executing some tools like a bash, right? So, it's executing some bash commands. It's executing some some other stuff. It might even um try to I don't know. Python scripts, right? And node stuff and all this stuff, right? So,

as you see here, we're using all these tools that we have seen and eventually it will come up with some um some projects. And as that it's already creating something under temp. All right. Here we go here. Uh well, that's basically what's being created. Yeah, and it's going to create the source and uh I'm not sure what um it's going to be created. It's ongoing, right? So,

we're going to leave it um doing its job, right? But as you see right, we're basically composing those skills, right? To create our agent. we're going to leave that ongoing, right? And we're going to move on. Next thing that we're going to talk about is sub-agent orchestration or the agent tasks, right? So, it's actually better to have like multiple agents with a smaller context, right? And maybe

restricting the sub-agent to the set of skills and tools that we have, right? So, we have now another tool or yeah, which is called that the task tool. And use, right? Or basically rely on the agents that we have in our application, right? So, an agent is nothing more than an empty file. So, we can define that basically does a particular task, right? So, when the LM

decides that we need to perform a particular task, it can spin up now a sub-agent, right? And execute that in parallel. And this agent will have a clean context, right? So, it won't pollute the context from the parent agent. And it will also have a set of skills available. Maybe we don't want the sub-agent to get access to the file system, right? Or maybe we just want

to scope, right? That particular task in a sub-agent, right? So, task tool will allow us to delegate to the sub-agents and that's going to be the autonomous agent, right? Delegating to the the multiple sub-agents when it's This is basically an example of a sub-agent. So, notice that it's nothing more than a markdown file. It has a name, has a description that's actually going to be passed also

or available into our LM. And you can define also the tools that it has available and even the model that you want the agent to use. So, sometimes you want a particular agent to use a cheaper model, another agent to use a more complex model, depending on the task that we want to complete, right? So, we have this multi-model routing for free, right? So, at the end

of the day, you can specify, "Hey, when an agent says that the agent that that model is Haiku, use this Haiku builder." Or Opus, use this Opus builder and so on and so forth. So, this is defined by the agent as you see here, the model Sonnet will basically use, right? Whatever is configured. Well, it's not here. Could be all of or It's going to be used

the builder with which we configure here. This builder might be configured with tools and so on and so forth. So, basically we have kind per agent configuration. Let's see how we're doing with the this guy here. Probably fancy which much um Well, apparently we have to um It has dependencies. Let's uh say that. But um yeah, let's give it um sometimes. But as you see here, uh

that it's basically creating right uh already our our structure with some index and so on and so forth, right? So, uh it will give us right a a complete application. The last thing I want to I want to cover is uh basically some some protocols and I guess that you have heard about MCP quite a lot here at the conference. Uh there are a lot of protocols

for with uh with AI. I'm going to just focus on two of them, MCP and HT way. So, uh MCP allows us to uh basically use any tool right uh which we might not even implement, right? So, at the end of the day, um I don't know. Imagine that GitHub right has uh um some some tools and want to be exposed. Well, they will be creating their

own MCP server, so you can use that MCP server without writing the support for GitHub for instance, right? Spring has support for both of them served for for the MCP clients and from the MCP servers. Building an MCP server is as easy as uh using any of these annotations like MCP tool right and uh the MCP protocol has other um concepts like uh resources and prompts and

elicitations. So, everything is uh uh supported by by the Spring AI integration, but uh we have uh both sides, right? We have the client side and the server side. So, this will allow uh basically consume any external tool um that you have. And that's basically uh kind of the uh the architecture that we have. Uh you'll have your your application. Your application will be the MCP client

and uh will basically consume, right, an MCP um from an MCP server, right, which could be a local, right, so the transport could be a standard in, right, a standard in, or it could be like a remote, right, and we can use a um other forms of communication, right, for those uh remote uh servers. And then the land, the last thing is uh agent-to-agent communication. So, again,

what we have seen, right, that with the subtasks and subagents are basically agents which live uh within your um your application, right. Uh so, your application decides when to spin up another subagent. But what if someone else builds an agent? What if we have uh another remote agent? Well, we can use the A2A uh protocol. The support for A2A is under the Spring I community. I just

left the the link down here, right. Uh and if you want to see some examples, you have the the link down here. And eventually, right, it will be added into the um into the into the core. But again, as we're moving really fast in the AI space, a lot of this support is first added into the AI community to test it, right, to to make it available.

And eventually, if it's mature, if it makes sense, it will just make it back to the to the uh to the core, right. And the way this A2A protocol is uh is working is that uh every agent will expose its capabilities, right, through uh a well-known um uh URI, right. So, if you are familiar with uh OAuth 2, for instance, right, that where you can discover different

endpoints, right, for the auth provider, this is really similar, right. And we'll have this uh dot well-known {slash} agent card JSON, and that's where the right, so its name and what it can do, right, and the different tools that it uh it can use, and so forth and so forth and so on and so forth, right. So, we're going to um initiate the conversation, right, uh at

uh or actually send a request, right, And basically get the with different protocols, right? So again, right? Uh we have the two options. We have either um the support for being a client, right? So the A2A client or the A2A server in a Spring AI. But uh you can of course with A2A client consume any agent which is available, right? They're not even written by us, right?

Which is the the part that we have below here. So if someone implements a Python agent and it's compliant with A2A and it has this uh agent card, we can actually use the A2A client from Spring, right? To consume that particular agent, right? And that's basically the real A2A communication which might live uh somewhere else uh implemented in a different language and we can interact with them

all those uh agents, right? that's it from my side, right? Uh hopefully you have now a clear vision of what Spring AI is, a little bit about uh what's coming next, right? In the in the next releases, a little bit about the Spring AI community, uh organization and projects involved in there, and the different patterns and tools that uh we have available to build these agentic workflows.

So thank you. If you have any questions, I'll be around uh here, happy to take