How much value are you leaving on the table by over-constraining?

There’s a crucial distinction most teams miss: controls and constraints aren’t the same thing. Controls define boundaries — what an agent can access, what it’s allowed to do, where human approval is genuinely required. Those are essential. That’s what the Control pillar is about. Over-constraining is something different: it’s the scaffolding you add because you don’t trust the model to do its job.

Prompt chains, output parsers, retry logic, routing, approval prompts for low-risk actions — each one is a bet that you know better than the model how to handle the task. And models keep improving while your scaffolding doesn’t. It actively fights new capabilities. When a model learns a better approach, your workaround prevents it from using it. You’re maintaining code that solves a problem that no longer exists.

Claude Code’s evolution proves the pattern. With each model upgrade, the team removed code rather than adding it. The architecture is deliberately thin — a single loop, a handful of basic tools, no multi-agent orchestration. The principle: do the simplest thing that works, and let the model do the rest. But the permission system? That stayed, because it’s a genuine control.

The question for your team isn’t whether you have too many controls — it’s whether you can tell the difference between a control that enforces a real boundary and scaffolding that just compensates for last year’s model limitations.

Go deeper: AI Agent Reliability Is Getting Easier. The Hard Part Is Shifting. traces how scaffolding becomes dead weight — and why the real investment is context and permissions, not code.