Operations | Monitoring | ITSM | DevOps | Cloud

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a vendor’s cloud. Someone on the data team deployed a LangGraph service to a VM with a database key in an environment variable, and someone else is running an agent framework on a laptop with production credentials in a dotfile. Each of these is a hosting decision.

If you've ever inherited a cluster that nobody fully understands, or watched two teams solve the same infrastructure problem in completely different ways, you've already felt the cost of not having a template strategy. It's not always dramatic; it starts with a different CNI here, a missing cert-manager version there, but it compounds. Six months later, cluster configuration is tribal knowledge, and the platform team has become the bottleneck.

The OpenTelemetry Operator changed how teams approach telemetry collection in Kubernetes. The core appeal of zero-code instrumentation is that you can bring up telemetry inside application containers to collect traces, metrics, and logs without touching your source code or rebuilding your container images. However, if you follow the default OpenTelemetry Operator documentation, you quickly run into a heavy operational prerequisite: the Instrumentation CRD.

Table of Contents Kubernetes resource optimization appears to be a single problem, but the platforms that address it disagree on almost every design decision, starting with how they analyze workload demands. Some set CPU and memory requests from live signals, while others learn a workload’s historical pattern and provision ahead of it.

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms find real problems at a scale no human team can match. But when you read the findings closely, a pattern emerges: agents talked into refunds, transfers, and data leaks they had standing authority to perform. Patching the prompt fixes one phrasing until the next model update.

London has spent decades establishing itself as one of the world’s major technology hubs. Its strength comes from the concentration of AI and technology startups, financial services and fintech, highly regulated industries, universities and research institutions, international businesses and technology companies, alongside a large community of developers and engineers.

The sovereign cloud conversation has been dominated by physical location and legal jurisdiction. Both matter. But there's a third leg most discussions skip: the software stack itself. If the platform running a sovereign cloud is proprietary code controlled by a company in another country, its sovereignty has a soft underside.

Moving the agent off your machine and pointing it at real clusters — read-only, in shadow mode — then climbing a trust ladder toward carefully scoped action. This is the second article in a three-part series on taking an AI SRE agent from a weekend experiment to enterprise production. Part 1 built a local agent on a throwaway cluster: read-only, propose-only, refined against a small eval set, with portable skills and no production write access.

Picture the scene: you’ve just deployed a rolling update to your service. Half of your pods are running the new version, they all passed their readiness checks, and Kubernetes terminated the old replicas. Suddenly, the new pods start throwing 503 errors. Thankfully, you still have pods on the old version, so you stop the update. If the rollout had been a little bit faster, you’d have an outage. This is the failure mode minReadySeconds exists to prevent.