Stay informed and never miss an Core update!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
A mathematical model based on the physics of quantum mechanics and the theory of relativity that is more than 50 years old, is considered a great architectural solution for current and modern intelligent agents.
In Part I, we describe the beginning of a proof of concept on the use of AI multiagents to automate the management of a type of procedure and improve the citizen service capacity of a public sector organization.
Later, in Part II, we saw that in order to meet functional and non-functional requirements, in addition to using the AutoGen framework as a solution for developing intelligent agents, we needed to consider other components and tools.
In the end, we managed to meet the goal of the proof of concept.
However, to bring such a solution to a real productive environment, we had to solve some other challenges.
In this Part III of this series of articles, we will describe some software architecture solutions that apply to the inherent problems of intelligent agents and agentic systems, especially when it is necessary to take the next step of bringing them to productive environments.
Intelligent Agents vs. Agentic Systems
Before addressing the topic of architecture, it is important to highlight the differences between AI agents and an AI agentic system.
AI agents are fundamental components, operating independently unless something coordinates their work. This coordination is what transforms an environment from a simple “collection of agents” to an AI with management capacity or an agentic AI system.
The agentic system operates at the level of workflow and results, not at the task level.
The agentic system introduces the ability to plan, reason and route across multiple agents and systems. Instead of executing one task at a time, an agentic system understands the overall objective, determines the sequence of actions needed, selects the appropriate agents or tools for each step, and adapts as conditions change.
With this distinction in the definitions, we will see some of the main characteristics of these two elements:
Characteristics of AI agents and agentic systems
Taken to our proof of concept to solve the problem posed that we described in the posts of the Part I and Part II, a agent system, that They maintain their status, orchestrated by a workflow sequential and that interact with each other through conversations (chat) with a communication format asynchronous. Due to the simple nature of the test, it did not include high turnout, but in a productive environment it should surely be contemplated.
If we add to the above layer of infrastructure where AI agents normally live in a productive environment, the solution will surely be, a cloud native architecture.
Cloud-native software architectures, as described in the post "Applications adaptable to changes" have been specifically designed to take advantage of cloud computing models (public, private, hybrid or multi-cloud) for scalability, resilience and agility. Key types include microservices, serverless computing, event- and container-based architectures, and 12-factor applications, all managed through automated CI/CD pipelines.
When we look at these characteristics, and compare them with modern system architectures, we see that there is a computational model that naturally fits these characteristics perfectly, it is the Actor Model 1.
The actor's computational model, formulated by Carl Hewitt, Peter Bishop and Richard Steiger in 1973, based on principles of physics, was designed to model highly parallel, distributed and asynchronous systems, rather than the sequential logic of traditional Turing machines.
Basically, actors are lightweight and isolated entities that maintain an internal state and communicate through asynchronous messages, and these can determine the behavior or logic that they carry inside.
Highly competitive distributed applications such as Whatsapp, Discord or Fortnite, among others, have been designed and built using the actor model.
At Peperina Software, we have been working with solutions based on actor model architecture since 2019 and we have been able to verify these advantages of scaling, resilience, responsiveness and efficiency in productive environments.
In its essence, the actor model is a simple model where three models come together 2:
Thus, when we model the logic of an AI agent as the behavior of an individual actor, the model is almost perfect.
Each AI agent is an actor with its own status and communicates securely with other agents or actors through messages.
This allows that, in addition to complying with each of the above-mentioned characteristics, the actors are by definition:
However, to better understand the communion between AI agent systems and the actor model, it is worth evaluating the above-mentioned properties with other modern software architectures. For example:
Microservices Architecture
Both microservice architecture and AI agent systems represent modern approaches to dividing the complexity of application logic into distributed and manageable components, but they differ fundamentally in their purpose, autonomy, and decision-making mechanisms. Microservices are designed for the development of structured, deterministic and scalable software, while AI agents are designed for autonomous, flexible and goal-oriented problem solving.
Serverless Architecture
The serverless architecture, defines logic in functions whose nature is ephemeral, triggered by triggers. They're special for brief, stateless bursts of work, but aren't as suitable for an intelligent agent who must maintain memory and context for tasks that can last a long time. On the other hand, if it is necessary to rebuild the state of an agent on each invocation, this adds latency and cost, as well as interrupting continuity.
Surely for this reason, late last year, AWS created the durable lambda functions 3, basically, it added to standard lambda functions the ability to manage state to allow developers to express the logic of the stateful application completely within the function code, and to be able to create workflows. Similarly, Cloudflare created a Workers AI 4 which provides a platform that allows developers to create stateful autonomous agents that operate with low latency.
In this way, the serverless architecrure, which was born with a specific purpose, was adapted to cover the characteristics of AI agents.
Container-based architecture
In this type of architecture, smaller computing units (containers) ensure coherence between development and production environments, usually orchestrated by tools such as Kubernetes.
An example of this type of architecture is the one offered by Google, with the solution Vertex AI Agent Engine 5, a managed and containerized execution architecture on Google Cloud, designed to deploy, scale and manage AI agents, eliminating the need to manually configure the infrastructure. It is compatible with multiple frameworks (LangChain, LangGraph, ADK) and features a modular design that combines a central execution environment for reasoning (usually Gemini) with memory banks for long-term persistence and secure integration of tools (function calls).
The problem with this type of architecture is the weight of the containers. Keeping thousands or millions of practically inactive containers up and running is operationally complicated and unsustainable from a cost perspective.
Event-driven Architecture (EDA)
This type of architecture predates the arrival of AI agents, and it came to solve the challenge of communications in a microservices architecture. If we connect microservices, as they say, by “pulling cables” between them, that is, through APIs or direct RPC calls, we create an enormous tangle of interdependencies. If a service fails, it affects all the nodes involved in that communication network.
Through asynchronous communication through events, EDA solves the coupling problem. The services do not depend on each other but rather react to events that happen in real time.
In the case of AI agents, something similar happens, multiple agents need to communicate with each other, and react to different events.
EDA allows workflows to be decoupled and, at the same time, enables real-time communication, ensuring that agents can operate efficiently on a large scale.
Of course, EDA does not solve the complete problem or the rest of the characteristics of agentic systems, such as business logic, concurrency management, durable states, etc. Just as with microservices, it is an important enabler for decoupled communication between them.
Platforms for building agency systems
When building agentic systems, we probably need several of the architectural pieces mentioned above, since none alone solves all the needs and complexities inherent to this type of system.
Thus, for example, the logic of intelligent agents could be based on the actor model, which, as mentioned above, simply meets the main computational requirements of an agent: communication, concurrency and security, with distributed state management.
These actors or agents, who can scale to millions on a single machine or node, can live in lightweight containers orchestrated by Kubernetes, in any of the public, private or hybrid clouds we know of, with mechanisms to scale up or down according to the demand to pay only for the running agent or actors. To communicate events in real time with other applications or systems, you can include some of the PubSub messaging solutions that implement EDA, such as Kafka. Then, to this we added observability, monitoring and other complementary services, and with this we are completing the assembly of an agentic platform.
Different technology providers are already offering this type of platform, including:
Each one has its pros and cons, so when it comes to selecting a technology, the solution depends on the different requirements and factors we have to evaluate, because this is usually a choice between trade-offs.
“There are no solutions; there are only trade-offs. [...] But you try to get the best trade-off you can get, and that's all you can hope for.” 6
—Thomas Sowell, interview with Fred Barnes (2005)
One of the most important factors to consider, when choosing an agentic platform solution, is that agentic systems, in short, are distributed systems with some additional complexities, such as: non-deterministic components (LLMs); long-lasting workflows; and because of their autonomous management feature, actions with irreversible effects, for example, sending emails, updating records, providing infrastructure, etc.
From our experience, since the Akka Agentic AI platform is based on Akka libraries based on the actor model, that have more than 15 years of verifiable experience in thousands of projects around the world related to distributed systems, it provides us with trust in the face of typical distributed system problems, such as: persistence, recovery, idempotence, reattempts and external side effects.
In addition, its use is really simple with a high focus on the developer experience (DevEx),
Akka is an enterprise-level agentic AI platform designed to help implement production-ready, agentic systems without the need to integrate a long list of independent tools.
In the next post, Part IV, we will see a concrete example of our development and implementation of an agentic system for a client in a productive environment using the Akka Agentic AI platform.
Credits: Cover photo of Ecliptic Graphic within Unsplash
References:
