Operational context protects your AI investment

When technology changes faster than investment can mature

In the article “Your company has already invested in AI. But is it getting all the return possible?”, we discussed an important shift in organizations’ agenda. After a first phase marked by experimentation, the adoption of new models, and the development of specialized agents, the question is starting to move beyond simply how much to invest in Artificial Intelligence.

For many companies, the challenge now is to understand how to keep increasing the return on the investments already made and turn initially independent initiatives into a permanent operational capability.

This concern becomes even more relevant when we consider a particular feature of the current technology cycle: the speed at which Artificial Intelligence itself is evolving. Models that were state of the art a short time ago are quickly surpassed, new architectures gain ground, agents incorporate capabilities that did not exist before, and traditional vendors are adding AI features to practically every layer of their products.

For companies, keeping up with that evolution is inevitable, but it also raises a strategic question that does not always receive the same attention as the choice of new technologies.

How much of the investment made today will keep producing value when the technology used to build it changes?

The question is especially important because a corporate AI project involves much more than the cost of a model or a license.

There is investment in integration with existing systems, preparation and organization of information, agent development, construction of knowledge retrieval mechanisms, automations, process definition, team training, and incorporation of the solution into operational routines.

Over time, the organization also accumulates knowledge about how that AI should interpret its environment and act within it. A relevant portion of the investment, therefore, lies in building everything that turns a generic technology into a solution capable of producing value inside a specific company.

That is exactly where a little-noticed risk arises. If this understanding of the organization is too embedded in a given agent, model, or vendor, a future technology change may require not only replacing a tool but rebuilding part of the knowledge that had been structured around it.

In this scenario, the rapid evolution of AI stops being only an opportunity and also creates a problem of preserving the investment.

This concern is starting to appear in research on value creation with AI. McKinsey’s study The State of AI: How Organizations Are Rewiring to Capture Value shows that adoption of the technology has already spread widely, while capturing economic impact at scale remains far more concentrated.

The study draws attention, among other factors, to the need to redesign processes, establish governance mechanisms, and track indicators capable of linking AI initiatives to business results. In other words, the distance between adopting AI and turning it into sustainable value remains significant.

That difference helps broaden our understanding of return on investment. Evaluating ROI only by the immediate result of an agent or a particular use case may be insufficient. In environments where technology changes quickly, we also need to consider how much of the knowledge, integrations, and operational capability built during that project can keep being used when new models, new agents, or new platforms are incorporated.

From this perspective, protecting AI investment does not mean preventing technology from being replaced. It means precisely the opposite: the idea is to build an architecture in which technology can evolve without losing the operational knowledge the organization has accumulated. That knowledge is the asset that the next generation of AIOps associates with operational context platforms.

Not all knowledge built with AI belongs to the AI

This distinction becomes clearer when we look at what happens during the development of a specialized agent. An important part of its capability may come from the model itself and the technical knowledge it already has.

An agent dedicated to databases, for example, may know Oracle or PostgreSQL in depth, another may master Kubernetes, and a third may have great ability to interpret logs, metrics, or traces.

This specialized knowledge can be extremely sophisticated, but it remains, to a large extent, reusable across different organizations. What turns that generic knowledge into specific operational capability is what the company adds to it.

To investigate a real incident, knowing Kubernetes is not enough. You need to understand which applications run in that cluster, which services they depend on, which changes occurred recently, which components support a given business process, and which signals from other platforms help explain the observed behavior. That understanding does not belong to Kubernetes, to the language model, or to the agent vendor. It belongs to the organization.

This distinction already appeared in earlier articles, when we discussed that an agent can know a tool deeply and still not understand the incident. Now, however, it gains an economic dimension.

Every time an organization structures these relationships to make its agents more efficient, it is building an asset. If that asset remains tightly coupled to each individual AI initiative, part of the investment will need to be rebuilt whenever the architecture changes. When it is preserved independently and made shareable, the same knowledge can keep producing value for different agents and future generations of technology.

That is the point at which operational context stops being only a requirement for improving diagnostics and becomes part of the discussion about protecting investment in Artificial Intelligence. The accumulated value no longer lies exclusively in the agent the company uses today and also resides in the representation it has built of its own operation, a representation that can outlive the technologies that helped use it.

This changes the question we should ask when evaluating an AI initiative. Besides asking how much it costs and what result it can produce today, it may be equally important to ask how much of the knowledge we are building with this investment will continue to belong to the company and can be reused when the next generation of AI arrives.

That question will be fundamental to understanding why operational context can work not only as infrastructure for agents, but as a mechanism for preserving and multiplying the technology capital the organization has already invested.

