Agentic AI Patterns: one size does not fit all - Quarkus

Blog Agentic AI Patterns: one size does not fit all
At the beginning of 2025, we began experimenting with agentic AI using Quarkus and its LangChain4j extension. These efforts led to the publication of a three-part blog post series on the topic: the first introduced agentic AI and workflow patterns, the second explored purely AI-orchestrated agentic patterns, and the third examined the differences between these two approaches through a practical example, highlighting their respective pros and cons.
Only a few months have passed since those articles were published, yet the AI ecosystem and the possibilities it unlocks have evolved at an incredible pace. Keeping up with the constant stream of novelties and changes has become increasingly challenging. In fact, the initial experiments from that series now seem to belong to a different era, even though they laid the essential groundwork for exploring the agentic AI landscape.
These experiments and explorations led to the implementation of a new agentic module in LangChain4j, designed to provide a comprehensive toolkit for building agentic AI systems. The module also includes a set of predefined agentic patterns that serve as building blocks for coordinating agents in different ways. However, as we continued experimenting and, more importantly, discussing our findings with the LangChain4j community, it became clear that believing this set of patterns could fully cover all possible use cases was somewhat naive. In reality, the landscape is far more complex and nuanced.
Agentic AI was, by far, one of the most discussed topics at Devoxx Belgium 2025, and we had the opportunity to present the agentic AI patterns implemented in LangChain4j. In fact, we delivered both a talk showcasing practical examples of how these patterns work and how to use them, and a session that delved deeper into the journey behind implementing the agentic framework, including the key decisions we made and the mistakes we learned from along the way.
As always at Devoxx, what mattered even more than attending the countless talks on agentic AI was the opportunity to meet so many people working in this field, exchanging ideas, sharing experiences, and discussing challenges and solutions.
We learned a great deal from these interactions and returned home with one clear realization: we will never find a definitive pattern for agent orchestration. Not only is this beyond our specific area of expertise, but more importantly, such a universal pattern simply doesn’t exist. The variety and complexity of tasks that an agentic system may need to handle mean that no single approach can work in every situation: there is no one-size-fits-all solution for agentic AI orchestration.
In reality, there is a broad spectrum of agentic patterns, ranging from reliable and deterministic yet rigid workflows, where agents follow predefined code and flow paths, to flexible yet unpredictable pure agentic orchestrations, where LLMs autonomously determine the sequence of actions and maintain control over task execution. Between these two extremes lies what might be the most interesting space: one that balances reliability and flexibility. And since precisely defining that middle ground is challenging, why not give users the ability to shape it according to their specific needs?
The natural outcome of these reflections was the decision to design a generic architecture for agentic AI patterns: one flexible enough to support a wide variety of use cases, while still allowing these patterns to function as modular building blocks that can be seamlessly combined and complement one another.
To ensure maximum flexibility, we needed to identify the simplest and most minimal abstraction capable of doing the job. This led us to realize that an agentic pattern, at its core, is the specification of an execution plan for the subagents it coordinates. Such a plan can be defined by implementing the following Planner interface:
This interface, that still has to be considered experimental and could be enriched or modified in other ways with subsequent revisions, defines a method for initializing the planner, along with two methods responsible for determining the first action to execute and all subsequent ones. The method that returns the first action is optional; by default, it simply delegates to the method that returns the next action, which is the only one that must be implemented. The Action class returned by these methods represents the next step to be taken by the agentic pattern. It can either specify one or more subagents to be invoked next or signal that the execution has completed.
In essence, the architecture of the LangChain4j agentic framework can be seen as a two-layered system, where the planner layer is responsible for determining the sequence of agent invocations, while the execution layer handles the actual execution of these agents based on the planner’s directives. Both layers are designed to be easily extensible, allowing users to implement custom planners and execution frameworks like Quarkus to adapt some runtime aspects, like the thread pool used to run the different agents, to its needs. The AgenticScope acts as the shared context between these two layers, maintaining the state of the entire agentic system throughout its execution.
All the built-in agentic patterns provided out of the box by the langchain4j-agentic module have been rewritten using this new Planner abstraction. The pull requests implementing this architecture have already been merged, and this article won’t go into much detail about their internals here, as you can find a full explanation in its description.
Another important aspect to consider is that this new architecture not only allows users to implement their own agentic patterns but also makes it easy to combine them with any other pattern, whether provided by LangChain4j or created by users themselves. Since all patterns are now defined in terms of a Planner, any pattern can s