Comparing Agentic AI Frameworks for Java by Timo Salm / Sandra Ahlgrimm @ Spring I/O 2026

This talk discusses the comparison of agentic AI frameworks, focusing on three main technologies: Spring AI, LangChain for J, and Imbable. The speaker explains the concept of AI frameworks, particularly emphasizing agentic AI frameworks, which allow large language models to guide interactions and decide on the tools necessary for task completion. The session includes an overview of key concepts such as prompts, tokens, and retrieval augmented generation (RAG). The speakers highlight various implementation techniques, showcasing a sample application that includes features like user profiles and seasonal ingredient recognition, while comparing the strengths and weaknesses of the discussed frameworks in handling agentic AI patterns. Overall, the session provides insights into the evolving landscape of AI frameworks geared towards improved development experiences.

[music] >> Hello and welcome everyone. I'm so excited to be here. It's my very very first Spring I/O. Who else is the first one? Yes, I told you I'm not alone. No. So, I'm also not alone here on stage and we're going to present on comparing agentic AI frameworks. And we will first look into a bit of the concept, like what is an AI framework, like what

is an agentic AI framework. We will not cover so much of the basic about the AI frameworks itself since we do have another session. We already gave bunch of other sessions for those. I think they're also here and also you can find them later. We have linked them. So, first some introduction on agentic AI frameworks and then we're going to dive into a bit of code. So,

we have built the same sample with Spring AI, with LangChain for J and with Imbable. Yeah. I think that's the correct way how to pronounce it. yeah, I'm very excited to be here as I said. We also compare those three. Obviously, it's based on our user experience, right? So, it's how we feel about it. And yeah, we show this so it should be pretty open. My name

is Sandra Argüelles. I work for or I'm the main responsible person for developer experience on GitHub Copilot as well as Microsoft Foundry. So, I work for GitHub at Microsoft and I'm here with Timo. My name is Timo Salo, working for Broadcom. In my job, I'm trying to help my customers be successful with our products like Spring, RabbitMQ, Bitnami and Tanzu Platform. Great. So, first let's talk a

bit about the glossaries. So, first off, a prompt is whatever we put into our machine with the LLM, so large language model or small language model and then there we do have our tokens inside. A token is just a subset of characters, so can be a single character or word. So, whenever you work with AI, what you get back is just the next token, right? So, very

limited abilities in terms of, you know, it feels like it would actually think. But then always keep in mind it's just statistics. It's based on the most likely next token. That's what you get. So, for instance, I put in Barcelona is and then the next token will be bye-bye and here. Each LLM or small language models has its context size, context length. So, whenever I work with

something, I feel most of you have already experienced the token limits. Right? Yes, most hands up. So, that's what it is, right? So, when I have my you also see that the more expensive ones usually have the bigger context size, so they can keep in mind more things. If that's actually good for our business use case, another question, but that's where it's coming from. And then there

are multiple patterns that we can use and architectures such as RAG, so retrieval augmented generation is built on you know, because I can't put it all in the context, I will first Oh, yeah, I am actually enlarging my context. So, my LLM is already pre-trained. All the models are pre-trained by the Yeah, by the companies building them and then they're hosted somewhere and then if I want

to enrich the data, I can use something like RAG. So, I will basically put in my business context, my business data. It will be put into um vector store. vector store and then based on Yeah, and then the context gets enriched and then I can also retrieve the data from there and that's how I make it possible that based on my business data, I get the relevant

results. Very important whenever we're talking business since, you know, when I'm a car manufacturer and the customer is asking what's the best car, obviously about my car and not anything else, And then if I need up-to-date information, I use something like tools. So, tool calling, like for instance, where I'm currently, what's the season or what's the weather. When I need up-to-date data, I would use tools for

this. One note here, tool calling is at the end the more or less a foundation of most of the features we see with AI agents. So, it's a pretty interesting and powerful um capability of the large language models. So, we started with the standalone LLMs where like 2 years ago everyone was like talking about prompt engineering and how we can fine-tune our apps where we just, you

know, kind of automated natural language tasks. So, I would say like give me a summary. You know, give me a bullet point list or write my emails. Best feature ever, right? Write my emails in a very nice American way, not the German straight way. Really saved my life at work. And then we move forward with the RAG as I already explained where we had the vector DBs

and embeddings to get into the business data and retrieve less hallucination. Then as Timo already mentioned, next big step was the tool using models. So, we can call the tools and use them. Next step right up would be the multimodal multimodal models where I can have one model which is which can do multiple things like generating images, also giving me the text and also the speech or

audio in and output. Which brings us to the last step which would be the agentic AI systems where you can, you know, using MCP, you can do orchestration, use memories, so you really have the end-to-end automation. What we will explain more now. But first, yeah, what was needed to get there was the MCP. So, when we had the whole agents thing and tool calling and everything was

there and then we kind of needed something like a baseline how to talk to each other and that's when Anthropic came up with the model context protocol which was really like the needed step especially as a Java developer where I'm used to standardizations. We needed some sort of protocol here even though one might argue if it's a real protocol anyhow. So, that's the step here and then

Google came up with the agent-to-agent protocol that allows like AI agents to speak to them themselves by determining themselves whom to speak to. And that this was given to the Linux Foundation. Okay. Perfect. Yeah, it's me. So, yeah, maybe I can start. So, thank you for all the different like topics. Hopefully, you're able to understand now a little bit more like what we're focusing on here. I

think we're focusing on agentic AI. So, what's the difference to the traditional like generative AI applications we built in the past? There like the application was responsible for guiding most of the interactions with the large language model, deciding which tools to use, whether to use retrieval augmented generation or not. The difference to agentic AI is that a lot of like this Yeah, deciding so which tools to

use in the in the responsibility of the large language model. So, we're giving the large language model a lot of power in deciding which capabilities it needs to fulfill a task. And in in agentic AI, the idea is as you already saw that you not only have one agent making the decision, so attaching a lot of tools to a large language model. Also at the end having

multiple agents specializing on specific aspects and connecting them and with that you can imagine for those people that for example use Open Claw what's possible. So, I think it's we cannot imagine what's possible or will be possible in the future. Before we start comparing like for agentic AI, we first have to learn about like what types of agentic AI or agents we actually because that's a huge

focus. In general, a lot of the concepts you will hear about, they are based on like those people that are really on the forefront. So, usually the providers or yeah, implementers of all those AI models, Anthropic for example, OpenAI, Google um first I think see the limitations and then also because they are like the implementations or the trainers of those big models, they have the control to

add new functionalities I think a lot sooner than other companies. And um at the end it's all about limitations. So, if we have a large language model, of course with tool calling we can attach 100 tools with MP CP servers for example from from uh GitHub and other from from Jira, etc. We have hundreds of The thing is that we have this limited context size and the

tokens that you send to the large language model are not only like limited by this context size or the amount of tokens an application can accept per request. Also, on the other side, tokens are the currency of AI. So, it's at the end it's like the price is per token which means you shouldn't send hundreds or thousands of tool calls every time or the meter data for

that tool to your And therefore, there are a lot of concepts to mitigate that and we will see some of them today. And one of the fundamentals about it is also how you actually implement your AI agents. And there are two currently ways. So, they are coming especially this workflow one, also an idea from Anthropic, that you still control a lot of like the process of um

a specific task via code instead of letting large language model decide it. Um and those are the workflows. So, the benefit is they are predictable. They are more or less in code. Um and then uh you have the specific paths, you have specific patterns to actually then um start your large your agents doing a specific task that's really limited in a way because we also learned that

as more concrete the task is the better the goal. And then there are things like goal-oriented um processes etc. to really get to that what you want. On the other side, of course, if you put everything into the the the the large language model or let the large language model decide um what to do next and um really giving all the flexibility, the benefit for you is

at the end that um it can handle a lot of tasks you for example maybe don't have the tools for something you didn't implement yet. Um so, it provides you a lot more flexibility, but as I said, with a lot of risk also that you will get something maybe you didn't expect and especially on the enterprise side, you can imagine that's also something uh from a security

