What Does Agentic AI Architecture Actually Mean?

The English expression is ambiguous. Read superficially, it may suggest an “agentic architecture” — perhaps even an intelligent architecture — as though the architecture itself possessed intelligence, autonomy, or the capacity to act. That is not the meaning I use here. The phrase must be expanded as architecture of agentic AI systems: the architecture of artificial intelligence systems whose decisive components are advanced agents.

An architecture does not become intelligent merely because it contains intelligent components. It may be adaptive, reconfigurable, context-aware, or capable of supporting autonomy, but these are architectural properties that must be defined and verified separately. Intelligence belongs to the behavior of the system and, above all, to its agents: they interpret objectives, construct plans, select tools, consult memory and knowledge, evaluate results, and alter their path during execution.

The difference from the agent-based architectures I studied fifteen or twenty years ago does not lie in the mere presence of agents. Limited autonomy, cooperation, negotiation, multi-agent organization, objectives, and context are not new ideas either. What is new is the type of component introduced into the architecture: an agent built around a generative model, capable of working with natural language, combining heterogeneous knowledge, dynamically generating plans and code, using external tools, and revising its decisions on the basis of intermediate results.

A simple observation: interoperability — whether semantic or involving security, authorization or trust — which caused us so many difficulties twenty years ago, now seems to have been almost absorbed into the very definition of the agent. An agent must declare its capabilities, be able to discover and use tools, and communicate with other agents through common interfaces and protocols. The problems have not disappeared, but they have moved to another level.

This new agent does not invalidate the history of multi-agent systems; it continues it on a radically different technological basis. It is precisely this difference that justifies the emergence of a new family in the long succession of software architectures. Not because the architecture itself has become intelligent, but because it must organise, constrain, and make intelligible the behavior of components whose cognitive capabilities are incomparably greater and less predictable than those of agents programmed through explicit rules, plans, or BDI models.

A correction to my own pessimism

In the pages on the history and future of Software Engineering, I spoke about the decline of its classical form. It was not software that was in decline, but the image of an autonomous discipline, with relatively clear boundaries, prescribed methods and an ideal path from specification to implementation. Agile weakened the prestige of heavyweight methodologies, DevOps absorbed development into operations, the cloud transformed the application into a permanent service, and generative artificial intelligence seemed to reduce programming to the formulation of an intention in natural language.

Reading about Agentic AI Architecture does not invalidate this interpretation, but it completes it. The classical form of the discipline is dissolving, yet the engineering problem returns in a more difficult form than before. A language model can propose a plan, choose a tool, generate code and evaluate a result. But precisely because all these things happen probabilistically and, at times, unpredictably, the system surrounding the model must be designed with greater rigor. Heaven forbid that we should develop, with such an architecture, an application for guiding space rockets!

The location of the difficulty therefore changes. It is no longer enough to design the algorithm and the data structure. We must design the space in which a system can make decisions, use tools, modify its strategy and learn from results without leaving the acceptable limits of safety, cost and responsibility.

From decomposing functionality to decomposing decisions

The most fertile idea in the InfoQ issue seems to me to be the distinction between microservices and agents. Microservices decomposed functionality: each service was given a responsibility, controlled certain data and communicated through well-defined interfaces. However complex the whole became, the route taken by a request was, in principle, known and encoded in advance.

An agentic AI system decomposes something else: the decision. It is not prescribed the entire path to follow. Depending on the goal, context, intermediate results and evaluations, it decides at runtime which agent or tool should be used, in what order, whether another attempt is needed and when the result may be accepted.

This is a profound change in the object of design. In classical systems we designed control flows; in agentic AI systems we design the conditions under which the control flow can be constructed dynamically. The architect no longer traces every possible route, but defines the space of permitted routes, the available tools, the evaluation criteria and the boundaries beyond which the agent may not pass.

What changes compared with microservices?

The new architecture does not replace microservices and the cloud. Agents continue to use (micro)services, databases, message queues, APIs and observability infrastructures as tools. What is new is the decision layer added above them. The transition will therefore not be a sudden break, but an overlay: these architectures will grow upon the foundations of existing distributed systems.

A probabilistic core within a deterministic shell

A language model is not a deterministic service. The same request may produce different answers, and a linguistically convincing result may be false, incomplete or incompatible with the system’s rules. For this reason, the LLM’s output must be treated neither as truth nor as a directly executable command, but as input to a verifier.

The approach supported by the eMag authors is an engineering one: the probabilistic model must be enclosed within a controlled mechanism. The agent may propose a plan, but execution must be performed through tools with explicit interfaces, limited permissions and verifiable results. Generated code must run in an isolated environment; results must be tested; every important step must be logged; attempts must be limited; and when confidence decreases, the system must return to a deterministic path or to a human operator.

