The current dynamics around AI agents are strongly reminiscent of previous IT technology cycles. Teams are experimenting, new frameworks are emerging almost weekly, the first productive use cases are delivering impressive results - and at the same time, a new operational ecosystem is already beginning to form

Copilots, agent frameworks, RAG pipelines, AI workflows, model gateways, vector stores, agent runtimes and specialized platforms are currently being created at high speed. This is understandable. Companies want to use AI productively as quickly as possible. Many of the new solutions address real challenges around evaluations, governance, tool integration, prompt management or observability. Nevertheless, a fundamental architectural question is worthwhile:

Is this where the next generation of integrated platform capabilities is emerging - or the next generation of operational silos?

This is exactly where the topic becomes interesting for platform engineering and cloud-native architecture. After all, perhaps the most important finding is not that AI agents need completely new platforms.

Perhaps the most important insight is:

AI agents are operationally closer to microservices than to magic.

The surprising finding: Agents are workloads

If you look at current AI agents soberly from the point of view of operations and platform architecture, they are surprisingly familiar. Behind all the "Agentic AI" rhetoric are ultimately systems with classic operational requirements:

Runtime
Network
Scaling
Secrets
Observability
Lifecycle Management
Policies
Rollbacks
Ownership
Deployment Pipelines

An AI agent needs access to data, APIs, models, and tools. It needs to be versioned, secured, monitored, and rolled out. These capabilities have been at the core of modern cloud-native platforms for years.

This doesn't mean that agents are simply new REST services. They have additional characteristics such as reasoning-based decisions, probabilistic behavior, or dynamic tool usage. Operationally, however, they are surprisingly close to existing cloud-native workloads.

An important consequence follows from this:

Perhaps AI agents do not need their own platform world in the long term.

They need good platforming skills. But they don't necessarily have to be created in a new, parallel AgentOps world.

Technological freedom does not mean platform anarchy

A strong argument from the microservices world remains correct: Freedom of technology should enable teams to select technologies that are suitable for their context.

But freedom of technology does not mean that every team has to reinvent everything. It only works with framework conditions:

Safety requirements
Reference implementations
Golden Paths
Observability-Standards
Deployment-Patterns
Governance as code
common operational capabilities

A team should be able to decide whether to build an agent with Python, Java, TypeScript or a specialized framework. However, it should not have to clarify for each agent how secrets work, how OAuth2 is connected, how logs are created, how metrics are collected, how images are hardened, how a rollback works, how LLM tokens are to be procured, how LLMs are called or how LLMs are operated.

This is exactly where the strength of existing cloud-native platforms lies. They allow technological diversity beyond common operating principles and provide proven solutions out-of-the-box where teams shouldn't build them every time.

The problem isn't just AI – the problem is platform proliferation

Many companies are already familiar with the pattern. A team operates a system. Then it has to register, document and maintain this system manually in many places:

API-Management
Enterprise Architecture Management
Developer Experience Platform
Security and firewall processes
IT Design Documentation
Logging and monitoring platform
Data Platform
Data Product Catalog
AI Agent Platform

Every platform has good reasons. Each governance requirement is understandable individually. But in sum, a problem arises:

The complexity moves to the team.

And thus exactly where it causes the greatest damage: into the workflow of the people who are actually supposed to provide professional value. This is where team psychology becomes relevant. Bureaucratic platform work creates cognitive load. It leads to context switches, waiting times, manual synchronization and declining ownership. All these platforms are needed to comply with and implement standards and governance. Governance remains important. It becomes critical where it no longer acts as an integrated platform capability, but ends up as additional manual work for the team. Then it is decided how much governance can take place in an automated, declarative, and platform-integrated manner before it paralyzes teams.

KISS is not a naive desire for simplicity

KISS - Keep it simple, stupid - is sometimes treated like a calendar saying in architectural discussions. That's a mistake.

At this point, it's not about simplicity as a matter of taste. It's about the operational consequence of platform proliferation. If every new topic creates a new platform with its own governance, processes and maintenance, not only does the technical complexity increase. It also increases the cognitive burden on the teams. That's exactly why KISS is not a calendar saying in this context, but an architectural principle.

Simplicity is not just an architectural feature. It has operational relevance. Complexity generates measurable costs:

more effort for coordination
More dependencies between teams, technologies, and platforms
more cognitive load for each individual and thus less productivity
more sources of error and thus more errors
Slower changes and thus poorer time-to-market
Poorer traceability (audits), who is responsible for what

The research situation supports this direction, even if it is rarely referred to as KISS.

