Platform Engineering: platforms serving AI agents

Over the last few years, Platform Engineering has gained ground as a response to a very concrete problem: the complexity required to develop and operate applications grew faster than it would be reasonable to pass on to each development team.

Infrastructure, pipelines, security, observability, policies, environments, shared services, and countless other capabilities began to be organized by platform teams, offering developers standardized paths to consume all of this without having to master every detail of the infrastructure.

Now, a change begins to alter one of the premises of this model.

The human developer is no longer necessarily the only consumer of the platform.

Artificial intelligence agents begin to query catalogs, analyze telemetry, use tools, run workflows, and interact with corporate resources. In more advanced scenarios, they can take part in incident investigation, resource provisioning, and even software deployment processes.

When that happens, Platform Engineering no longer has only people on the other side of the interface.

The platform that was created to abstract complexity for developers begins to need to do the same for AI agents.

This change seems small, but its implications go far beyond simply creating new APIs.

Platform Engineering was born to hide a complexity that should not be everywhere

The principle behind Platform Engineering is relatively simple.

Instead of each team individually assembling its own combination of infrastructure, automation, security, observability, and delivery processes, an internal platform offers shared capabilities, self-service, and predefined paths.

One of the elements used for this is Internal Developer Platforms (IDPs), which organize development and operations capabilities in a standardized way that is accessible to teams.

Service catalogs, templates, standardized environments, automations, and so-called golden paths, recommended paths that embed predefined practices and controls, help reduce the number of decisions each developer needs to make to perform recurring tasks.

The Cloud Native Computing Foundation (CNCF), the organization that maintains and promotes important projects in the cloud native ecosystem, describes this evolution as a way of encapsulating operational practices behind workflows, self-service, and standardized environments, allowing developers to focus more on the functionality they need to deliver [1].

The model worked for years on an almost implicit premise: whoever consumes the platform is a person. It is precisely this premise that Agentic AI begins to change.

The agent also begins to consume the platform

An agent investigating an incident may need to discover which services are related, query telemetry, identify the owner of an application, check a recent change, or trigger an operational workflow.

Another agent, acting in the development cycle, may need to consult architectural standards, discover which components are approved, provision an environment, or start a deployment process.

These are tasks that use capabilities many internal platforms already offer to people.

In July 2026, the CNCF published an analysis on Platform Engineering for agentic enterprises arguing precisely that AI agents are becoming consumers of the platform alongside human professionals. The text cites activities such as infrastructure provisioning, application deployment, incident investigation, telemetry analysis, and execution of operational workflows [1].

Gartner reaches a similar conclusion. In Agentic AI Readiness Requires Platform Engineering, published in June 2026, it recommends that organizations offer automated, standardized paths so that agents can build, deploy, and operate software, using machine-consumable components with built-in governance and validation [2].

We are not, therefore, talking only about using AI to increase the productivity of platform teams. We are talking about something different: AI itself is starting to become a user of the platform.

The same platform, but not necessarily the same interface

People and agents do not need to interact with a platform in the same way.

A developer may use a portal, a command-line interface, or a pipeline. An agent will probably consume these capabilities programmatically.

That does not mean, however, that it is necessary to build a second platform just for AI.

The CNCF analysis argues precisely for evolving the existing platform so that humans and agents can operate on common foundations of identity, governance, security, observability, policies, and lifecycle management [1].

A survey conducted by the CNCF in partnership with SlashData helps show how this movement is already starting to appear. The CNCF Technology Radar Q1 2026, based on responses from more than 400 professional developers, identified different strategies for incorporating AI workflows into existing platforms. Among the 364 respondents who integrated AI workflows, 35% indicated a hybrid approach, with separate experimentation and shared production deployment, while 17% said they had extended their existing development platform to support these workflows [3].

These numbers do not mean there is a definitive dominant model. They do show, however, that companies are already deciding whether AI will be integrated into the existing foundation or treated as separate infrastructure.

Creating a parallel platform for each new technology generation may solve the immediate problem, but it can also create new silos of operations, security, and governance.

For agents, this fragmentation can be particularly problematic because they will need to interact precisely with resources that already belong to the corporate environment.

The platform now has two types of consumers

The evolution of internal portals helps make this change more concrete.

Gartner, in its Market Guide for Internal Developer Portals of July 2026, states that Platform Engineering teams now have the responsibility to improve the experience of both developers and AI agents, maintaining consistent governance and making it easier to discover and access development and delivery capabilities [4].

Red Hat presents a similar view by arguing that the value of an internal portal is not only in its graphical interface. Service catalogs, documentation, templates, ownership, integrations, and policies make up a body of corporate context that can also be consumed by agents [5].

In this model, the portal stops being just a destination the developer visits and also works as a context infrastructure that agents can query programmatically.

This changes how we think about platform experience.

The developer experience remains important, but a kind of agent experience also emerges: can it discover which capabilities exist? Does it understand how to use them? Does it receive only the necessary permissions? Can it access enough context to make a decision? Are its actions recorded?