Protecting the investment does not mean protecting the technology

There is a natural tendency to associate protecting a technology investment with the longevity of the chosen solution. For many years, that logic made sense. Large enterprise platforms were acquired with relatively long horizons of use, and architecture decisions often considered cycles of five, ten, or even more years.

In that environment, protecting an investment meant, to a large extent, choosing a technology solid enough to remain relevant for much of that period.

Artificial Intelligence introduced a different dynamic. The speed at which models, agents, and platforms evolve makes it increasingly hard to imagine that the technologies used today will remain unchanged throughout the period companies need to capture the expected return on their investments.

That does not mean current choices are wrong or should be treated as temporary. It only means that a long-term strategy needs to consider, from the start, the possibility of replacing architecture components without rebuilding all the value accumulated around them.

This issue gains importance because corporate investment in AI keeps growing quickly.

According to IDC, in the article A Deep Dive Into IDC’s Global AI and Generative AI Spending, global investment in Artificial Intelligence was projected at approximately US$235 billion in 2024 and is expected to exceed US$630 billion by 2028.

More important than the absolute number is what it represents: as AI leaves its predominantly experimental phase and receives ever larger shares of corporate budgets, technology executives also carry a growing responsibility to turn those investments into measurable results and preserve the value built over time.

In this scenario, protecting the investment should not mean preserving indefinitely the agent, model, or platform chosen today. A more resilient strategy is to identify which components represent replaceable capabilities and which represent knowledge that must remain under the organization’s control.

Models can be replaced by more efficient versions, agents can evolve, and vendors can change, while the relationships among applications, infrastructure, services, events, changes, and business processes continue to represent a reality that belongs to the company.

That separation is exactly what allows operational context to be treated as an asset. The less that context is tied to a specific technology, the greater the possibility of reusing it in new initiatives.

An agent developed today can use it to investigate incidents. Another, in the future, may use it to predict risks, recommend actions, or run automations. The technology responsible for reasoning may change substantially, while much of the understanding needed for that reasoning to make sense will remain the same.

This approach also changes how we evaluate the return on AI projects. Part of the return will continue to be measured by direct gains in productivity, cost reduction, higher quality, or faster processes.

However, as adoption matures, another dimension becomes relevant. How much of the capability built in each project can be reused by the following projects?

The greater that reuse, the less need there is to rebuild integrations, relationships, and contextual knowledge in each new initiative and, consequently, the greater the accumulated return of the AI portfolio tends to be.

This discussion is directly related to a problem that is appearing more clearly in research on corporate AI. In the study The GenAI Divide: State of AI in Business 2025, from MIT, the researchers highlight a significant gap between experimentation and generating economic impact, drawing attention to organizations’ difficulties in turning generative AI pilots into measurable results at scale.

Among the factors discussed is precisely the need for systems capable of learning from context, adapting to the organization’s specific processes, and integrating properly into existing workflows.

This finding reinforces a fundamental difference between simply funding AI projects and building a corporate AI capability. In the first case, each initiative needs to justify its investment individually and often rebuilds part of the infrastructure it needs to work. In the second, investments begin to accumulate on a common base, allowing what was built in one project to reduce the effort required and increase the return potential of the following projects.

In this sense, protecting AI investment stops being a discussion about technological longevity and becomes a discussion about reusing the value that has been built.

The greater the ability to separate the organization’s specific knowledge from the technologies that use it at a given moment, the greater the freedom to incorporate new models, agents, and vendors without abandoning what has already been built.

Operational context creates a reusable base for different agents

This logic is particularly relevant in IT operations because the context needed to understand an incident is, by definition, multi-source. Information from monitoring tools, observability platforms, ITSM systems, inventories, cloud environments, applications, and different infrastructure components needs to be related so that an isolated event can be interpreted within the broader reality of the operation.

When each agent has to build these integrations individually and rebuild its own understanding of the environment, the organization multiplies similar efforts. The investment made to make one agent more efficient rarely benefits the others in the same proportion, and each new initiative tends to carry part of the same integration, contextualization, and maintenance costs.

Even when agents are technically excellent, the architecture keeps fragmenting the investment. As they reach production, running them requires capabilities like those discussed in AgentOps: who will operate AI agents in production?.

A shared layer of operational context changes that dynamic. Instead of each agent individually rebuilding its understanding of the operation, different solutions can consume a common representation of the relationships among events, resources, applications, services, and other relevant elements.

This does not eliminate agent specialization. On the contrary, it lets each one keep doing what it does best, but on a contextual base that does not need to be recreated with each new implementation.

