AI agents barged into our ordered world – here’s how we restored order with an enterprise agent control plane

As someone coming from the DevOps and platform engineering world, I appreciate moving past all the AI buzzwords and looking at the tangible value.

We’re used to our world of DevOps and platform engineering practices where automation and control are valued, and we have it all figured out. We have our source code that is built into JARs and WARs, then deployed on application servers. CI/CD is the principle we live by. Apps live in their specific security context, they are observable, and we apply FinOps practices. We have our governance processes in place and we, much like Nicelanders, LOVE our ORDERED world!

Then AI agents came in! As much as they are useful, they completely break our established order. What are they even, are they apps, or microservices? What is their source code? How do you compile them? Where do you run them? Which models do they use? How do you make sure they access only what they are allowed to? How do you prevent them from running in infinite loops burning down your credit card? Left unattended, they tend to make a mess and break stuff.

What is CI/CD in the agentic world? And please tell me how to restore order in my little town now that AI agents barged in.

AI agents are obviously here to stay. So, we might as well get used to them and provide them the necessary infrastructure so we can again have order in our little town.

Agents are quickly becoming first-class citizens and they will need the same care as apps have today. That means providing ways to look them up in a repository and version them. They would need a runtime environment. Good news is that if you’re using containers and some flavor of Kubernetes, you’re good to go. You also need observability mechanisms, security policies, a way to track runtime costs. In short, when you zoom out your landscape, you shouldn’t be able to distinguish agents from apps, they should all be small entities generating value and conforming to the same governance process. It should be the same town with familiar infrastructure that is slightly adjusted and improved to welcome new citizens.

Apps vs. agents – more evolution than revolution

Agentic world doesn’t eliminate decades of software engineering practices. Some of them will, truth be told, be redefined to adjust to new paradigms and capabilities, but sound first principles will remain. If you’re wondering how this new agentic world stacks up to the old one, you’re not alone. I’ve been asking myself the same question, and Milan Jovanović helped me wrap my mind around it:

Versioning (Where is the source code stored and how is it versioned?)

• Apps: Source code lives in Git. Versions are commits, tags, branches, dependencies, container image tags, Helm/Kustomize manifests.
• Agents: Agent source is also versioned: prompt/instructions, tool access, skill docs, model/runtime settings, evals, guardrails, and deployment manifests. The “source” is broader than code.

Build (How are they built into an executable?)

• Apps: Code is compiled or packaged into JAR/WAR/binary/static assets, then usually into a container image.
• Agents: The execution harness is built like normal software, but the agent itself is usually packaged as configuration: instructions, tools, skills/context, model settings, permissions, and runtime parameters. That config can be packaged in harness-specific formats, for example Claude, Codex, or another agent runner, or in more universal/distributable forms such as OCI artifacts/images when you want registry-based versioning, signing, promotion, and reuse.

Deployment (How are they deployed in runtime environment?)

• Apps: Deploy a service to Kubernetes/OpenShift: Deployment, Service, Route/Ingress, ConfigMaps, Secrets, PVCs.
• Agents: Deploy an agent definition and run policy. Some agents are long-running, some are job-like, some are event-driven. The platform schedules runs, injects config/credentials, and connects the runtime to the control plane.

API (How do you control on which URL the service is available?)

• Apps: Expose HTTP/gRPC endpoints through Service + Route/Ingress/API gateway. URL ownership is a normal platform concern.
• Agents: Agents may not expose a public URL at all. They are controlled through a control plane: start run, stop run, resume/fork, send event, inspect result. If they do expose interaction, it is often via UI, webhook, chat, queue, or MCP/tool interface.

Testing (How do you test it?)

• Apps: Unit, integration, contract, e2e, performance, security tests. Expected output is mostly deterministic.
• Agents: Still needs normal tests for runtime/tools, plus evals: task success, regression prompts, tool-call correctness, safety checks, golden scenarios, human review, and cost/latency thresholds. Outputs are probabilistic, so tests need tolerances and judgment.

Promotion (How are they promoted to next environment, i.e. TEST -> UAT?)

• Apps: Promote image/config from DEV → TEST → UAT → PROD using CI/CD or GitOps. Same artifact, different environment config.
• Agents: Promote agent definition, runtime version, skill/tool versions, model choice, policies, and eval baseline. Promotion should require eval pass, permission review, and often staged rollout because behavior can change without code changes.

Security (How is the user authenticated and how are app or agent aware of user credentials they are working with?)

• Apps: User authenticates to app; app uses service accounts, secrets, OAuth tokens, RBAC, network policy.
• Agents: Same base controls, but sharper permission boundaries. Agent must know what it may do, which tools it may call, whose credentials it acts with, what data it may read/write, and how actions are audited. Least privilege matters more because the agent can decide paths dynamically.

Observability (How do are logging, audit and tracing implemented?)

• Apps: Logs, metrics, traces, audit events, dashboards, alerts. Focus on requests, errors, latency, saturation.
• Agents: Add agent-specific telemetry: prompts/events, tool calls, decisions, run state, model/provider latency, token usage, output artifacts, approvals, retries, and full audit trail. You need to answer “what did it do and why?”

FinOps (How do you track/control costs?)

• Apps: Track infra cost: CPU, memory, storage, network, licenses, environments. Control via quotas and autoscaling.
• Agents: Track model/API spend too: tokens, tool calls, runtime duration, retries, parallel runs, per-project/user/agent quotas. Cost control becomes part of orchestration, not just cluster capacity planning.

The platform side: familiar infrastructure, new control plane

From the infrastructure point of view, things are a bit simpler. Agents are not flipping existing runtime concepts on their head. On the contrary, they play nicely with our existing infrastructure. We can bundle them in containers and run in existing Kubernetes-based environments. However, this is where similarities with apps end. The devil is, as always, in the details and agents follow their own implementation concepts. Therefore, to control them, we can’t simply use existing control planes used for managing apps. Kubernetes console doesn’t cut it alone. We need a bigger boat, a control plane that is aware of agentic concepts and gives us full control over them.

While there are many excellent solutions for implementing the control plane in the app world, the agentic world is still a rather uncharted territory. However, every organization that wants to run and scale agentic workloads inside real enterprise environments, instead of unmanaged experiments, will need to eventually have one. An enterprise control plane that allows organizations to adopt AI agents safely, transparently, and at scale should at minimum consider the following:

• Runtime aspect – A platform for running AI agents inside enterprise infrastructure with governance, auditability, quotas, and observability.
• Governance aspect – A control plane for platform teams, security leadership, engineering leadership, and company management that need controlled adoption of agentic workflows.
• Workload aspect – A workload-agnostic platform that can trigger and run agents on real events, not only coding prompts.

How we put agents under control: meet GLaDOS

Facing the fact that agents at CROZ have moved past the experimentation phase and have become the new normal, we’ve built our own enterprise agentic control plane. We call her GLaDOS, as a reference and tribute to Portal 2 game <3

GLaDOS is our enterprise agent control plane for governed, scalable AI workloads across the software delivery lifecycle and other organizational processes.

She is operator-managed and Kubernetes-native, designed to run on infrastructure that we already trust: OpenShift and other Kubernetes distributions. She has a control plane, dashboard, runtime container, operator, and proxy sidecar. Agents run as isolated workloads in pods with multiple execution modes, including event-driven runs and an orchestrator that can spawn governed child runs. Security boundaries are explicit: OIDC for users, shared bearer between dashboard and control plane, per-instance HMAC for runtimes.

The interesting part isn’t that she runs agents. Plenty of tools do. It’s what sits around the agent:

• A policy engine with real approval gates, so a human signs off before an agent does something that matters. It’s real separation of duties, not just a checkbox.
• Cost you can actually see and cap — cost is attributed per team, with budgets that stop runs instead of explaining them after the bill arrives.
• Access that reuses your existing Kubernetes RBAC, and an audit trail that exports straight into the SIEM your security team already runs.

GLaDOS is our opinionated way of implementing an enterprise agent control plane. Your mileage will most certainly vary, and precisely for that reason, we didn’t build GLaDOS as an off-the-shelf product. We’ve built her as a configurable, extendable, “80% ready-made” asset that does the heavy lifting, allowing you to still customize her and tailor her 100% to your own specific needs.

In times when development is getting more affordable and organizations look for any leverage to differentiate themselves, we believe that building off-the-shelf products doesn’t do any favors to our clients. It can’t help them differentiate. It can’t help them fully utilize their specific context. Therefore, our approach is to build powerful, extendable components that we, and our clients, can use to make the most out of our current technical landscape, without imposing any implicit constraints that come with off-the-shelf products.

If your organization has moved past experimenting with AI agents and is now looking at how to scale them safely, we’d love to talk. At CROZ, we help enterprises design and implement agent control planes tailored to their existing tech landscape, so governance, observability, and cost control come built in from day one, not bolted on after the fact. Reach out to us to explore how we can help you build the platform that fits your organization like a glove.