Stop Building AI Agents Like They're Console Apps

I spent three weeks debugging an AI agent pipeline last month that was supposed to handle code reviews. It had access to everything—entire codebases, chat histories, documentation, deployment logs, previous reviews. By week two, the agent was hallucinating connections between unrelated pull requests and retrieving documentation from 2021 that contradicted current standards. The prompt was "smarter." The model was newer. The problem wasn't either of those things. The problem was that I'd built it like a console application with unlimited stdin instead of like a system with resource constraints and governance.

Reading through the AOS (AI Operating System) framework essay made me realize something uncomfortable: we're treating LLM context windows like junk drawers when we should be treating them like kernel schedulers. The difference isn't semantic. It's the difference between a system that works once and a system that works reliably under load, with visibility, and without surprises.

Context as a Schedulable Resource

The core insight here is dead simple but I'd never framed it this way before: context engineering is resource management.

In traditional operating systems, the kernel decides what a process can see in memory, how much CPU time it gets, and what happens when it tries to exceed its boundaries. An AI agent doesn't need a kernel, but it desperately needs someone deciding what it can see.

This is where most agent systems I've seen fall apart. We prompt-engineer aggressively, but we don't govern what data reaches the agent. We treat context windows like they're free. They're not. Every token you waste retrieving tangential documentation is a token you can't use for reasoning about the actual problem.

The framework calls this "context manifests"—explicit declarations of what an agent should see, what it shouldn't, and why. Before the agent runs, someone (or something) has already answered: Which files matter for this task? Which old decisions are still relevant? Which knowledge items are stale? How much of the context budget do we allocate here versus later stages?

The Governance Layers Nobody Wants to Build

Here's what kept me reading: the framework doesn't pretend more agents solve anything. It inverts the question.

Instead of "Can the agent do the task?" ask "What checks the agent's work?"

I've never shipped a system where that second question was properly answered. We had code review. We had human gates on irreversible actions. But we didn't have structural contracts between agents, we didn't have independent auditors of outputs, and we definitely didn't have any mechanism to convert repeated failures into learning instead of buried Slack messages.

The framework sketches these as counterbalances: Context Engineer ↔ Context Auditor, Memory Engineer ↔ Memory Auditor, Prompt Architect ↔ Prompt Evaluator. One side builds. One side checks. One side learns. One side forgets.

This is the operating-system metaphor that actually matters. A real OS doesn't just let processes run. It enforces permissions, isolates processes, tracks resource usage, and cleans up after failures. An AI OS would do the same, but for agents.

What Worries Me About This (And Why I'm Still Convinced)

Building governance layers is unsexy. Nobody gets excited about an entropy manager or a memory auditor. But that unsexy part is probably why I trust it more than the "autonomous swarm" narrative that gets venture capital excited.

I've seen enough systems decay from "temporary" workarounds, duplicated rules, forgotten context decisions, and stale knowledge. The Cursor symlink example in the framework—a decision made but never documented or integrated—is painfully familiar. It's the kind of thing that works until it doesn't, and then someone spends a day debugging why the platform behavior changed.

The entropy-management approach treats this as a first-class problem. Not "can we accumulate knowledge?" but "can we maintain why we accumulated it?"

My Actual Next Step

I'm going to retrofit the agent system I built last month. Not with more agents. With explicit context manifests and an audit trail for what each agent is allowed to see. I'm going to document the boundaries, not just implement them. And I'm going to build a simple review step: before an agent returns a result, something reads that result and asks whether it's structurally valid and actually grounded in the context it was given.

This will be slower than the current system. It will also be maintainable, which the current system is not.

What's the first task you've given an AI agent that surprised you by failing in a way that looked like "too much context" rather than "not smart enough"? I'd genuinely want to hear about it.

Source: This post was inspired by "Toward an AI Operating System: Context Engineering as the First Runtime Primitive" by Dev.to. Read the original article