This point is particularly important because specialization and context have different economic natures. An agent’s knowledge of Oracle, Kubernetes, networks, or security can be developed by one vendor and used by thousands of companies.

The context that explains how these components relate within a specific organization, however, needs to be built from that very operation. Precisely because it is specific, cumulative, and reusable, that context can become a technology asset of the company.

When this separation is preserved architecturally, changing agents no longer necessarily means completely rebuilding operational knowledge. The organization can adopt a more efficient technology, replace a given vendor, or try a new generation of models while keeping an important share of what has already been built available.

The earlier investment does not disappear with the technology that used it, because a relevant part of its value remains in the context layer.

That is a fundamental difference between an architecture oriented only toward deploying agents and one oriented toward building operational capability.

In the first, value tends to follow each individual solution. In the second, a growing share of that value comes to belong to the organization itself and can be reused by different solutions over time.

This is also where return, governance, and architecture begin to converge. The more resources companies devote to Artificial Intelligence, the more important it will be to know not only which projects are producing results, but also which assets are being built, who controls them, and how much of that investment can be reused by the next initiatives.

Operational context thus becomes part of a much larger discussion than simply improving incident diagnosis. That includes how artificial intelligence reduces uncertainty before the operational decision. In this way, context becomes part of the very strategy for preserving and evolving corporate AI investments.

Return increases when the next project does not have to start from scratch

There is an important economic consequence when operational context is treated as a shared asset. Each new Artificial Intelligence initiative no longer needs to fully rebuild what previous projects already learned about the organization.

Integrations, relationships between components, dependencies between services, event history, and other information needed to interpret the operation can form a progressively reusable base. In this scenario, part of the investment made in one project also contributes to the following ones.

This logic is quite different from that found in environments where each AI initiative evolves independently.

When different agents build their own integrations, maintain isolated knowledge bases, and individually develop mechanisms to understand the environment, the company may end up repeatedly funding similar efforts. Each project may show a positive return when analyzed in isolation, but the portfolio as a whole accumulates redundancies that make it harder to capture value at scale.

The problem becomes more relevant as the number of initiatives grows. An organization may have agents specialized in different technologies, AI features embedded in observability platforms, internally developed automations, and generative solutions used by different teams.

Each of these initiatives may fulfill its function properly, but that does not necessarily mean the investment made in one of them is increasing the capability of the others. Without an architecture that favors sharing and reusing knowledge, portfolio growth may also mean growing fragmentation.

This is where the discussion about return needs to go beyond the individual analysis of use cases.

The question is still how much a given agent saves, how much it shortens an activity, or how much it increases a team’s productivity, but it now includes another dimension: how much of the capability built by that investment can be used again by the organization?

The greater the answer to this second question, the greater the accumulated effect of investments over time tends to be.

The challenge of turning AI adoption into return

This concern appears clearly in McKinsey’s study The State of AI in 2025: Agents, Innovation, and Transformation. The research shows broad adoption of AI in organizations, but also a significant gap between use and generating business impact at scale.

Among companies reporting greater impact, practices related to process redesign, defining governance mechanisms, and integrating AI into workflows appear more often, reinforcing the idea that return depends on broader changes than simply making new technology resources available.

This perspective helps explain why architecture exerts growing influence on return.

When a new initiative can take advantage of integrations, relationships, and contextual knowledge built previously, the earlier investment keeps producing value even outside the use case that originally justified it. Instead of a succession of independent projects, a cumulative infrastructure begins to emerge in which each new capability can benefit from what the organization has already developed.

The effect can be especially relevant in IT operations. A relationship identified between an application, a business service, and certain infrastructure components can be useful to an agent responsible for investigating incidents, but it does not need to stay restricted to it.

The same relationship can support another agent in analyzing changes, assessing impact, recommending actions, or in future forms of automation that were not even foreseen when that information was first structured.

In this sense, operational context produces a particularly important characteristic for return on investment: reuse. Value is no longer limited to the result produced by a given technology and now includes the possibility of continuously using the knowledge built in new applications.

The more this base evolves, the greater the capacity to incorporate new technologies without fully repeating the investments made in earlier stages.

This change also alters how we should interpret the idea of protecting investment. Protecting does not mean guaranteeing that a given solution will remain in use for many years. In a market transforming as fast as today’s, that would probably be an unrealistic expectation.

Protecting the investment made means increasing the share of the investment that keeps generating value even when the technology components of the architecture are replaced. And operational context becomes particularly relevant because it represents precisely what tends to remain.

Models may change, agents may evolve, and vendors may be replaced, but the need to understand how applications, services, infrastructure, events, changes, and processes relate will continue to exist. When that knowledge is built as a reusable asset of the organization, technological evolution stops threatening the earlier investment and can, on the contrary, increase its value.