In this formula I recognize a return of the spirit of Software Engineering. We do not ask the model to become deterministic, which would mean cancelling its advantage. We use its flexibility where it is useful and surround nondeterminism with structures that make the system testable, auditable, recoverable and, as far as possible, predictable.

From chains to graphs and then to code

The evolution of the mechanisms surrounding agents is itself a small history of engineering maturation. Early applications linked several prompts in a linear chain: classification, information retrieval, generation. They were easy to build but fragile. An early error propagated to the end without real recovery mechanisms.

Graphs introduced branches, retries, parallelism, explicit states and validations. The flow became inspectable and modifiable, and specialized agents could be coordinated by an orchestrator. But as scenarios grew, graphs risked becoming complicated, rigid and difficult to maintain in their own right.

The next stage treats code as a mechanism of reasoning and verification. The agent can generate SQL, Python or other executable forms, run them in an sandbox, observe failure and correct the solution. This does not mean that any syntactically correct code is also semantically correct. But compilation, tests, assertions and simulation provide much stricter feedback loops than the evaluation of free text.

Four elements of a robust mechanism

• Execution sandbox: an isolated space in which code can run without compromising the real system.
• Instrumentation and logging: recording steps, results, errors and intermediate states.
• Validation mechanism: tests, assertions, business rules, security and compliance constraints.
• Refinement loop: controlled correction of the solution, with limits on time, cost and number of attempts.

It is significant that agent maturation does not lead from Software Engineering toward magic, but from prompt improvisation toward architecture, states, protocols, validation and recovery mechanisms. The profession moves from prompt designer toward system architect.

Context as the core of the state of the agent’s universe

In the InfoQ issue, context is treated as infrastructure for reasoning: information selected, filtered, ordered and updated before reaching the model. This formulation is familiar to me, but the connection with my own research is stronger than I initially stated. In agent-based design, context is the core of the state of the universe that the agent must perceive, interpret and be able to act upon. The agent does not operate on reality in its entirety, but on a relevant representation of it.

In the 2003 works on Agent-Based Modeling of Virtual Environments and on agents based on virtual perception, the problem was already that of constructing the world accessible to the agent. The field of perception, the nimbus of entities, the degradation of information with distance and the transformation of perceptions into action concepts delimited the agent’s effective universe. Not everything that existed in the virtual environment as a reflection of reality automatically became part of its internal state.

Later, in Strengthening Context-Awareness of Virtual Species in Digital Ecosystems, context was extended to several facets of the modeled reality — clinical, environmental, emotional/BDI and social — and obtained through context-gathering agents and an integrating agent. Context was therefore no longer merely an informational appendix, but a distributed construction produced and maintained by mechanisms provided by the architecture.

Adaptive context and a mutable state space

Adaptation does not mean only updating the values of state variables within a fixed schema. Reality changes, but the agent’s objectives also change. When the objective changes, some information becomes useless, other information becomes indispensable, and the space of state variables must itself be reconfigured. This is structural adaptation, not merely parametric adaptation.

In Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem, adaptability was connected to the continuous relationship between reality and its digital representation in the R2V2R paradigm, as well as to the evolution of virtual organisms in a multi-agent ecosystem. In Evolution of Digital Species by Using Mutable Contexts, the idea becomes explicit in the title itself: species in a digital ecosystem can evolve by using mutable contexts.

This distinction is important for the present architecture of agentic AI systems. A context engine that merely replaces old data with new data remains insufficient. It must be able to modify the context model: to add sources, variables, relationships and constraints required by the new objective, and to remove elements that no longer contribute to the decision. Otherwise, the agent remains imprisoned within an ontology of the problem that was established too early.

Who modifies the agent’s relevant universe?

The decisive architectural question is who performs this restructuring. The first possibility is the adaptive agent: it observes its own results, detects the insufficiency of its context, seeks new sources, modifies its internal representation and obtains the tools required by the new universe. This solution offers autonomy, but makes traceability more difficult, because the agent becomes both user and designer of its own informational world.

The second possibility is a context manager situated at a higher architectural level. It knows the objectives, policies, access rights, available sources and expiration rules; it builds the appropriate context for each agent and modifies it when reality or goals change. In a multi-agent architecture, the context manager may itself be a meta-agent or a common service of the ecosystem.

The realistic solution will probably be hybrid. The agent may propose changes to the context, but a higher level validates and authorizes them and preserves the memory of the transformation. Here we find again the separation between strategic and operational control from my research on the software process: the agent decides within a framework, while the higher architectural level controls how the framework itself may evolve.

