The Cage Was the Point: Why Enterprises Aren't Ready for Fully Autonomous Agents

The experiment I describe in the side-project post started because of a cage.

Not a hostile one. Not a bad one. A cage built from good reasons: production services that millions of people use every day. Team processes designed to prevent one engineer’s mistake from becoming everyone’s incident. Code review cycles that catch the things fatigue makes invisible. Approval chains that exist because the cost of a bad decision at a company is socialized — it lands on colleagues, on customers, on the engineers who get paged at 2am.

I work at Kleinanzeigen. It’s a great employer. I’m proud of what the company does and how it operates. And after months of doing AI-assisted development inside that environment, I kept hitting a different kind of wall — not a technical one, but a coordination one. I couldn’t find out how far AI could actually go, because every time I pushed at the edges, the system correctly pushed back. A sprint commitment. A review cycle. A conversation about alignment that needed to happen before the decision could be made.

I didn’t resent the cage. I understood it. That understanding is what turned it into an experiment.

---

My Role at the Front

Before I explain why enterprises aren’t ready, I need to explain what I do there.

I don’t just use AI tools at work and keep the results to myself. My role has evolved into something like an embedded AI expert — attending meetings, running workshops, fielding one-on-one questions from colleagues who are somewhere on the climb from “I’ve used ChatGPT a few times” to “I want to understand what this means for how we build software.” I’m usually the person in the room who has tried the thing that the room is speculating about.

That position is earned by doing the experiments first. You can’t teach what you haven’t lived. So I run sessions, hit walls, document what breaks, and bring that knowledge back. The AI I use at work is different from the AI I use on the side project — not the model, but the configuration, the permissions, the scope of what I let it touch. The work environment imposes constraints that make sense for work. The side project environment had none of those constraints, by design, which made it the only place where the real question — “how far can you actually go?” — could be answered honestly.

The distinction matters. I’m not here to criticize enterprises. I’m here because I work inside one, believe in it, and have thought carefully about what AI autonomy requires before an enterprise can safely unlock it.

---

The Questions Nobody Has Fully Answered

Here’s what enterprises are right to worry about, in order of how concretely solvable they are.

Blast radius. If an agent makes a mistake — wrong API call, wrong environment, wrong scope of action — what is the maximum damage? This isn’t a hypothetical. Agents have write access. They can delete things, send emails, commit bad code, provision infrastructure. The question “how do we limit what an agent can affect?” doesn’t have a clean enterprise-grade answer yet. Scoped credentials help. Sandbox environments help. But the mental model of “what is this agent allowed to do, exactly, and how do I verify that?” is still being worked out across the industry. We don’t have the equivalent of Kubernetes RBAC for autonomous agents yet.

Production access. Related but distinct. In a professional environment, access to production systems is controlled, audited, and granted deliberately. An agent operating on behalf of an engineer inherits — or should inherit — the same access constraints as that engineer. But most tooling doesn’t enforce this cleanly. The agent that works great in development has the same credentials as the engineer running it, which means it has access to everything that engineer has access to. That’s not how you’d design it if you were designing it intentionally.

Who is allowed to orchestrate agents? This is the question I ask in every workshop. Not “can you use Claude Code?” — that’s a capability question. But: do you understand what you’re handing off when you give an agent a task? Do you understand when to stop it? Do you know how to read the output critically enough to catch the subtle wrong answers — the code that compiles, the output that looks right, the change that would have been fine in one context but is a problem in this one? Agent orchestration requires a skill set that takes time to build. Handing the tools to someone who hasn’t built that skill set doesn’t give them capability — it gives them responsibility without the judgment to exercise it.

That last one is where most enterprises are genuinely, correctly stuck. And it leads to the insight I think about most.

---

The Thing I Don’t Share

In every workshop, someone asks the same question.

“Can you share your setup? The agents, the skills, the MCP connections — the whole thing?”

The answer is no. And it’s not because I’m protective of my tools. It’s because sharing my setup wouldn’t give them what they’re actually asking for.

My agents work for me because they encode the way I think. The prompts that work in my skills aren’t transferable instructions — they’re compressed versions of my mental model. The vocabulary I use, the way I frame a problem, the assumptions I make about what “done” means: all of that is baked into my system prompt, my CLAUDE.md, the words I reach for when I describe a task. Someone else with my exact directory of skills would still fail at prompts I succeed at, because their background is different. Their words are different. Their intuitions about what an agent needs to hear to do the right thing are different.

I’ve watched this happen. A colleague takes a setup that works for me, runs it on a similar task, and gets garbage out. Not because the tools are bad — but because the prompts are a language, and that language evolved between me and the tools, over hundreds of sessions, shaped by my specific history and thinking. You can’t install that. You can only build your own.

This is a real problem for enterprises. If the value of agentic development is not in the tools but in the engineer’s learned ability to orchestrate them — and I believe it is — then you cannot solve the adoption problem by distributing configurations. You can’t write a CLAUDE.md that works for an entire team the way a style guide works for an entire team. The knowledge is in the heads of the people who built it, and it transfers slowly, individually, through practice.

What I share in workshops is not my agents. It’s the principles. The mental model. The way to think about what an agent needs in order to do a job well. I show people the AI Dev Ladder — the progression from zero-context prompting to full autonomous pipeline orchestration — not as a how-to guide but as a map. You are here. The path goes this way. Go find your own walls.

That’s the only way it scales.

---

Capability and Readiness Are Different Problems

The side project answered the capability question. 847 commits. One engineer. One quarter. A product in production.

The enterprise question is different. It’s not “can AI agents build software?” That answer is yes and has been for a while. The enterprise question is: “can we unlock that capability in a way that doesn’t introduce risk we can’t control, with people who have the judgment to wield it, in systems where the blast radius of a mistake is already managed?”

That question has a more complicated answer. Maybe. Not yet. Getting there.

The cage at Kleinanzeigen wasn’t holding me back from the capability. It was correctly protecting a set of concerns that autonomous agents don’t yet know how to address on their own. Every approval chain is a human judgment being applied to a decision the automated system can’t yet be trusted to make alone. The goal isn’t to remove those chains. The goal is to earn the right to loosen them — one solved problem at a time.

Blast radius control. Solved it? Remove one chain.

Production access governance. Solved it? Remove one chain.

Enough engineers with genuine orchestration judgment. Built it? Remove one chain.

We’re working on all three, in parallel, at different speeds. That work is real, it’s happening, and it’s not going to be finished this year. The enterprises that move carefully here aren’t being Luddites. They’re being engineers.

---

The experiment I ran on the side project wasn’t an escape from the cage. It was a different question being asked in a different room. The enterprise question and the capability question need to be answered separately, or you confuse yourself about what you’re actually measuring.

The cage was the point. Without it, I wouldn’t have needed the clean room. Without the clean room, I wouldn’t have the answer to bring back.

That’s what the frontline is for.