DevOps Research and Assessment (DORA) shows that loosely coupled teams and architectures create better conditions for continuous delivery. DORA's research on platform engineering also shows that internal developer platforms can improve productivity, team performance, and organizational performance – when aligned with developer independence .

Team Topologies also points out that cognitive load is crucial for strong team effectiveness. Or as Martin Fowler says:

The primary benefit of a platform is to reduce the cognitive load stream-aligned teams.

Cognitive load is also not a marginal topic in software engineering research. According to a study, cognitive load is an indicator of know-how exchange, productivity and quality

For overall architecture, this means:

A platform strategy is needed.

When separate platforms are created for API, Data, Security, Developer Experience and AI, not only does the number of technical systems increase. The mental burden on teams also increases. And at some point, it becomes a corporate risk.

AgentOps as an extension of the platform

AgentOps is needed. Agents also need lifecycle management, governance, evaluations, observability, and security. The key is whether these capabilities emerge as another separate platform or are deployed as an integrated part of existing cloud-native platforms.

From my point of view, there is a lot to be said for integration into the existing cloud platform:

Agents are workloads.
Agents need identity.
Agents need network.
Agents need scale.
Agents need secrets.
Agenten brauchen Deployments.
Agents need observability.
Agents need policies.
Agents need ownership.

All of this already exists in modern cloud platforms. What is missing are AI-specific extensions:

LLM Gateway
LLM Security Policies
Tool (& Data) Invocation Governance
Prompt and agent versioning
Cost and token transparency
secure reference images

Of course, you get a lot of this with a dedicated AI platform. But you often also get the additional complexity and the disadvantages described. Therefore, you should first check which AI-specific platform capabilities can be provided on the existing cloud platform.

Make-or-buy is not the actual dividing line. Purchased components can also be part of the solution. The decisive factor is whether they are integrated into the company's own platform or whether another operational silo is created.

Ownership belongs in the specialist domain

A productive AI agent is not a neutral technical artifact. It acts in a business context. It uses domain data, calls domain APIs, knows domain rules, and creates business impact.

Therefore, ownership should also be located where the technical need arises:

The agent belongs to the domain that needs it.

This is analogous to data mesh. Data mesh shifts responsibility for data products to the domains because that is where the knowledge about meaning, quality, use and technical responsibility lies. Exactly the same logic applies to AI agents.

If a team is responsible for a business capability, if it operates the associated microservices, and if it is responsible for the data products of that domain, then it should also be responsible for the agent who extends that capability.

An agent is then not a central AI artifact. It is another component of the domain.

Team Topologies: Healthy teams own their systems

Team Topologies has made an important point very clear for modern organizations: A healthy, stream-aligned team needs ownership of its systems and as few external dependencies as possible.

This is not a romantic idea of autonomy. It is a prerequisite for flow.

DORA describes loosely coupled teams and architectures as the basis for teams to deliver independently: Teams should be able to make major changes outside the team without permission, complete work without fine-grained coordination, and deploy independently. It is precisely these characteristics that improve software delivery performance.

Team Topologies formulates the same idea from the point of view of team psychology: Platforms are valuable when they reduce the cognitive load on teams. Not when they create new mandatory processes, new forms and new manual maintenance tasks.

Consequently, AI agents should also be able to emerge in the same way as microservices and data products: from the team, with the way of working chosen in the team, along existing domain boundaries, with clear responsibility but on a platform with common guardrails. The goal is not maximum freedom without a frame. The goal is: Team autonomy within shared platform capabilities.

Kubernetes is here to stay

Kubernetes isn't perfect. Kubernetes is complex. And yet, Kubernetes has established itself in many organizations as a common abstraction for modern workloads. The reason isn't that Kubernetes makes every single task easier. Kubernetes creates a common operating platform:

declarative Deployments
Horizontal scaling
Health Checks
Service Discovery
Secrets
Config Management
Network Policies
Workload Identity
Scheduling
Rollouts and rollbacks
Operators and Custom Resources

Or to put it bluntly:

Kubernetes is here to stay.

Not because every team has to love Kubernetes. It's because DevOps and platform teams can customize Kubernetes to suit their own needs, and because it works as a common integration surface for many workload types.

If AI agents now become productive, the question arises:

Can the existing cloud platform be extended to also serve as an AI agent runtime?

Scaling: An agent should run when it is needed

An agent is operationally a workload. That's why it should behave like a workload. If an agent is not needed, it should not run. If it is rarely needed, it should run small. And if it is used heavily, it should be able to scale horizontally.

This is not an exotic AI problem. This is a classic platform problem.

