Experiment Agentic AI patterns (and MCP) within your own workloads, Arnaud Jean

In this talk, the speaker discusses the evolution of programming paradigms and how they lead to modern software development techniques, particularly in the context of agentic AI. He emphasizes the importance of design patterns in developing AI agents, leveraging tools such as Spring AI to implement these patterns effectively. The session covers various architectural patterns, including mono, graph, orchestrator, and swarm patterns, and how they can influence the structure and functionality of AI agents. Through practical examples, the speaker demonstrates how to create a snake-style game using these different agent architectures, highlighting the benefits and trade-offs of each approach. The speaker also discusses the significance of precision in prompt design when interacting with AI, referring to RFC standards that can enhance communication with AI systems.

[music] Okay. Okay. So, now comes the most tough time of any conference to listen to a talk after lunch. Yes. So now um how you say the the biggest issue is you not to sleep and the speaker not to speak not to sleep during his own talk. And yes please take your seats. By the way uh when you come from that part my left part of this

of the of the hall there are still places here on your on my right. So your your left part. So please don't state uh don't stay because we will have issues with the fire department. So great pleasure. I hope you like the lunch. And now I want to introduce you the only speaker with two first names. [laughter] Yes. Jano who is also the J Prime representative of

Keanu Reeves and John Week. Yes. And uh he's do going to do as he said he likes experiments. He likes crazy stuff. So uh I think that's going to be really not a sleepy but truly crazy talk. Jano Mercua. >> Yeah. And enjoy the talk. >> Okay. So a talk after lunch. Indeed. I would say I don't know if you have drinks or uh whatever in your

mind in your in your hands but sante in French pro in German or naz in Bulgarian. Naz to everyone. We are developers. We love to experiment with new technologies. But let's be real. When it works to when it comes to production environment, well, I think that we truly cherish patterns. Patterns are really what save us when we implement production use cases, production workload. So I'm Aru. I've

been a developer for a while in a paid way. Uh I've done the coding stuff. I've done the architecture, AI and so on. Um nowadays I'm a developer advocate at Amazon Web Services. Uh which mean like creating technical content uh talks, live streams. Uh but it also mean that I've saved the company billion of dollars by not writing production code anymore. So that's why in the next

45 minutes we're going to experiment all together aici patterns and how we can implement it using spring AI. But before going into the details and the land of spring AI, we need to take a step back. We need to understand where we came from in the IT industry in order to understand where we are going forward. uh a famous doctor would say roads we don't have roads

where we are going. If you have if you catch the the sentence then you are nerdy. So in the 60s uh the industry moved from low-level low-level programming language to higher level. Uh cobalt was one of the first language after punch card to express business logic in code. In the 70s uh the industry was moving towards structured programming by helping developers to escape the chaos of unstructured

programming. A few years later in the 80s a different path happened. We had objectoriented programming thanks to the C++ that came into the picture and helped to shape the rise of object and classes. how to modelize real world object into an abstraction into an object and classes. In the late 90s, Amazon was still running as a single monolytic application. Um, and in 1998, the growth as growth

accelerated, then the team began to break down these monolithic application into loosely coupled services. We were not talking about microservices yet, services. So each team had ownership over their service. They changed how developer worked. They could deploy faster, move faster uh on their system end to end and rely on their peers, not the world company. Over time, the industry began adopting these services at scale and uh

it became what we know nowadays with micro services. In 2020 um in the 2000 sorry we had on premises where we deployed application on services that we have to manage by ourself. Uh writing code often mean wrestling with hardware capacity planning long procurement life cycle. I had an experience where I have to wait three months to get my server up and running to deploy my simple Tomcat

And when cloud computing emerged then it changed the expectation for the role. Developers can now provision infrastructure on demand and have the freedom to experiment without waiting for the hardware capacity. And if we put apart the covid in 2020 um in 2020 I mean we were still developing like we are used to and our tools nowadays are really amazing. Um but none of this tool that we

are using are removing the work that you you in the room I'm looking at you only can do. uh we went from generative AI assistant where following we we implemented a set of rules to automate some specific task uh to generative AI agent where it it help us to achieve a singular goal very simple goal and nowadays with agentic AI system we can build multi- aent system

