Operations | Monitoring | ITSM | DevOps | Cloud

In short, automating the AI agent lifecycle is this year’s pitch: Google Cloud’s walkthrough of 30th July 2026 turns the whole thing into a conversation with a coding agent.

In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its own from 2027, and 43% of health systems were piloting agentic AI at the start of this year.

At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts. Coding agents create an interesting problem because, in most organizations, they didn’t arrive through the front door. Few companies ran a platform evaluation and rolled Claude Code out to 500 developers. Developers installed it themselves.

Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple and, I think, correct: the SaaS era rewarded whoever owned the system of record, and the agent era will reward whoever owns the clearinghouse.

Human approval is easy when you are sitting in front of the agent. For an agent running by itself in a cluster, almost none of that holds. You’re in a meeting and your agent is running in a cluster. It has a service account, it has been asked to keep a service healthy, and it has just worked out that the right fix is to roll back a database migration. Nobody is watching it. That was rather the point of deploying it. You want to get notified to approve such an important action.

In short, this is a beginner’s guide to deploying an AI agent on Kubernetes. You will containerize an agent, store its API key as a Kubernetes secret, write a deployment with health probes and resource limits, expose it with a service, and lock down its network egress, in that order, with a working manifest at every step. On a local kind cluster the whole walkthrough takes about an hour.

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.

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.

In short, buried in the transport section of the MCP 2026-07-28 release candidate are three changes that matter more to infrastructure teams than to anyone else: mandatory Mcp-Method and Mcp-Name headers, cache-control-style ttlMs and cacheScope fields, and standardized W3C Trace Context propagation. Together with the stateless core, they turn MCP from a protocol that gateways had to fight into one that meets them halfway.

Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to Calico’s tiered microsegmentation. NSX virtualizes the network layer in ways that Kubernetes doesn’t replicate by default. There is no native concept of a Layer 2 segment or VLAN, for instance.