perspective not optimal. Here are some of the workflows patterns as I said, they are coming um from Anthropic like the initial definition. Of course, there's nothing like completely new. Um but yeah, they um wrote a nice blog article about that. And um the easiest of course is prompt chaining. So, instead of putting um everything you want in one big prompt that you split it and then it

will be sequentially um executed. So, step by step that you always see, okay, this is the output. I validate it, send it to the next step. The other one is parallelization. Of course, if you want to uh want to do uh like a more complex um task and uh those all those different steps, they uh don't each other or agents, you can parallelize them. Another one is

routing that you for example, if you have uh specialized agents with special models for example or special prompts that based on specific criteria, you send like a request to one agent and uh then to another one. Orchestrator workers are um a way to actually let in a way or involve the large language model in the planning, stripping down a bigger task into smaller task. And uh orchestrated

to other models and then uh this is also why there's an image for that. I think uh something really um already usable and valuable is the evaluator optimizer. The idea is that if you um send a large a recursive large language model, often you get a uh yeah, hallucinations especially if you're not like have those big models with for example what we need for enterprise uh development.

Things like structured output that you want to have a JSON response, the JSON is invalid, all those things. You have to resend it. Of course, you can also do that with for example Spring Retry and things like that. But wouldn't it be better if it's not just like easy things like uh the JSON is incorrect to ask a large language model about that? And there are special

models that are um better than others in doing the evaluation. So, at the end you get a response. You have another language model evaluating the response. If it's not valid, it will um rerun the same call and do that like you can define of course the maximum as long as there is no valid result and if there's a valid result, you will get it back. Of course,

this can take some time, but it's really powerful and for those that are already using Spring AI for example, um that's heavily used within uh like internal components. Like for example, structured output, um doing those loops um for you to always resend it there. Okay, and with that it's time to have a look at our sample app. So, I love to use conferences to solve my real

life problems. So, especially the demo apps. So, in the previous versions, we already created a recipe finder to generate the so like you know, I don't know what to eat and then I want to know what I have in the fridge and then it should generate the recipe because I really can't cook, but I can follow recipes. That was the idea of the first one, but now

I need to go one step ahead and do a weekly plan. And since I like have kids, I need to also take care of nutrition and then it should have like for instance my profile. So, we added a login. I can sign in here. Maybe you have to refresh. Yeah. Maybe after refresh. I love live coding. Okay. So, and So, I log in, then I get my

user profile and she realized what I am currently. We should also get what's the seasonal ingredients. So, where am I currently? Because you know, based where I'm at the globe, it's a different. And then I can do the login again since we lost this. So, now I'm logged in. Can see here this one is the LangChain for J1, but we will not show everything since uh I

keep the DE since I heard we have mostly Germans in the room maybe. Okay, and then it will generate the plan and the way it does it is we get first what are the seasonal ingredients as well as other agents we are starting. And then we go into the validation which will call the generate weekly plan like in a loop. Get you know, the output of the

other agents and then it will generate my weekly plan based on what I have for instance in my fridge with tool calling, what's the the season, what is my preferences that I might have put into the additional instructions and then at the end I should get my weekly plan output it. Yeah. So, here we have it for 2 days already. So, here's my Monday plan and the

Tuesday plan for instance. Pretty straightforward. One note here, it looks like, okay, that's something I can do with one prompt. Of course. But the thing here is the validation. So, it's like we have those user profiles, if there are allergies etc., that's like in the code in this case mocked. It will do the evaluation maximum calories based on this evaluation loop. So, it could be that it

takes 10 large language model calls to get to a result. Um because yeah, in this case it's important for us uh if we care about our nutrition and um yeah. Yeah, it really helps me also to like streamline all the voices in my head which is like, can I do noodle it again? Oh no, the nutrition facts won't be good enough. So, I was really happy to