in order to mimic human logic and reasoning so to go way beyond what we are used to but as you can see over the last 70 years. It's an evolution, not a revolution. Each stack is being added on top of the previous one. We move from punch card to cobalt to cobalt to C to C++ to object and classes to Java and so on and so forth.

So this is an evolution And when it comes to AI, it's really important to have in mind that uh we have to be precise. It has to be deterministic because AI by default is nondeterministic. Uh what's happening here? Uh do we eat grammar or are we having dinner tonight? human language is ambiguous and that's why we need to be precise when using AI because we need to

clarify our intent and make sure it's performing and delivering what we expect. We have so many different senses at the same time. And if you give an ambiguous input prompt to the AI, it's going to deliver a ambiguous output. Sometimes we say, okay, build me a snake style game uh to the AI and then the AI is going to try its best to implement this snake style

game according to the input that you shared. But if you only say build me a snake style game, it probably will deliver something working or not. We don't know. But this version is probably not what you are picturing in your head. And that's why being precise is truly truly important. If you are not precise, you iterate with the the with the AI on the code and not

uh on what you originally have in mind. That's why if you have something to retain from this talk today, the patterns and RFC's that saved us still save us nowadays. Um this is the sentence to remember. For example, the RFC 2119 which provide keywords for requirements level. Uh it does provide some keywords like must, must not, should, should not, may as directive for the AI. So if

you provide this kind of RFC to your AI agent, it's going to use it as directive to implement the quest that you want to implement. It remove the ambiguity that makes the usage of tools by the AI weaker. And so uh it will really help us in our in our quest today. Okay, great. We know that pattern is going to help us to achieve agentic AI and

multi- aent systems, but I think we need more. We need to better understand what's concretely an agent. Before implementing our own agent using Spring AI, we need to understand what it is. So let me state a common ground. This is the anatomy of an agent. The agent when we create an agent, it could be a coding agent, it could be a a reservation agent, it could be

an assistant agent and so on and so forth. It has the first thing is the model. The model is going to act as the brain of our agent in order to resonate uh with the tools in order to tailor the behavior of an agent. If you want an agent, I don't know to build your snake style game for example, you have to tailor its behavior. And how

to tailor it? Then you can use system prompt. System prompt is some some instruction that you're going to provide to your agent in order to perform certain tasks, certain action following your best practices, following your internal practices for example. So we have the model, we have some instruction with the prompt. Then we need tools. Tools or skills. Uh how many of you are using tools, skills on

a daily basis? Raise your hand. Yeah, thank half of the room. So tools are the agent's hand. This is how your agent can manipulate external resources like API, like databases, like uh existing function in your codebase. Skills. Skills is a way to define some specific action via markdown and also it allows the agent to leverage any tools available. We can also have memory. memory um for those

that attended the previous talk um made by Kevin he shared about memory short or long-term memory helps to retain information so if your agent has to persist a conversation a state then you can use memory in order to implement it and for sure there is your goal what you want to achieve what you want to develop this is your prompt I'm going to refer to prompt as

quest because we're going to play a little game al together and see how it works So your prompt, your user prompt as a quest and then the agent with the model, the brain, the tools, the skills, the memory and it's iterating over an agentic loop. This is truly important the because what of what most of agents do is IO they are calling something they are waiting for

the response. Once they get the response from the tool, they are putting the information of the tool execution into the context, iterating on it, fetching new information and then sending you the final response. So it's truly a loop that is being implemented between each agent and this is what we going to do. So every pattern is a way of composing loops as simple it is. and agent.

Now that we know the definition of agent, agent has to follow the same principle as our microservices or Um the agent if you want to because the agent are replaying the monolithic microservices arc but the time frame is very different. We went into through 70 years um as in into in the introduction here the agent are replaying this microservices arc in 18 time frame. So that's very

very short but it doesn't remove the implementation implementation levels. It has to be loosely coupled to make sure that your agent that you build let's say you build a one big monolytic agent can be then plugged into one of the pattern like the graph or or the orchestrator pattern. It has to be composable uh interoperable and also specialized. You don't want one big monolithic agent. You probably

want specialized agent. I don't know. You have a coordinator, game coordinator to build your snake style game. And you want um a UI developer agent that's going to focus on UI development using some dedicated tool and skills. You want a code reviewer agent that's going to perform the code review with certain skills and certain best practices within its own knowledge and so on and so forth. So