Kubernetes is an autoscaling-capable runtime. Event-driven workloads and serverless patterns provide already established answers. Agents should use these answers instead of reimplementing them in a special platform.

This is particularly relevant for AI, because costs are not only incurred by CPU and memory. LLM calls, GPU usage, embedding, vector search, and tool calls generate variable costs. A platform that treats agents like workloads can make these costs visible and technically limit them.

Security starts with identity

Many protocols designed specifically for agents are currently being hyped. Attempts are being made to implement existing security mechanisms in these protocols after the fact. It's not that simple. Existing security best practices did not emerge overnight.

If an agent is another microservice, then it can also be secured like another microservice. OAuth2, JWT, Workload Identity, Service Accounts, AD Groups, and existing IAM solutions are not suddenly irrelevant just because the workload is reasoning-capable. They can be used for AI agents. They are battle-proven and already on board. Let's use them. An agent needs its own identity. Not the identity of some generic technical user. Not hidden behind the identity of a human being. Not as an anonymous call from an AI platform. But as a clearly recognizable digital actor.

What is the agent allowed to do?

The answer should come from domain responsibility.

An agent is a member of the domain that is responsible for him. If the domain has an AD group, then the agent can be assigned to this group. He is then allowed to use the data and tools for which this domain is authorized. This sounds simple, but it is crucial for the implementation of the domain ownership principle.

If the customer service agent belongs to the customer service domain, then he is allowed to process customer cases if exactly this authorization has been assigned. However, he is not allowed to automatically read HR data, trigger finance actions or change production systems. To do this, he would need separate explicit authorizations of the foreign domain. To avoid this, each domain provides its own agents, which it is responsible for.

Analogous to the tools: the question "Is the agent allowed to call a tool?". Yes, if his identity has been authorized for it. And if not, then not. Just like with any other service.

Tools must be able to distinguish between machines and people

It must not happen that target systems cannot distinguish whether an action was triggered by a human, a classic service or an AI agent.

Traceability is key, especially with agents. According to the EU AI Act, the following points must be transparent:

Which agent performed the action?
In which version?
On what mission?
With which tool?
On the basis of what justification and justification?
Was the action delegated directly by a human?
Or triggered autonomously by agent logic?

The audit log of the target system must show whether it was an agent, a service or a human. Not as subsequent reporting. But as part of the security model.

LLM Security is a Platform Task

AI agents bring new security risks: prompt injection, data leakage, unwanted tool use, insecure retrieval contexts or unsuitable model choice. This is precisely why the reflex quickly arises to introduce a ready-made AI platform that encapsulates these risks.

That can make sense. But it only solves part of the problem. When AI becomes strategic for core processes, business models or the handling of critical company data, it is not enough to view LLM Security as an isolated product function. Then the integration sovereignty must remain with the company's own platform architecture: identity, data classification, model releases, audit, policies and tool authorizations must interact with the existing governance mechanisms.

Make-or-buy is therefore not the actual dividing line. The strategic question is whether control over identity, data classification, model access, audit and governance remains within one's own platform architecture.

Therefore, these risks speak in favor of common platform capabilities.

The platform should provide hardened images in which key security mechanisms are already pre-implemented:

secure defaults for agent runtimes
standardized logging and audit hooks
Secrets Handling
Policy Enforcement
Output Filtering
Prompt-Injection-Schutz
sichere Tool-Invocation-Patterns
Central configuration for Model Gateways

In addition, security layers are required before the LLM gateway:

Is this agent allowed to call this model?
Is this agent allowed to call this model with this data?
Is the data PII-relevant?
Is the target model shared for this data class?
Was the model explicitly specified or automatically chosen?
Are there any data residency or compliance requirements?

That's platform governance.

Conclusion: The liberation of AI agents does not start with the next silo

AI agents are important. They will become productive digital players in companies. They will read data, use tools, prepare decisions and execute processes.

Precisely for this reason, they must not be operated as a magical special world.

You need ownership. You need identity. You need audit. You need scale. You need security. You need governance. You need platform capabilities.

But much of this has already been learned by modern cloud-native platforms.

Perhaps this is why the real liberation of AI agents is not the construction of a new agent platform, but the integration of AI into the principles that have already made modern software architecture strong:

Domain Responsibility
loosely coupled teams
declarative platforms
GitOps
Kubernetes
Security by Design
Governance as code
KISS as an architectural principle

Or in short:

Agents are workloads. Let's treat them as such.

PS: By the way, this is not just theory. We built a prototype at adorsys and showed it as a demo at CloudLand. If you are interested in what this can look like in concrete terms: feel free to get in touch. I'll show you the demo.

Sources