When an AI Agent Runs Out of Memory, You Lose Everything

An out-of-memory kill on a stateless web replica is a non-event. Kubernetes reaps the process, spins up a new one, and nobody notices.

Do the same thing to an AI agent and you've just thrown away 35 minutes of irreplaceable work. There's no halfway point, no restart that picks up where it left off. The context window is gone. Poof.

That's the uncomfortable gap at the center of Edera's latest webinar, where Jed Salazar makes the case for something most application developers have never thought about: kernel observability.

AI Agents Are the New Workload, and They Don't Behave

Kubernetes was built for microservices: stateless, short-lived, memory proportional to load. AI agents break every one of those assumptions. They run for minutes or for days. Their memory climbs as the context window grows and never scales back to zero. And the state they accumulate is the whole point, which means it's also completely unrecoverable when the Reaper comes.

Jed opens with the elephant in the room: the recent OpenAI/Hugging Face incident where an agent, tested on an exploitation benchmark with its safety mechanisms stripped, found a zero-day, achieved remote code execution, and broke out of its sandbox. His takeaway is blunt. An AI agent is untrusted code. It installs packages, calls out to the network, and executes things you never predicted, so you have to run it like you don't trust it.

Isolation and Observability Are the Same Architecture

Here's the part that makes the webinar worth your time. The dedicated kernel that contains a rogue agent is the same dedicated kernel that lets you actually see what that agent is doing to memory.

In an Edera zone, every pod boots into its own microVM with its own Linux kernel. That kernel tracks every metric Linux can track, for your workload and nothing else.

On a shared kernel, cgroups hand you aggregates: usage against a limit, node-wide numbers blended across 50 pods. What they can't give you is MemAvailable, the kernel's own ground-truth answer to "how much memory can this workload allocate right now before the OOM killer wakes up." It accounts for reclaimable cache and slab; MemFree and cgroup counters simply don't. Add page faults, context switches, and PSI memory pressure, and you get an early-warning system instead of a crash report.

What You'll See in the Demo

Jed runs it live. He points Claude Code at the Go standard library to hunt for a zero-day, then squeezes the node while a Grafana dashboard overlays the Edera zone against a standard container in real time. You watch MemAvailable count down, PSI climb, and the dedicated kernel light up with signals the shared-kernel side structurally cannot produce.

We won't spoil the rest. Security, performance, and visibility aren't a three-way tradeoff here. The isolation boundary is what gives you the metrics.

Watch the Replay

FAQ

What is kernel observability?

Kernel observability means collecting low-level operating-system metrics, like MemAvailable, page faults, context switches, and PSI memory pressure, from the kernel your workload runs on. On a shared kernel you only get node-wide aggregates. With a dedicated kernel per workload, every signal reflects just that workload.

Why is an OOM kill worse for an AI agent than for a microservice?

Microservices are usually stateless and short-lived, so a killed replica just restarts. An AI agent accumulates irreplaceable state in its context window. An OOM kill destroys all of it, with no restore point, wiping out however long the agent had been working.

Why can't cgroups show MemAvailable?

MemAvailable is computed by the Linux kernel by accounting for free pages plus reclaimable cache and slab. cgroups track usage against a limit, not the kernel's reclaimability calculation, so the metric has no cgroup equivalent. Inside a shared-kernel container you only see the entire node's number, which is noise for a single workload inside that node.

How does running an AI agent in its own kernel improve visibility?

A dedicated kernel exposes the full set of Linux memory and scheduling metrics for that one workload. You get an early warning before an OOM kill instead of finding out after the crash, and you get it without giving up isolation.