having agent being loyal, composible, interoperable and specialized is really key and it has to follow the same practices that we are used to when developing our own application. And when we want to implement agent uh we have protocols to help us in our journey. We have the MCP model context protocol released by Antropic in November 2024. MCP, think about MCP like HTTP but for AI agent. So

it's really the same level where it allows agent to reach any tool uh exposed over the network and MCP is following a client server architecture. there is an MCP client that we're going to use and there is probably an MCP server exposed over the network somewhere um within your IT uh or another company that you can consume directly and by this by using this MCP servers you

can consume API databases code function whatsoever that's great but we want MCP to connect with tools but also we need to maybe a tool can be another agent so how agent can communicate among each each other Well, we have A H2A or agent to agent that we can use in order to connect agent together. A2A is using what we call an agent card where all the capabilities

of the agent are being described. uh it's as simple as a JSON file um that is being exposed by the agent where all its capabilities like the model the system prompt the tools the skills are being exposed to other agent via this JSON file and each agent can then directly consume the information. So this is the architecture of our application that we're going to build and use

all together. Um here you are on the left uh or on the right depending on where you are looking. Um we're going to have an agent and then we have different uh tools. We have a tool exposed over MCP uh which is a hammer it seems in this case but a tool can be a database an API a file system resource whatsoever and then we have also

other agents that going to communicate among each other using A2A. So these agent are being will be specialized on a certain domain and going to perform the action that we're going to we're going to ask. Okay, I think we have enough concept right now. We can move into the implementation phase. To do so, we're going to use Spring AI. Spring AI is really key. It brings the

entire Spring ecosystem applied to AI. So if you are already familiar with Springai, you can directly reuse it and import the Spring AI library to implement your first agent and it supports on the shelf MCP and A2A protocol. So it removes all the plumby that we don't have to focus on and we can directly work on the business logic that we're interested in. And our agent are

going to be running onto Amazon web services. Uh it's using a service called agent core. If you want to learn more more about there is a session in the uh by Vadim um speaking about agent core but we won't focus on that one we will focus on spring AI itself and the spring AI community because there's a lot of tool provided by the community and contribution are

more more than welcome um in order to have a brain for agent we're going to use Amazon Bedrock Amazon Bedrock is a serverless service that consume any LLM that let to consume any LLM um via API there is an invoke API that you can use and you can communicate with I don't know entropic clothes family model open AI mistral AI career deepseek and so on and so

forth so we're going to use that Amazon bedrock service in the back end in order to have a brain for our agent uh when implementing the different pattern so the different patterns now we want to experiment with the agentic AI patterns there are four main patterns. Uh sometimes it's named differently, but most of the time it's the monopattern, the graph, the orchestrator, also known as a um

agent as tool, and the swarm pattern. And depending on on on what you're developing on the application you're working on, then you probably want to go with a mono or a swarm or one in between. And that's a trade-off between the controllability and the autonomy um that you pick when you selecting a specific pattern. Great. So now let's compose our agent into topologies and try to achieve

the same quest. We're going to build a snake style game al together uh using these four different patterns. Do you think we're going to get the exact same outcome? No. No, we won't. Okay, let's start with the first one, the most controllable one, the mono agent. So the monolytic agent, the monolytic topology, there is no composition at all. One agent does everything. The agentic loop that we

saw run once um around one undifferiated persona because there is only one big system prompt trying to achieve everything and trying to handle all features of our quest. So if you want to implement this agent using spring AI then what we can do is to import the spring AI library. We also importing the AWS SDK uh Java SDK in order to interact with the LLM uh in

the back end. First we create a bedrock proxy chat client. This is our object in order to authenticate our request onto Amazon bedrock and get um the resources from the specific LLM. In this case, as you can see, we are using entropic cloud sonet 4.5. Um, we are setting some parameters for the LLM like the temperature. We want to be the more deterministic. 3 is very close

to 0. So, it's the more deterministic. Um, we set a max token number and then once we have our chat model, we directly build using the chat client from Spring AI. We use the chat client class from Spring AI in order to build our agent. And this is how we create an agent using spring AI. We provide a default system which is our system prompt in this