have this like out of my head and in a uh good workflow present. Yep. Okay. Yep. And that's the next one. Okay. Yep. So, start. >> um yeah, let's now have a look. Sandra already mentioned what we will have a look today. So, we are comparing three frameworks um related to agentic AI capabilities. As she said, we have a similar talk which is focusing on like the

core capabilities of those frameworks. Um first one Spring AI uh enterprise support by uh Broadcom um was founded in 2023. The next version is um the 2.0 which will be released in May. Um with that we will get a lot of new features and Spring Boot 4 of support which is of course amazing. And um yeah, that's about Spring AI. Yeah, LangChain for J was the first

AI framework for Java developers initiated by a single person, then uh presented at Devoxx I think 2023. Very quickly major companies such as Google and Microsoft, also IBM, Red Hat put their effort on this one. So, very community driven. Um now the inventor has got hired by Red Hat, so it's now a bit more under the IBM umbrella. You can also see this with a lot of

things first being implemented in Quarkus that may be coming into LangChain for J later. But I like the fact that it's framework agnostic. I can use it with whatever Java I want even though being at Microsoft having a bit of access of like what's used in And who's using LangChain for J? Obviously it's 80% Spring. You know, it's it's there to be built also with Spring and

why not? And I'm super happy to finally sneak it into Spring IO because I tried multiple times and this year was the first one being accepted. Perfect. So, our next one is Ambaival. It's a framework really providing a high abstraction with all those patterns we saw. So, that's the focus of the framework. Um it's actually founded by the uh or one of the creators of Spring um

Rod Johnson who's also here. So, feel free to reach out to him. And um actually this framework is built on Spring AI. So, it's like it's using all the abstractions from Spring AI, but putting an abstraction on top. Of course, there are more like agentic AI um frameworks for Java like for example, Cook from uh JetBrains. This will be the next talk in your in this room.

So, if you are interested in Cook and see like how it compares to the others, feel free to just uh stay in the room. Before we finally jump into the code, uh we have to uh talk about some concepts. Um and um as I said, every of those frameworks, they are handling like how they implement those different agentic AI patterns in different ways. already like from, I

would say, the the initial version is coming with a so-called advisor API. For those that are not familiar or too familiar with AI or large language models or AI providers, at the end, all those calls that you do to the large are to a REST API, which means that, of course, you can use the capabilities of any framework of your tools, curl, etc. to interact with those

models. And of course, it made a lot of sense also from a Spring AI perspective to use the same context, the same experience that we know, for example, from REST clients, because it's also for REST calls. It's just some wrapper around it. And what you, I think, already did in the last 10 years, uh and longer, is like intercepting REST calls. And that's more or less what

the um advisor AI is doing. So, you can intercept at every step of the call and the chain to the um for the request and the response, and add functionality. A good example is retrieval augmented generation, where you add additional context to your prompt. And that's something in Spring implemented with a, for example, the naive question answer advisor. That all this flow, like reaching out to the

embedding model, to the vector store, getting the data back, that's all completely abstracted away by by this And the great thing is, it's not only for building functionality. You can more or less build everything with that um you can imagine. Okay, um the screen will go off, but uh yeah. >> [laughter] >> And uh there's another concept and new one which is called a a recursive advisor.

And what's special about that is that you can copy the chain in a way, so what's downstream. And with that, you really are able to enable those, for example, evaluation loops, etc., so that you can add some logic as a specific place and then run and uh validate them, run them again until you reach to a specific goal, and then the next one in the or behind

you in the in the call chain will be called. So, that's really an amazing and impressive uh functionality. And as I said, there are already some of them implemented in Spring AI, like, for example, the structured output validator or also a cool tool a tool call advisor that's in addition to the tool calling that you have natively with some benefits that it can, from a usability perspective,

etc., incorporate in this tool advisor chain. So, now it's finally uh time for some As Sandra mentioned, at the end, it's like we built this sample with the all three frameworks, and um we tried to do that in the same way. So, the samples are pretty similar, and I will only show the relevant classes here, because, of course, it's a simple uh demo app, but it's a