Protecting the investment also requires knowing what is being built

This discussion leads to a second dimension that cannot be separated from return: governance. As companies multiply their Artificial Intelligence initiatives, it becomes harder to understand not only how much is being invested, but also which capabilities are being built, which information is being used, which integrations are being repeated, and how much of the knowledge generated remains available to other initiatives.

Governing AI investments, therefore, should not mean only controlling budget, vendors, or model consumption. That discussion also involves situations in which the AI bill grows faster than the return. These elements are important, but they offer an incomplete view of the asset being created.

An organization may know precisely the cost of a given agent and still have little visibility into how much of the knowledge built to make it work can be reused in other projects.

This perspective brings governance and architecture closer together. The more fragmented the context used by the different initiatives, the harder it will be to assess redundancies, identify reusable capabilities, and understand the dependence on specific technologies.

On the other hand, when a relevant portion of that context is treated as a shared capability, it becomes easier to separate what belongs to the organization from what belongs to the agent, model, or vendor used at a given moment.

This separation tends to gain importance as investments increase. The question will no longer be only choosing which projects to fund, but understanding what technology asset each project leaves the organization after the investment is made.

An initiative capable of producing immediate results while also expanding a reusable base of knowledge can generate a far greater structural return than another project whose value remains restricted to the solution that originated it.

That is where return, protection, and governance begin to form parts of the same strategy. Return shows how much value is being produced, governance makes it possible to understand and control how that value is being built, while architecture determines how much of it will remain available when technologies inevitably evolve.

For companies that already have different Artificial Intelligence initiatives, this may be one of the most important questions of the next stage of adoption: are we only funding new AI projects, or are we, with each new project, increasing a capability that will remain the organization’s own?

Perhaps the most durable asset is not the AI itself

The speed at which Artificial Intelligence evolves makes it risky to try to predict which models, agents, or platforms will hold a dominant position in the coming years.

Some technologies used today will certainly keep evolving, others will be replaced, and new alternatives will emerge with capabilities we cannot yet anticipate.

For organizations, this transformation should not be interpreted only as a risk. It also represents the possibility of continuously incorporating better technologies, as long as the architecture allows doing so without abandoning a significant part of the value built earlier.

That is why the discussion about protecting investment needs to go beyond the choice of technology. The greater the volume of resources devoted to Artificial Intelligence, the more important it becomes to identify which assets must remain under the organization’s control and keep producing value regardless of changes in the market.

In IT operations, an important part of this asset lies in the accumulated knowledge about the environment itself and, above all, in the relationships that allow information from different domains to be interpreted as parts of the same operational reality.

This knowledge does not come ready-made in a language model. Nor can it be fully acquired from a vendor, because each organization has a particular combination of applications, infrastructure, services, processes, integrations, teams, and business rules.

An agent may know Oracle, Kubernetes, AWS, or an observability platform in depth, but only the company itself can build and preserve the understanding of how these technologies relate within its operation and how those relationships affect the services delivered to the business.

When this understanding remains spread across independent tools, agents, and knowledge bases, a relevant part of the investment needed to build it tends to remain equally fragmented.

Each new initiative has to rediscover a portion of the operation, rebuild relationships, or develop integrations similar to those already implemented. The cost of this fragmentation does not necessarily show up as a specific line in the AI budget, but it shows in repeated effort, increased complexity, and the time needed for each new initiative to reach relevant results.

An architecture based on shared operational context seeks to reverse that logic. The knowledge built no longer serves exclusively the agent or use case that originally justified its creation and becomes part of a base that can be continuously enriched and reused.

From vision to practice

Investments in artificial intelligence should not depend exclusively on the model or agent chosen at a given moment. There is knowledge about the operation, built over time, that remains valuable even when the organization adopts new technologies.

That is where ARGUS connects to protecting those investments. Through its AIOps capabilities, the platform integrates information from different tools, correlates events, and builds a shared operational context that can be used by people, automations, and different AI agents.

This base allows new use cases to take advantage of existing operational knowledge, reducing the need to rebuild integrations and relationships between systems with each initiative.

With the addition of AgentOps and AI Gateway, ARGUS extends this architecture to also cover agent orchestration, observability, and governance, making it possible to track their activity as AI adoption grows.

The opportunity lies in treating operational context as an asset of the organization, capable of sustaining different applications and generations of artificial intelligence. That way, the value of investments is not restricted to the technology used today and also contributes to the initiatives to come.

Learn about ARGUS and see how it works in practice.

About the author

Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.

He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).

In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.