case. Uh and we provide some tools to our agent with the default tools method. We can we have two tools in that case the write result tool. So we we want to get a snake style game in HTML 5 and a task tool because it's going to iterate over several task. So it has a task tool. Great. We have created our agent. We have an instance of

our agent. Now we need to summon it. And how to summon an agent using Spring AI? Well, as simple as agent. Dutch user. User is your user prompt. So that's why create a snake style game. Add levels with different layout powerups, speed boots, invisibility, leaderboard, and smooth animation. Okay. Okay. So this is what we want to achieve al together. And when you call the call method, this

is where the agentic loop is being triggered. And hopefully we're going to get a plan. Uh we're going to get an implementation and then a deliverable. I don't know what we it will look like, but we should get one. Great. So let's switch to the agent and dragon's world. So this is an app. Uh the front end is in React but the back end is in world

Java and Java 25 by the way and Spring AI. So the purpose of this application is to build a quest. Uh you can build a flappy pigeon, you can build a snake game, uh solitire, a space invader and so on and so forth. Great. I think I said that I love snake. So we're going to build a snake game. And here you can see you can select

the different patterns. Um, is that okay in the back? Is that big enough in terms of font size? Okay, cool. Uh, so you can pick the monopattern and the monopattern is one agent. Okay, and we have two agents supporting the monopattern. We have an architect uh agent and the CTO agent. Let's see the definition. Okay, this agent uh is Enzone CTO using Sonet as a as an

LLM cloud sonet 4.5 with some system prompt over here that we can see you are the game development studio CTO with endzone capabilities you are able to deliver full software stack and game with polish feature complete HTML 5 games. Okay, sounds good on paper at least sounds good. uh and we can use it if we want by just picking it and running running it. Before we going

we can see that we have a graph orchestrator and swarm. So we're going to use the same application in order to test our different agent. Uh we can enter a name. Give me a name for a team. Sorry louder John. Sorry. Okay. Uh to I'm going to go J Prime. Yeah. Yeah. Sorry my And we can go next. We can add also in addition to your to

our quest to build a snake game, we can add other inputs like I don't know um create a fancy UI uh add sound effects. Uh okay, we can think we are good and then we can launch it. So let's see our team adventure how it goes. So our agent is being spin up and so looking at the code running in the background in the cloud and we

try to implement a snake style game. So come on hold on hold on you're going too fast. So what are you saying? I'll create a Polish snake style game with level power leaderboard and touch control. Let me plan and build this. Great. So it's starting with a plan phase. So he's planning for the game that we want to get. Um, great. Once he's done with the the

the planning, it's going to implement the game. So let's see how it's going to work. And it now is iterating through the agentic loop over here. You cannot see it till zero, but it's probably going to display in few seconds uh the number of iteration it made over the agentic loop in order to achieve the the result and send the So let's see let's give him few

few more seconds to to complete and otherwise I have a I have a back. So it's implementing the back end come on be be the god of John Wick with in order to implement. If it's taking longer, I'm going to switch. We know you can do it. Sonet clonet 4.5. We rely on you. We are waiting for you. I mean, I don't know how many people are

in the room. Like 800 maybe. So, you're being watched it by 800 folks that that are looking at it. And if it's not moving, then Oh, here we go. So he built the complete snake game uh and he made a snake game with all requested feature um levels with obstacle power up and so on. You see that the number of token it used in order to build

the game we ask the number of message is he sent and the number of iteration. So he iterated it iterated four times in order to complete the quest and it took 1 minute and 41 seconds. Okay, let's see the final result. Is it working? Is it not? Who knows? Okay, great. Start game leaderboard. I don't know where this data came from, but but okay. Um, start game.

Okay, seems that okay, we have a we have a working game, but I don't think we have all the features, especially the leaderboard is and we can replay it over time. Okay. So it's very basic and it has implemented what we expect but in a very basic manner and why um that's important it's because if like one monolytic application one big agent if you give everything to

one big agent you know what happen I mean it's context delusion and lost in the middle. So that's why um mono agent is correct when you are having a single responsibility persona focusing on one and only one thing with a set of tools. Um you limit the number of tools because each tools or skills are being added into the context of your agent. So if you want

to reduce that context and make sure it's still relevant, you have to limit the number of tools. You don't need decomposition. Uh your workflow is pretty straight. Uh you don't need decomposition. So this is where mono agent could be also a great fit and in the end it will depend on your LLM's capability to achieve this result. Great. Okay. First pattern. Now let's move to the second