From agent to digital ecosystem

Another direct connection with my work is the idea of the digital ecosystem. An agentic AI system is not merely a program divided into several intelligent modules. Agents form a population of autonomous entities, with their own roles, objectives, resources and contexts. They cooperate, support one another, negotiate, delegate activities, may enter into conflict and may produce different solutions to the same situation.

In Conceptual Modeling of the Healthcare Ecosystem and Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem, the transition from system to ecosystem meant precisely abandoning a rigid, centralized infrastructure in favor of a dynamic environment of cooperation among actors, services, organizations and digital resources.

In Agentification of Electronic Healthcare Record Systems, this idea was continued through virtual organizations created around patient-care processes, with a manager able to constitute, coordinate and dissolve them. Agents became context-aware and goal-oriented, while avatars of human actors could take part in cooperation, negotiation, mediation and adaptation.

The present architecture of agentic AI systems returns to the same problem on a new technological scale. An orchestrator must not be merely a dispatcher of model calls, but the temporary governor of an organization of agents. It must manage collaboration, contradiction, consensus, reputation, competencies, authority and the agents’ accountability. In this sense, the notion of ecosystem is more expressive than that of a simple multi-agent architecture.

The integrated toolset: from software environment to agentic framework

The third continuity concerns the toolset. In the book Integrating Tools for Software Development, the software process was modeled as a coherent universe of objects, activities, agents and tools. Integration did not merely mean being able to launch several programs from the same interface. It required common description languages, explicit states and relationships, strategic and operational control, tool libraries, activation rules, exception mechanisms and a machine capable of executing the process.

INTERFORM was precisely the attempt to transform modeling into a configurable executive system: it viewed objects through facets, executed activities, allocated agents, launched tools, changed states and handled exceptions. Seen from this perspective, the current notion of an agentic harness is too modest when it designates only a sequence of prompts or a graph of calls. Serious applications require an integrated framework for the execution and control of AI agents.

Such a framework must integrate not only tools, but also memory, knowledge, context, evaluation and organizational rules. It becomes the infrastructure in which model nondeterminism is transformed into an observable and controllable process. This is, I believe, the most direct connection between my 1992 book and the present problem: not the integration of isolated tools, but the integration of the entire execution universe of the process.

When the system works but makes poorer decisions

Classical distributed systems accustomed us to relatively visible failures: a service does not respond, an operation times out, a response is delayed, data become inconsistent. In an agentic AI system based on LLMs, the infrastructure may remain perfectly healthy while the quality of the result deteriorates.

An agent may choose a weaker source, misinterpret an intermediate result or pass an incomplete context to another agent. The erroneous initial decision influences subsequent steps, and degradation propagates without necessarily producing a technical exception. Latency remains normal and the error rate is low, yet the system answers less well.

New modes of failure

• Cascading decision degradation: an early wrong choice reduces the quality of all subsequent stages.
• Retry amplification: the evaluation mechanism requests new attempts, increasing cost and latency without guaranteeing convergence.
• Silent degradation: infrastructure metrics remain good while usefulness to the user decreases.
• State and context drift: agents work with different or contradictory versions of reality.
• Excessive coordination: the number of agents and interactions creates cost, latency and new points of failure.

Consequently, observability must monitor not only the health of the infrastructure, but also the health of the decision: which tools were selected, which information was used, which alternatives were rejected, how many retries occurred and through what evaluation the result was accepted.

Limited autonomy and extended observability

The term “autonomous agent” may create the impression of complete freedom. In real applications, useful autonomy must be limited. The agent receives a space in which it may choose, not the right to do anything. Time and cost budgets, the maximum number of retries, reasoning depth, tool permissions and accessible data must be architecturally defined.

The InfoQ issue proposes a prudent evolution for the enterprise: first the control infrastructure, then structured autonomy of workflows, and only at the end agents capable of constructing their own strategy. I agree with this idea. Autonomy must not precede governance. Security, traceability, data protection, continuous evaluation and human intervention must exist before the system's freedom is extended.

This prudence is all the more necessary in medicine, finance, industry, infrastructure and public administration. In these domains, the agent may support decisions and automate parts of the process, but the extension of autonomy must follow accumulated evidence, not technological fascination.

A research thread of my own, not a retrospective analogy

The continuity with my work is not limited to the coincidence of a few terms. It can be followed through a sequence of problems that evolved over almost four decades:

• 1981–1992 — the process and the integrated environment: systematic design, the interform, INTERFORM and then Integrating Tools for Software Development, with objects, activities, agents, tools, states and two levels of control.
• 2003 — the agent and the perceived universe: agent-based modeling of virtual environments, fields of perception and the transformation of perceptions into decision and action.
• 2008 — the objectives and concerns of actors: Concern-Driven Design, in which interests, risks, obligations and priorities organize the model and architecture.
• 2011–2013 — adaptability, context and ecosystem: virtual organisms, R2V2R, digital ecosystems, multifaceted contexts, and agents for gathering and integration.
• 2015 — agentification of the infrastructure: the gradual transition from services to virtual organizations of agents and context-aware, goal-oriented avatars.
• 2019 — mutable context: the evolution of digital species through modification not only of state, but also of the structure of context.

InfoQ describes a new technological generation based on LLMs, but the architectural questions do not arise from nothing. What information constitutes the agent's world? How does this world change when the goal changes? Who coordinates the community of agents? How are tools integrated? How are the state and the memory of the process preserved? How are exceptions and conflicts handled? These questions genuinely run through my work, even though today's technological answers are different.

From BDI agents to agents built on LLMs

In my reflections on the future of technology I returned to the BDI model — Beliefs, Desires, Intentions. In the works on virtual agents and, later, on avatars in digital ecosystems, the agent was not merely an executor: it had an explicit representation of the world, pursued objectives and selected its actions according to rules, plans, protocols and models of its internal state. Its autonomy was real, but operated within a conceptual structure designed in advance.

Present-day agents are different not because they discovered objectives, context or cooperation for the first time, but because their decision-making core is a generative model. They can interpret a requirement that has not been fully formalised, produce representations and plans that the designer did not enumerate, generate code, use tools described in natural language and revise their strategy according to results. This capability enormously enlarges their space of action, but reduces predictability in proportion.

They are therefore not simply modernised BDI agents. Their “beliefs” are distributed among active context, persistent memory, domain knowledge, external sources and model parameters; their “desires” come from the objectives of the user, the organization or other agents; their “intentions” appear as dynamically generated, evaluated and revised plans. The BDI model nevertheless remains useful because it forces the architect to separate what the agent holds to be true, what it pursues and the plan to which it has committed itself.

The introduction of mutable contexts adds a problem that the simple BDI scheme does not solve: a change of objective may alter the very structure of the relevant “beliefs”. The architecture therefore needs either agents capable of self-reconfiguration or a metacognitive level — context manager, supervisor or governance organization — that controls the evolution of the agent’s informational universe.

When several agents collaborate, contradict one another or negotiate, individual BDI must be complemented by a theory of organization: roles, authority, protocols, norms, reputation, consensus mechanisms and conflict resolution. Here the architecture of agentic AI systems meets my research on virtual organizations and digital ecosystems directly.

What should be added to Software Engineering education?

In the page on the future of Software Engineering I argued that the student should be trained neither as a mere programmer nor as the operator of an AI tool. The architecture of agentic AI systems reinforces this conclusion, but its connection with the old core of the discipline must be made explicit.

• Modelling the agent’s universe: state, perception, context, knowledge, memory and their relationship to objectives.
• Mutable contexts: the difference between updating values and structurally changing the space of state variables.
• Context management: self-adaptation, meta-agents, selection, expiration and revalidation policies, and traceability of change.
• Architecture of digital ecosystems: cooperation, mutual support, negotiation, conflict, consensus, roles and virtual organizations.
• Integrated frameworks: objects, activities, agents and tools; capability registries, protocols, sandboxes, evaluators and exception management.
• Architecture of agentic AI systems: separation of planning from execution, specialized agents, orchestration and dynamic flows.
• Runtime evaluation: quality criteria, tests, simulation, evaluators and convergence control.
• Decision observability: tracing choices, tools, context, retries and the reasons for accepting the result.
• Agent security: prompt injection, contamination of tool results, limited permissions and task-bound credentials.
• Governed autonomy: guardrails, deterministic fallbacks, human-in-the-loop and progressive rollout.
• Protocols and integration: APIs, asynchronous messaging, MCP, A2A and bounded contexts.
• System economics: token cost, latency, number of model calls and selection of the simplest sufficient abstraction.

Not every student must become a researcher in foundation models. But the future software architect must know how to integrate a probabilistic component into a verifiable system and how to design not only the agent’s behavior, but also its relevant universe, the collectivity to which it belongs and the infrastructure that constrains and explains its actions.

A new family in the history of software architectures