demo app, so there are a lot of domain classes, etc., that don't have any relevant logic. In this case, if you're familiar with Spring AI, you should be really like be familiar with the code I show you here. The thing is, Spring AI doesn't provide It provides a lot of capabilities for agentic AI, MCP service support, for example, um tool calling, of course. Um a lot of

things that are actually on, I would say, experimental supported, so on Git repositories, there are also a lot of blogs about that available. Um therefore, it's not like that you have an additional higher abstraction for those different different capabilities, at least not until the next version of Spring AI. We will introduce some more of those advisors that do more advanced capabilities, like, for example, what you will

hear, tool search. That's one that you don't like expose all the tools. You have a tool that says, "Hey, if you would need a tool, uh call me, and then I will expose relevant tools to you to actually save, for example, token size." And if we have a look at the um uh at the implementation here, if you may remember the diagram that we had, the first

thing we do here is um that we want to start a workflow. So, we want to have a parallel one. We want to fetch the user profile and the ingredients, because they don't uh need like um any inputs from each other. And that's something I completely built at the end uh manually, because we have everything for that in Java. So, you don't need something special. It's just

like running two things in parallel. It's just like, as you see, how you would implement it in standard Java running two processes. But that's what I mentioned. With all the tools you have, you can more or less implement any of those workflows. You just have to do it yourself as long as not production uh or enterprise ready available from the Spring AI team. But let's have a

look at something more interesting. So, you can see, we have this parallel workflow, and then it will get interesting, because now we have this loop. we think I can also see the uh agentic AI or or the interactions with large language model here with the chat client as we have API from Spring AI. Um As I said, if you're interested in that, I think there are a

lot of other uh talks about Spring AI and introducing the capabilities. But the interesting thing is really here. So, that's like this um loop, as I said, and it's only implemented via this one advisor that I created. So, a recursive advisor. That's something I implemented. I also implemented in a way that if you want to try it yourself at home with a different project, it's relatively generic,

so you can use it. You see some default instructions, "What you want, please create me the meal plan with uh some um here structured output." And then, if I have a closer look at how that's actually implemented, we can see it really looks like the example I showed. So, um we have this advice call. We have um like intercepting there, doing this call, and then running a

validation whether the response from the large language model is actually valid. And that's something I provided as an function. So, there is another large language model called via the chat client API. And then, at the end, if it's valid, I will just return the response from the chain. So, at the end, then it's like, "Fine, I will get my result." If it's I will do, and that's

the magic of this recursive advisor, as I mentioned, that you copy the chain and being able to run this loop again. And you do that as long as actually this condition here is is true. And you can see, I have some default prompts, "Please uh revise the response." I'm adding this responses then again and again with this validation feedback, and therefore I have a completely generic um

validation loop implemented within Spring AI. The code is available, so you can have a look. And um that's more or less it what I want to show here. So, it's like, with Spring AI capabilities, tool calling, etc., it's it's possible to implement most of the current capabilities. my colleagues, like Christian, they have blog posts available to do, um for example, AI skills with those uh um advisors,

etc. So, it's really powerful. Feel free to have a look at those examples to be better like able to to um see what you can achieve maybe with those capabilities. And as I said, the team is we work on providing more and more of those production enterprise ready uh advisors. Let's move on. Yeah. So, Mario Fusco from IBM Red Hat introduced the LangChain forJ agentic module. As

you've seen, it's uh Timo had to create the code himself, and Mario thought it would be cool to have this abstraction already in LangChain forJ available. So, he introduced that module, and we're using it here. you know, agents could be defined as AI services with the at agents, and here we are going to use the same thing. So, like, first we had to introduce the interface with

the nutrition planner, and then we have here the at agent with the output key and description. And as a Spring developer, I felt some namings were a bit interesting. So, for here, we have this at V for ingredients, which is like implementing this agentic uh way of things. So, yeah. So, first we have here the create meal plan, where we get all the ingredients, for instance. we

had to use the agent builder patterns again. So, we would uh get them from our class, and then add the chat module and build the things. And what I love here is that we can mix and match. So, like, with the agentic services, I can use the sequence builder, put in the here the nutrition planner, and then add my sub agents, such as the ones to get