one. The graph pattern. The graph pattern is very deterministic. It is a directed asylic graph. Um so it's edged directed. the execution reads through the order and if fin will wait for all predecessors. So it's really where um the topology you can read the graph and it's the contract of your workflow. Um it's not managed by the coordinator. It's not managed by the peers. It's directly managed

by you that implements the pattern. It read the execution order of the graph before the agent runs. Great. So how can we implement using Spring AI this specific pattern? Well, it's just a graph. So it's a tree. You can implement a bre first search tree and browse the tree and it's going to work. So the thing is I'm not putting the code to create our agent like

we did in in the first pattern. But we can see that for each over here in the in the map we have the prompt which is created our snake style game and then each outcome of each agent is being added to the next one. So the context is being fulfilled by the iteration of each agent being executed. So that's great. So we can see that each time

we are adding we are browsing the the tree node by node and at the end we reach the end of the of the tree and we should get something out of it. So let's see if with the graph pattern we can get something different. Um for the other patterns as it's might be longer than the mono agent. Uh, I've already played with it and recorded it. So,

we're going to use it. And here's and we're going to replay it step by step up. I vip coded a replay button to have fun with the agent. So, let's see. We want to implement the same quest, a snake style game. We want to have the game with the same feature and the same implementation. um we ask to a game coordinator first in order to implement the

design and specification of our game like a product manager will do. Once all the specification have been made is this specific agent is sending its response to a UI developer agent with specific skills on UI development. So is providing okay this is the design and specification do what you do with your skills your knowledge and build something. So this is what our quen LLM um is doing.

So we can see the HTML being produced by the agent in order to achieve our quest and once it will be okay with its own implementation because he can iterate several several time. So here we can see that each agent is iterating multiple times um on its within its own agentic loop. So now the quen should be done and now he's sending so he he has iterated

three times and now he's sending the deliverable to the code reviewer agent and the code reviewer agent has a system prompt which is specific to code reviews. He he has also some skills and tools dedicated for code review. So he's performing the code review. He can rewrite the entire application if he wants to. So let's see. And at the end it will deliver an outcome. So he

only iterated once and we should get a snake style game. So let's see. Okay. Different shape, different look. Great. Um leaderboard. Let's see. Leaderboard. Yeah, leaderboard. I don't know. It seems that they don't like leaderboards. Agent don't like the leaderboards. Um, so that's that's a game that I can play. Okay. Um, the snake is the snake is very small. The I don't know if the screen is

too big or the snake is very small. Yeah, it seems I mean we have the same feature but now okay I want to show you because I remember if I remember correctly if I'm if we are eating enough apples then we can go into different oh there is a specific not just apples let's see what it what is it over here level complete oh okay we have

levels and we can go to the next level and play with it. Okay, great. And when you are reaching level three, it's going to another um it's a different uh the difficulty change. When you reach level two, it's medium and level three, it's hard. Okay, so we have a different implementation, way better, way more detailed, way more functional. So I think we are going in the right

direction. graph is correct and is really useful when you want to have a predictable pattern and predictable workflow. The execution order is known in advance. So you can implement it if you want to audit your workflow because you can read the graph and so you can you know what will be the order of execution, what will be the different agent involved and so on and so forth.

So this is really helpful if you need to audit your your workflow and if you need to parallelize it uh well you can have several branch and par paralyze it. So graph is really helpful but don't always remember that agentic loop it's n independent loops with merge point. So this agentic loop is really key in in the implementation of these different patterns. Great two patterns. Now the

third one um I think that's the one I like the most orchestrator or also known as agent as tools. Agent as tools you send your request your inputs and there is a coordinator that's going to act as an orchestrator between several specialized agent. So it's a composition of agent where you have for example an architect agent with some dedicated tools for architecture, a front-end developer with build

UI tools and the code reviewer with some review tools and the coordinator is going to discuss with each specialized agent autonomously on its own and is going to summarize the output from each agent combine it reflect on it and then ship the deliverable. So the outcome the next style game that we do expect is going to be at the end shipped by the coordinator not by one