The history of Software Engineering may also be read as a succession of architectural responses to growing complexity. An early landmark was Mary Shaw and David Garlan’s Software Architecture: Perspectives on an Emerging Discipline, published in 1996. The architectural repertoire then expanded rapidly: monolithic programs were followed by layered organization, client–server architectures, components, distributed systems, SOA, microservices, event-driven architectures and cloud-native platforms. Each family changed the unit of decomposition, the form of interaction and the location at which control was exercised.

The architecture of agentic AI systems must be placed within this history. It is neither merely a marketing extension of microservices nor a renaming of multi-agent systems. The central architectural unit becomes the agent based on a generative model, while the object of decomposition shifts from functionality to decision capabilities: planning, search, interpretation, evaluation, execution, memory and supervision.

This does not mean, however, that every application should be transformed into a collectivity of agents. As at every earlier stage, the new abstraction is justified only where the complexity of the problem requires it. A deterministic flow, an ordinary service or a well-known algorithm remain preferable when they solve the problem more simply, cheaply and safely. The new architectural family becomes necessary when the path cannot be completely prescribed, when goals must be interpreted, when the relevant information changes and when the choice of actions depends on evaluations produced during execution.

Decline or return?

I still believe that the classical form of Software Engineering is in decline. There is no longer the same confidence in universal methodologies, exhaustive documentation and the possibility of completely designing the system before implementation. But the architecture of agentic AI systems shows that the disappearance of the classical form does not mean the disappearance of the discipline.

A return may even occur. When automatic code generation seemed to reduce the engineer’s role, the emphasis shifted towards using a ready-made model. Now, with agents, we find that the model alone is not the product. The product is the complete system: models, services, tools, memory, context, evaluators, protocols, access rules, recovery mechanisms and the people accountable for it.

Perhaps the discipline’s name will change or be divided among AI Engineering, Platform Engineering, Systems Architecture and Governance. But the founding concern remains: how do we transform an impressive computational capability at our disposal into a system that is intelligible, reliable, maintainable and accountable?

From programs that execute to systems that decide

The first Software Engineering arose when programs became too large to be controlled by individual talent. The architecture of agentic AI systems appears when the decisions produced by systems become too complex to be left to an isolated model.

We no longer design only programs that execute instructions. We design systems that interpret goals, construct plans, choose tools, evaluate their results and alter their path. This apparent freedom does not reduce the need for engineering. It amplifies it.

Perhaps this is the natural continuation of my earlier reflections. I began by fearing that AI would make programming unnecessary and dissolve Software Engineering. I am now beginning to see the reverse movement as well: precisely because AI can produce code and make decisions, we need a Software Engineering capable of designing the machine’s freedom without losing control over its consequences.

Reading landmarks and my own works

This reflection starts from The InfoQ eMag, Issue #125, July 2026 — Agentic AI Architecture, particularly the following articles:

• Mallika Rao, From Microservices to Agents: The Next Evolution of Distributed Systems.
• Karthik Ramgopal, The Evolution of Agentic Harnesses: From Chains to Graphs to Code.
• Adi Polak, Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures.
• Subash Natarajan and Ahilan Ponnusamy, Agentic AI Architecture Framework for Enterprises.
• Rafał Gancarz, Agentic AI Architecture: Current Challenges and Future Opportunities.

My own works in conceptual continuity

• Integrating Tools for Software Development (1992)
  Modeling the process through objects, activities, agents and tools; integration, state, control and the architecture of the INTERFORM environment.
• Agent-Based Modeling of Virtual Environments (2003)
  Perception, internal state and the universe accessible to the virtual agent.
• Concern-Driven Design (2008)
  Interests, risks, obligations and priorities that organize objectives and architecture.
• Conceptual Modeling of the Healthcare Ecosystem (2011)
  The transition from system to ecosystem and the cooperation of autonomous entities.
• Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem (2011)
  Adaptability, R2V2R, virtual organisms and the evolution of digital representation.
• Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem (2012)
  Specialized agents, organizations and the infrastructure of a digital ecosystem.
• Strengthening Context-Awareness of Virtual Species in Digital Ecosystems (2013)
  Multifaceted context, gathering agents and integration of the relevant state.
• Agentification of Electronic Healthcare Record Systems (2015)
  Virtual organizations, organizational manager, goal-oriented agents and avatars.
• Evolution of Digital Species by Using Mutable Contexts (2019)
  The agent's evolution through structural change of context.

Internal links

• The History of Software Engineering
  The chronology of the discipline, from the software crisis to generative AI.
• The Future of Software Engineering
  An essay-dialogue about the profession, education and the Software Engineering school at FILS.
• Order in Chaos
  The abstract machine, the interform and the INTERFORM project.
• Reflections
  Texts about technology, artificial intelligence, the profession and what remains.