the seasonal ingredients or the weekly plan creator or the validation loop. You create them first, and then I can just add them like that. So, that was pretty simple in the code. So, why don't we have a look? I think yeah, code is next. Great. So, are the agents and just for simplicity we put them all in the same class. Obviously first I coded it differently but

to show it here easier that's how we did it. So here's my interface where I can put everything in here and you can also see here's the LangChain4j imports with the V U service. So here I have my user profile, month, country for instance and then here you can obviously have your prompts in a different finder as a different file but just for simplicity we have it

where you have your user message, the agents and then here you basically define how how the interface for your agents are looking like. In order to use them in the in the way here. So here we first define our different agents like the seasonal ingredient agents um with the things we just have seen in the interfaces and then when it becomes interesting is how we add tools

which is the dot tools thing, added the weekly plan here so it has it attached and can then do the loop in the next one. Yeah, here in the validation loop where we can then, you know, define how many iterations I want to have because always keep in mind it's a workflow, it's consuming tokens so I would want to make sure that it's useful, right? I don't

want to use AI just because I want to have like my defined work stream or workflow how to use things. So here I defined it should just go three iterations. If it's fine with the nutrition it's good but otherwise, you know, have an end defined. That's the lessons learned hard way for me here. So yeah, also I have the exit condition so if it's good it can

also stop doing So once the validation is done. And then here the real magic is how I do the sequence builder here so first I want what's the seasonal ingredients, right? They have to wait for the other output. And just as a thing so LangChain4j provides so many more agentic patterns already. I think Mario implemented like everything that's possible almost. Uh we just used here the ones

that were useful for our use case. So that's why we have only implemented those. And then here it's building it and then it will basically just give me the nutrition plan back here as that. Pretty simple. Okay, so uh yeah, we saw Spring AI providing all the capabilities of course to build those patterns but uh not yet providing like too much out of the box of those

workflows patterns for example or more advanced tools. They are all like experimental available but not yet a GA. but there's more at the end. So after large language model already providing high abstraction there is even higher abstraction provided by uh Imbable Bable, sorry, Imbable um which is really focusing on all those patterns. So uh there's a lot of like effort put in like how to best design

such a framework and it's focused on some core concepts. So really like the planning is a huge focus and you can see that um even there's no large language model used for that, there's A* search so also like an AI search algorithm used to for the planning and the planning will be done after every step so will adjust based on the output which will of course help

with for example validation loops etc. And also then at the end as I said it's the defined really on this uh goal plan planning, we have different type of annotations or um yeah, objects like for example goals or conditions and another thing is really that it's focused on the domain model. So here it's a lot about like um the underlying I'd say uh platform of the framework

deciding what's next, how the different domain models are connected etc. It's for example also possible to um with structured output etc. to define something based on really the domain models you're sending to the model and getting back to do also a lot of orchestration for example Spring AI just leveraging at the end uh large language And um yeah, let's have a look at the sample and you

will see it's completely different to the others. Not like from how it's implemented but like how it looks. Um at the end the first thing is that I also have annotations to define an agent. An agent is at the end here also the concept of running multiple steps. Of course it's possible to have sub agents so you can also then more like split those if you'd like

to. And then we have different concept. You see for example here's an action so that's the fetch user profile and um at the end the name is a little bit strange because of the fact that uh I also expose an MP MCP server from here and there is no user input so therefore I had to create two different methods. But it's like the only thing how I

connect those different uh methods is by the input. You can see the input here is user. The user is available in my case because you saw the login so it will be sent via just like my UI or the the rest controller. Then the next thing is for example I see the fetch seasonal ingredients. There the input is a weekly plan request which is I also get

from the user. The AI is just the interaction so an abstraction on top of the chat client at the end or the capabilities of Spring AI to interact with models or initiate large language interactions. Which means that this planning I mentioned will be done with A* search is actually then deciding based on those inputs whether they are available what's the next step and because I have the