The questions are different, but the responsibility remains with the platform.

Context becomes part of the infrastructure

This is perhaps the point I consider most important in this evolution.

An agent can have access to excellent tools and still make bad decisions if it does not understand the environment in which it is acting.

To investigate an incident, for example, having access to logs is not enough. It may be necessary to understand topology, dependencies, ownership, recent changes, policies, operational history, and the relationship between services.

The CNCF argues that, as applications, resources, and agents form an interconnected ecosystem, understanding the relationships between these elements becomes as important as managing the elements themselves. Telemetry remains essential, but it needs to be combined with information about dependencies, changes, ownership, and operational knowledge to build a more complete understanding of the system [1].

Red Hat reaches a similar conclusion when discussing portals for agents: the catalog, the standards, the policies, and the documentation that already guide developers become enterprise context that can also guide the actions of AI [5].

The more autonomy we give the agent, the less acceptable it becomes to let it rebuild the company’s context on its own at every decision.

This brings Platform Engineering closer to a theme we have discussed throughout this series: shared operational context.

People, automations, and agents should not build independent versions of reality only to try to reconcile them when something goes wrong.

Serving AI also means governing it

If an agent starts consuming the platform, it also needs to operate within the platform’s controls.

This theme connects directly to what we discussed in AI agents also need identity: who are they and what can they access?

Each agent needs its own identity, bounded permissions, and an audit trail. The CNCF argues that developers, Site Reliability Engineering (SRE) professionals, the discipline focused on the reliability and operation of systems at scale, and agents may use different interfaces, but their actions must remain subject to consistent security controls, policies, and operational limits [1].

Gartner also treats governance and validation built into the paths consumed by agents as part of preparing Platform Engineering for Agentic AI [2].

This is important because the abstraction provided by the platform cannot mean an absence of control, quite the opposite.

If an agent can provision a resource, run a workflow, or start a deployment, the platform needs to know who it is, which actions it can perform, which policies apply, and how to record what it did.

Platform Engineering, identity, observability, and AgentOps therefore begin to meet in the same architecture.

We are not building a platform for agents

There is an important difference between adapting Platform Engineering to Agentic AI and building an entirely new infrastructure around agents.

The first option extends a foundation that already exists.

The second risks recreating, around AI, the same fragmentation problems that Platform Engineering emerged to solve.

The goal should not be to create one path for developers and another completely separate one for agents. It should be to allow both to consume common corporate capabilities through interfaces suited to each, sharing policies, identity, context, observability, and governance.

The CNCF summarizes this evolution by arguing that the next generation of Platform Engineering should extend the existing platform so that applications, resources, and agents can be managed within a common operating model [1].

Red Hat, when discussing the evolution of internal portals, follows a similar direction: the interface may change, but the catalog, golden paths, integrations, and context remain relevant because they now serve two audiences, people and agents [5].

The arrival of agents does not reduce the importance of the platform. It expands who the platform needs to serve.

This may be the main change.

From vision to practice: ARGUS

This evolution has a direct connection to the current proposal of ARGUS.

ARGUS was born with the purpose of correlating events from multiple sources, reducing noise, and building shared operational context. In environments where agents begin to investigate incidents, query resources, and take part in operational decisions, this context can now be consumed not only by people but also by the intelligences that act alongside them.

With the addition of AI Gateway and AgentOps (Agent Operations), this proposal expands. AI Gateway makes it possible to apply policies and control how applications and agents access artificial intelligence resources, while AgentOps expands the ability to orchestrate agents, track their executions and actions, and establish mechanisms for observability, governance, and oversight.

The goal is not to create a parallel infrastructure for agents. It is to allow them to take part in the operation within an architecture in which policies, context, actions, and results can be related.

This means an agent can receive context about what is happening in the environment and, at the same time, its own actions can become part of that context. Decisions, tool calls, changes, events, and results can be related to the infrastructure, to the services, and to the other operational information available.

The platform now also serves AI, but AI needs to operate within the same context and the same governance mechanisms that sustain the operation.

This combination helps prevent the adoption of agents from creating a new isolated layer of technology, with its own view of the environment and its own control mechanisms.

As people, automations, and agents come to share the operation, a common systemic view stops being just a tool for incident investigation and becomes part of the very infrastructure needed to expand autonomy safely.

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.

References

[1] Cloud Native Computing Foundation (CNCF). Platform engineering for the agentic enterprise: Managing applications, resources, and AI agents. Jul. 21, 2026.

[2] Gartner. Agentic AI Readiness Requires Platform Engineering. Jun. 5, 2026.

[3] Cloud Native Computing Foundation (CNCF) and SlashData. CNCF Technology Radar Q1 2026. 2026.

[4] Gartner. Market Guide for Internal Developer Portals. Jul. 15, 2026.

[5] Red Hat. Why developer portals matter more in the age of AI agents. May 7, 2026.