In recent months, the concept ofAgentic AIhas emerged as one of the central themes in the evolution of information systems. But beyond the hype, what is really taking shape is a structural convergence between cloud platforms, open frameworks and distributed architectures.
This article proposes a reading in three acts: first observing the convergence of models in hyperscaler platforms, then exploring hybrid and distributed efficiency-oriented scenarios, and finally bringing everything back to the enterprise context, where governance, security and compliance constraints come into play.
The result is a unitary perspective in which agents are no longer simple application components, but infrastructural elements, to be designed and governed through architectural patterns such as Zero Trust, Self-Contained Systems and Event-Driven Architecture, supported by CI/CD and Infrastructure as Code practices.
Table of Contents
Overture on the Fourth Circle – Act I – Convergence
In previous articles onFourth Circlewe have observed how AI is progressively ceasing to be a tool to become a structural dimension of the corporate ecosystem.
An ecosystem that includes software, platforms, data, but also processes, people and operating models.
L 'Interludeit led us to stop for a moment, to observe the context, to distance ourselves from the noise.
Now it's time to get back to the topic.
This Overturecomes from a question that has become inevitable in recent months:
what is really emerging under the term “Agentic AI”?
Not as hype or as a product feature, but as a possible new technological baseline.
However, there is one aspect that radically changes the way in which this topic should be addressed.
If we look at agents from the perspective of an enthusiast or an experimental context, the available options seem almost limitless.
But in a business ecosystem — especially in regulated areas — the reality is different.
Regulations such as NIS2, DORA and emerging frameworks such as ISO/IEC 42001 introduce concrete constraints on:
• data management
• traceability
• localization
• auditability
In this context, the question is no longer “what is possible”, but:which options remain truly viable.
At the same time, a second factor is emerging, less visible but equally relevant: efficiency.
Intensive use of large models is not always sustainable — neither economically nor operationally — especially when agents enter iterative loops or high invocation frequency scenarios.
For this reason, approaches that complement enterprise models are starting to spread:
• lighter, specialized and low token consumption models
• Distributed executions across cloud and on-premises environments
• hybrid orchestration logics, in which the "right" model is chosen based on the context
At this point it is useful to clarify a choice of field.
In this analysis we will take cloud platforms as the main reference.
Not because they represent the only possible option, but for some very concrete reasons:
• direct and consolidated knowledge of these environments
• the fact that they represent the largest distributed computing capacity available globally today
• the presence of consolidated frameworks and references for regulatory compliance on a national and European scale
Hyperscalers are not just service providers, but major points of convergence where innovation, scalability, integration and compliance are rapidly brought to maturity.
This does not exclude — indeed, it makes it even more interesting — the evaluation of hybrid scenarios, in which computational capacity and services can be distributed between public clouds and dedicated platforms.
A concrete example, in the Italian context, is represented by Intacture, a high computational intensity platform developed as part of the Trentino DataMine initiative, strongly desired and supported by the Dedagroup group, which offers advanced services, including those linked to GenAI.
It is therefore not a question of choosing between cloud or local alternatives.
It's about understanding how these options can coexist in hybrid architectures.
For this reason, we will start from what is proposed by the big players in the field of agentic AI, and then observe how these capabilities can be extended, integrated or rebalanced in more complex contexts.
We can divide this history into distinct periods:
Opera in three acts
To try to bring order to this scenario, thisOvertureis divided into three acts, each observed from a different but complementary perspective.
In the first act we will analyze the convergence that is emerging in the main cloud platforms, observing how hyperscalers are building, with different approaches, a surprisingly similar technological base for the development of agent systems.
In the second act we will take a lateral step, leaving the cloud perimeter to observe the same patterns in the world of open source frameworks and local environments, where the same capabilities emerge in a more explicit, less abstract and often more flexible form.
Finally, in the third act, we will bring these observations back to the enterprise context, to understand how this convergence is filtered, constrained and operationalized through architectures, processes and governance models.
The choice to represent this journey in three acts is not accidental.
It is a way of making legible a phenomenon which, observed as a whole, risks appearing fragmented:
starting from the offer of the platforms, crossing the more flexible alternatives and finally arriving at the point where all this must be governed.
The objective is not to compare technologies, but to understand a phenomenon:
understand whether we are observing a simple evolution of tools or the emergence of a new infrastructure base.
🎼 Act I – The convergence matrix
Starting from this context, we tried to directly observe what the main cloud platforms are offering in the agent field.
Not through theoretical comparisons, but by looking at the real services made available by the main hyperscalers: Amazon Web Services, Microsoft Azure, Google Cloud and Oracle Cloud Infrastructure.
The analysis, at least initially, is not linear.
Each platform uses its own language, offers different levels of abstraction and integrates these capabilities in a way that is deeply linked to its ecosystem.
In some cases we explicitly talk about agents, in others about extensions, workflows or intelligent services. Even integration with external data and systems is described with different terminologies, often difficult to compare directly.
At first glance, the panorama appears fragmented.
A look at the services
However, if we go into detail, interesting elements begin to emerge. On Amazon Web Services, services such as Agents for Bedrock present themselves as a layer capable of orchestrating models, integrating knowledge bases and invoking external services, maintaining a close link with the AWS ecosystem.
In the case of Microsoft Azure, agent capabilities are distributed between Azure AI Agent Service and the entire Copilot stack, with strong integration with identities, development tools and productivity platforms already present in the company.
On Google Cloud, solutions such as Vertex AI Agents and Extensions offer a more open model, oriented towards interoperability with external frameworks and the composition of distributed capabilities.
Finally, Oracle Cloud Infrastructure explains the agentic components very directly, introducing services in which tools, data and orchestration become declared primitives of the platform.
From the service catalog to the model
At this point, something changes.
Beyond the names and differences in presentation, observing these services across the board a recurring pattern emerges.
The same capabilities reappear, with different forms but with surprisingly similar responsibilities.
What initially seemed like fragmentation begins to reveal structure.
It is precisely from this observation that the convergence matrix emerges.
The repeating blocks
By analyzing the different platforms, it is possible to identify some fundamental elements that systematically recur.
A first block is represented by an agentic runtime, i.e. a component capable of orchestrating sequences of actions, maintaining state and coordinating the interaction between model, tools and data.
Alongside this, the presence of tool calling mechanisms emerges, which allow the agent to invoke external systems - APIs, application services, functions - in a structured and controlled way.
A third recurring element is represented by RAG (Retrieval-Augmented Generation) patterns, which connect the model to knowledge bases, making contextual grounding of responses and actions possible.
Finally, all platforms rely on a hybrid data backbone, which combines structured data and vector representations, often distributed across multiple storage levels.
At this point a first key conclusion emerges:
- The agent is not an advanced chatbot.
- It is a coordination runtime between model, tools and data.
The convergence matrix
These elements can be summarized in a matrix that makes the observed convergence explicit:
The convergence matrix
These elements can be summarized in a matrix that makes the observed convergence explicit:
| Block | Amazon Web Services | Microsoft Azure | Google Cloud | Oracle Cloud Infrastructure |
| Agent runtime | Agents for Bedrock | Azure AI Agent Service / Copilot | Vertex AI Agents | OCI Generative AI Agents |
| Tool calling | Lambda, API Gateway | Azure Functions, Logic Apps | Cloud Functions, Extensions | OCI Functions |
| RAG / grounding | Knowledge Bases for Bedrock | Azure AI Search | Vertex AI Search / RAG Engine | OCI Search |
| Data backbone | S3, DynamoDB, Vector DB | Data Lake, Cosmos DB, Vector Search | BigQuery, Vector Search | Autonomous DB, Vector |
This representation simplifies a fundamental point.
We are not looking at isolated features, but a repeating pattern.
A model that emerges regardless of the vendor and tends to stabilize.
An architectural reading
If we reread this matrix from an architectural perspective, a very clear separation of responsibilities emerges:
- the runtime governs the flow
- the tools extend operational capabilities
- retrieval connects the system to the information context
- the data backbone guarantees consistency and persistence
A convergent, replicable, scalable structure emerges, governable in enterprise contexts and in some way independent at least conceptually from the proposal of the specific hyperscaler, if well organized at an architectural level
The divergence in compliance management
If the technical structure tends to converge, the issue of compliance introduces a further level of differentiation, less visible but extremely relevant in enterprise contexts.
The reference standards remain the same — such as NIS2, DORA or emerging standards such as ISO/IEC 42001 — but the way in which these are supported varies significantly between platforms.
In some cases, control mechanisms are deeply integrated into services: identity, authorization, logging and traceability become a natural part of the functioning of agent systems. This makes adoption in regulated contexts more immediate, because many requirements are already incorporated into the platform.
In other scenarios, however, the platform maintains a more neutral and flexible approach. The same capabilities are available, but require an explicit composition: it is the architecture that has to build the necessary level of governance, defining rules, controls and processes.
This introduces a subtle but fundamental difference.
The possibility of being compliant does not change, but the point at which responsibility is exercised does change.
In one case it is predominantly incorporated into the platform.
In the other it is distributed across architecture, processes and teams.
And this has a direct impact not only on design, but also on operational management, auditing and the sustainability of the solutions adopted over time.
A choice that remains contextual
At this point, the natural question is not which platform to choose overall, but which one to delve into in relation to the specific context in which we are moving.
The differences that emerge — in terms of integration, openness, compliance management and operating models — do not define a hierarchy, but outline different adoption scenarios.
In some cases, it may be natural to move towards platforms that offer a high level of integration and greater adherence to enterprise requirements already at the service level.
In others, it may be more effective to delve into solutions that favor flexibility and composition, especially when the goal is to build hybrid architectures or maintain greater control over individual components.
For this reason, rather than looking for a definitive choice, it makes sense to address the topic with a progressive approach:
analyze the proposals of individual hyperscalers, understand their operational models and evaluate how these fit into their own architectural, regulatory and organizational context.
- There is no "right" platform in an absolute sense.
- There is a platform that is more consistent with the problem you are trying to solve.
But is this convergence, so evident in the cloud, really limited to this perimeter?
In the second act we will try to broaden our gaze, exploring scenarios in which these same logics are applied outside of hyperscaler platforms.
In particular, we will analyze how it is possible to build architectures that maintain the regulatory and governance requirements required in the enterprise sector, while introducing elements of optimization, differentiation and control.
Scenarios where lighter models, specialized components and local or hybrid execution modes start to play an increasingly relevant role.
Not as an alternative to the cloud, but as a natural extension of the model we have just observed.
Leave a comment