input for the weekly plan request um it will uh fetch the seasonal ingredients and return them and you can also see the output type here. So if we scroll down we can see now we have the weekly plan request, we have the seasonal ingredients, we have the user profile so it can execute the step. If it would be like not possible so there's something missing and there

is no step that can provide that at the end the the you will get an exception that the agent was not able to find the next And with that at the end um we are also able to implement those really more advanced patterns. The thing here is if I have a loop there is an additional concept because um at the end I maybe need an additional input

for example because I have this validation. And on the other side I want to run that again and again. How can the agent decide because it's always like okay, I have those three inputs, I need them again. How should the agent decide where to go? And for that we have these states and the states is something where you can then for example um define agents in those

different states like here for example return new revised plan. This will rerun um the step but if I have done weekly it will go to this one here to this state at the end with done weekly. So you have an additional abstraction to in a way add additional information also for conditions etc. to decide or run those different loops etc. And um it also has the concept

of personas so everything you may know like okay, then there was this article about okay, you can get a lot of better results if you define personas in your your prompt. So I'm a nutrition expert and stuff like that and that's all what by this high abstraction is actually provided out of the box. We can see that if I scroll up a little bit um with prompt

elements for example persona recipe creator that's just an additional prompt but has a persona name and we can for example also based on that decide between different large language models etc. that I use. Another important thing I want to show and it shows like how much it's oriented around all these different articles about how to build uh agentic um uh AI um or agents at the end

is um that if we go to the weekly plan here we can see that there's for example an unfolding tool. This is what I already mentioned. At the end I don't want to send hundreds of tools to my large language model because all of them have meta data that will be sent to the large language model reducing my content size and at the end it's also like

a lot of tokens that will be consumed. The idea of that is um a little bit different to like this the this uh search tool which I mentioned with which is or will be implemented also by Spring AI. The idea here is really also that you only provide one tool to the large language model or multiples on this high abstraction like here maybe provide a prompt that

it should provide different categories based on which then you only select tools that are relevant and send that back and with that you can save a lot of tokens because you're not sending all the tools and you also have a lot more control which cool tools should be called for which purpose. And in the end for those people that are asking like okay, how does this work?

How do you initiate it? There are multiple ways also depending on how you interact with this. This year is a web application and also available as an MP MVP server. It's also available as a shell to build your like plots code or something like that yourself. Um but for this interaction with the controller at the end you're building this agent invocation. for this uh return type, the

weekly plan, which is the return type of my agent in this case, and then I'm adding the inputs that I got from the user. And the thing is also for this initiate uh initiation of this agent flow, at the end there's an I involved finding like those agents that are relevant for those inputs to start them and then run through. Mhm. Okay. Um That's it actually about

those three uh examples. As I said, they're all available as code. Feel free to have a look to see the differences and experiment yourself. >> [snorts] >> Sandra already mentioned, this is like current state and also the colors, etc., don't really reflect like, okay, it's uh perfect and the other one is like um yeah, room for improvement. It's really current state for example for Spring AI. With

the next version, uh several of those capabilities will be provided, but also as I said, the focus is a different focus of Spring AI. It's more about providing those core patterns um than like providing this high abstraction than uh Imbueable, for uh where it's really about like, okay, I want to orchestrate those those agents and shouldn't care about like those lower levels of abstraction. So, that of

course gives you a little bit less control in what you want to do or flexibility, but um yeah, helps you probably with uh uh achieving your goal a little bit faster. If we have a look at those capabilities, of course, they are not complete. So, that's just like what we saw, what most of them actually provide. We saw a lot like focus here on the deterministic uh

workflow. One of those reasons is also because that's one of the most mature ones. Others, like for example AI skills, so uh there's a lot of experimentation on that and yeah, it runs, but of course, if you would run that on multiple environments, operating systems, etc., as it will run maybe script in this environment, I'm not sure whether that's really production ready. It's just like it works,

it's possible. And for example, a huge um I think um yeah, innovation driver will be also this human in the loop. So that the agent is able to get back to you to get some additional feedback. You know that for example from Cloud Code, it's running then it's like, oh, I need some more information. Also from Copilot, of course. Sorry for that. No worries. Um and uh