of the specialist agent and you can see that each specialist agent are not talking to each other they are always and uniquely talking to the coordinator so that's a one single single responsibility persona and I think that's combining the strength of the mono agent and the graph how to implement using spring AI well thanks to Spring AI we have a tool library and the tool callback that

we can use and we just have to declare our agent. So let's assume that our three agent are already created the architect front end and reviewer. So these three agents are already created and we declare these agent as tools and once they are declared as tools with their own capabilities. Well, we just have to create our orchestrator agent and our orchestrator is going to use another method,

not a default tool, but the default tool callback and we we provide these three as parameter as simple it is. By doing so, then uh agent are being able to communicate with the coordinator and the coordinator will discover it at runtime and perform the expected outcome. The same way we invoked the mono agent, we can also invoke the uh orchestrator agent with the user prompt with your

quest with your prompt and wait for the response. So let's see if that is the case with the orchestrator agent. Where are you my orchestrator? Orchestrator also knows agent as tools. And let's replay it from scratch. Okay, great. So, let's play with it. Okay, so we have a game coordinator that's going to spin. Yeah, a game coordinator, a junior architect, a a principal UI developer, um, and

the senior code reviewer. You can see that each agent is using its own LLM. So, we have Cloud Sonet, we have Quen, we have Cloud Outpost and another Sonnet. So your agent can use any LLM available and you can define it. So the game coordinator the central point is defining this design and specification for our game. Then he's he discovered the tree agent, the tree specialist he

has access to and he send the he sent the first request to the architect because he knows that architect is going to architect the game in a proper way before letting the UI developer implementing it. So he decided to go with the architect first and the architect is reflecting on it uh within its own agency group. So he's architecting the snake style game system. He's doing a

technical um technical specification out of the spec and design made by the coordinator. And he sent his result to the game coordinator and the game coordinator says okay now I do have a technical specification made by the architect agent. I can send it to the UI developer. So the UI developer has now all information you can we can see confidence high to implement a single HTML file.

Okay. Okay. You're you're pretty confident of um so it's going to implement this specific game. I think it's going to take a while. So let's speed up a little bit. Yeah. Over here. So we're going to get the HTML. Yeah. It implemented the HTML file and it sent back the result to the coordinator is like, "Okay, now I have a fully functional snake style game. I need

to review it before shipping it." So, I know that I have access to a code reviewer agent with a specific persona and specific tools. So, I'm going to use it in order to review what has been produced and let the code reviewer agent fix it if it needs to be fixed. So this is what our agent is now doing is validating and optimizing the game for the

production quality. Okay. Um final deliverable will be the reviewed HTML. So and I think if we yeah because the code reviewer made an update of the HTML file and send the result back to the coordinator that shipped the game. So, do you think we're going to get the same or another one? Another one. Snake OD say navigate through danger. Okay, first thing leaderboard leaderboard is not uh

is working as expected. This is my played when I dry run. So, start a new game and we have a different shape. Okay. And we have the object from the invisibility. Oh, Okay, great. I think and so the leaderboard is working. Uh the game has fancy UI, the game has features that we expected. So it has been developed in different way, but we can see that we

got an better version of it. And I think with the orchestrator pattern you can get most of the agentic AI workflow. If you're building a multi- aent uh systems I think using the coordinator or the agent as tool workflow um is the best way to take most of the AI uh and your agent at scale. if we go back where is my yeah if we go back

to this space the orchestrator is correct when there is no fixed flow you've seen that the orchestrator picked the agent at runtime not before like the graph while it was already pre-created. So when you have no fixed flow and you want to have one smart coordinator deciding who's next at runtime coordinate a co coordinator pattern is really really great if you want specialized agent that work separately

and I think it's if we go back to our best practices around microservices and agent well that's also a receip for success so having specialized agent connected with one coordinator this is also really really key. It will avoid um situation like the personas scope delution that we faced in the mono agent like the tool delution into the context or the lost in the middle where the agent

doesn't know where he is or she is and most multi- aent workflow nowadays are being you are using this orchestrator pattern um in order to implement the logic the business logic. Okay, great. Last one, the most autonomous one, the swarm pattern. Okay, the swarm pattern, you have I don't know five agent, 10 agent uh plus and they are all running autonomously. There is no central coordinator. There

is no bottleneck with the coordinator uh agent here. All agent are working autonomously and they are handing off to over to their peers when they decide to end over. So you don't have the control on it. you can kind of tailor it with the prompt but in fact it's a decentralized pattern so there's no fixed order. Uh they share the same context so they share the list

of tasks to implement the handoff history when a an agent hand off to another one for XYZ reason. Uh they share knowledge and also agent roster. Okay, that's great. But if you don't define safety cap, you can fall into a trap of infinite ends off. So let's make sure that you you have a safety cap implemented to avoid infinite ends off. And in order to implement it

using Spring AI, so as of today in Spring AI, there is no uh swarm orchestrator engine to be honest. um the Spring AI community developed um patterns using agent to agent in order to achieve kind of similar pattern uh using spring AI. So you can definitively implement it but in this case what I did is I used the default tool callback in order to implement uh a

list of agent. So we've built ends off tool. So a specific tool to end off uh to make sure that agent end off throughs and the architect for example in this case the architect agent knows the list of agent he has access to like the front- end developer and the Also safety cap like I was saying make sure to implement safety caps to limit the number of

handoffs otherwise you're going to fall into an infinity infinite loop. Okay swarm to finish. Let's see And if we get a similar snake style game swarm pattern over here. Okay, let's let's speed up let's see how it goes. So we have three agent. We retrieve our famous one mono agent the set oken shield. So he initiated the swarm by directly shipping the hot potatoes to the UI

developer. So okay, why not? That's a strategy. Um um remember that swarm is really really autonomous. Uh so when you have workflow that are nondeterministic and you don't know the outcome probably it could be a fit uh but it could also be dangerous. Uh the UI developer made the HTML game in only one iteration. Remember in the previous pattern it took like four iteration or three iterations

to to do the same and now the code reviewer is already handling it. So they ended it properly. Um it was not the chaos like you could expect the code reviewer probably to to send the response back to ah the code review send the result back to the UI developer because probably something is wrong. So this is they deal with with them autonomously. Uh you have no

control on it. Um you just watch them running. And so I think he has done with the implementation and they shipped the snape game. Yeah. Okay. What the what we got? All peers have contributed and the deliverable is complete and production ready. Shipping to the final snake game with all features implemented. Confidence high. Okay. Okay. That's strong. Let's see. Okay. Now open quest final What? Wait, leaderboard

first. We know that. Okay. Undefined. Undefined. Great. Let's play a party uh with I don't know, obstacles. Do we have obstacles? No, there's no obstacles. Maybe that's wrong. Come on. Okay, let's go back to the menu. Challenge. Okay. So you see the implementation delivered with several um options like classic maze obstacle change but there is none or maybe it's later in the in the game but it

has a different UI it has a different shape different element to play and so on and so forth. Great. So we got our result with the swarm. We have been able using four different patterns to to build a similar game-ish. Uh but the swarm is really key if you look for autonomy. Um you have no control on it. Like I said, um agent will pick the the

path to execute your your task, your goal at runtime. So you don't know what's going to happen. That's the most autonomous way of building agent AI workload and for the demo that that was fine but uh in a real world like you have five plus agent and you have ambiguous routing or domain ends off this is where swarm will be really really key remember it's a decentralized

pattern so make sure to set explicit termination uh if you want to leverage it and to use it that's why um make sure to pick the pattern when building your your workload and don't default to it. Um if your problem looks like one skill, one goal, then I think probably the mono agent and the monopattern is the right choice. Um if you flown uh if your workflow

is known until the end, then the graph is also a great choice to be to be used. If you need audit, then the graph is also key. Um if you need to have a workflow which is decomposible and the path will be decided at runtime the orchestrator might be the right choice. Um and if you wrote emerge at runtime and peers know more than you then the

swarm is the go-to. Um my suggestion, my two cents will be experiment with the monopatter, build one big agent and then uh specialize it and associate it with a pattern like the orchestrator pattern. It will be um a good choice to to be implemented in your in your workload. If you want to play with it, uh if you want to have some fun, uh there's a workshop

that I'm delivering tomorrow about it. Um but if you're not attending the workshop then you can scan this QR code and go to the GitHub repo so you can implement step by step the different agent that we've seen using Spring AI. Um and share with me on LinkedIn your experience and your result about your identical patterns. I hope it was helpful and thank you very much for

your