yeah. Okay, for LangChain for J, so this one is only for Spring developers meant, right? So, this table is since we are Spring IO, it makes most sense. So, dear Quarkus developers, don't get offended. I know in Quarky words, they do have the HTTP server support also for LangChain for J, but here we are at Spring IO. That's why we're focusing on Spring. And also documentation-wise, it

it means like as a Spring developer, I don't see as much documentation as for instance uh for the agentic AI workflows as for Imbueable, for instance. That's how we came up with the colors. It's a community-driven thing. For me as a Spring developer, LangChain for J is still a ease of use. You just have to keep in mind for instance, if you add your business or your

company's features such as we did with the like my boss Julien Dubois, he added the official Open AI SDK also to LangChain for J. He forgot to build the Spring Boot starter for it. So, I did that yesterday, it got merged. So, with the next release, so we also get the auto configuration for the official Open AI SDK to be using as a Spring developer. So, for

the for our app, you see it on GitHub. I had to do the configuration myself, which was a bit of a yeah, well. Obviously, when I look at Spring AI, they will always have the Spring Boot starters in place since it's like Spring first. So, that's basically the difference here. But we do have the um abstraction layer and ahead as I said, we do have the agentic

patterns already implemented. I can use them also with all the cool things that Spring provides for me like the profiles for instance, we use a lot when we switch between the different model providers. By the way, I also used Ollama for this. Uh doesn't work as good on GitHub CodeSpaces, but very good on Mac now since they enhanced, you know, the the speed here. So, so you

can try this out totally also on your own machines if just bring a bit of time since you know, each LLM call will add some time. So, we have seen it in the start that it takes like a minute or two to get the result and for Ollama, it's like 2 minutes more or less. Yep. And Yep. Yeah, I think that's mainly it. >> Last but not

least, uh Imbueable. As I said, it's like 100% focused on those patterns. Therefore, it of course implements all of them. Also noting is that Imbueable is not GA yet, which means they come like innovate a lot faster than for example Spring AI, which is under enterprise support. So, we have focused a lot on bug fixes, etc., not only like trying the latest and greatest, even if like

my Spring AI colleagues, they are like if there's a new artifact for Anthropic, like a few days later, they have a prototype of how to implement it in Spring AI. Um Imbueable here, of course, even if it's true everything is green, it has everything, but for example, the AI skills was just added with a release. I think it was released yesterday or the day ago, the first

version. Uh as I said, because it's a little bit critical, it will run code in the container uh in a way um because AI skills are about uh scripts that you have, instructions, and um yeah, therefore I think it's also from a security perspective something it's nice to use for testing, but not for production, it's the best idea to directly run that. No. And um yeah, I

think that's it. Um here just like to reference for those people that didn't have the chance to have a closer look at Spring AI or a comparison of uh Spring AI and LangChain for J. So, the core features, um those are two talks we have and of course, there are the demos and the slides in GitHub, so you can also have a look. Those are both uh

focusing on this recipe finder, so grading recipes, showing retrieval augmented generation, tool calling, and Sandra has also those apps running. Do you want to drive them all? >> for the next weeks, you can use them today. Timo already pointed out that it's using my AI tokens, so uh don't go too much, but feel free to use it anyhow. And uh yeah, I will turn it off like

tomorrow just to be sure here. And last but not least, here's also the QR code for the sample. Yep. On GitHub. With like those three implementations, of course, we will work on keeping them up to date, even it's probably a lot of effort having like three of those frameworks trying to get the latest and greatest uh in uh as features. Since we have like 2 minutes left,

we have time for a bit of questions. I bring stickers, Timo has those cool magic cards where you should collect one of each Spring speaker. Yeah, I think they need 40 41 40 cards and then you get a prize and uh I know also the new book from my colleague Daniel about like testing with Spring applications, there's also I But those will be provided randomly as far

as I remember. Thank you very much. Enjoy the rest of the conference. Yeah. >> [applause]