Part 12 in the series. Previously: Agents Are Agents (Part 11), The Hammer Problem (Part 10), Computational Strategy (Part 9), Model Eats Software (Part 8), On Keeping AI in the Critical Path (Part 7), The Disintermediation Principle (Part 5), Zen of Unix Tools (Part 4).
The Discomfort
Most people cannot sit with not knowing the full state of things.
Not just in software. In everything. In relationships, the impulse is to know what the other person is thinking. In organizations, the impulse is to have visibility into every team, every project, every decision. In parenting, the impulse is to know where your children are, what they’re doing, who they’re with, at all times.
The impulse is understandable. It comes from love, from responsibility, from the reasonable belief that if you can see the whole picture, you can prevent bad outcomes. But it’s wrong — not morally wrong, but factually wrong. You cannot see the whole picture. You never could. The picture is always partial, always stale, always being reconstructed from incomplete information.
The discomfort with this fact is the root of most bad architecture — in software, in organizations, and in life.
The Illusion
Control feels like competence. When you can see all the variables, monitor all the processes, approve all the decisions, it feels like you’re doing your job. The person who has dashboards for everything, who reviews every pull request, who sits in every meeting — that person feels responsible. They look responsible. The organization rewards them for being responsible.
But centralized visibility is not the same as resilience. It’s often the opposite. The more you centralize, the more a single point of failure — you — becomes the bottleneck. The more you insist on seeing everything, the more everything slows down to the speed of your attention. The more you control, the less the system can function without you.
Shared memory feels natural because that’s how human short-term memory works — everything in one place, accessible immediately. But shared memory in a system means shared failure modes. One corruption propagates everywhere. One bad write poisons the whole state. The thing that felt like safety was the vulnerability all along.
This is true in software. A shared-state architecture where every component can read and write the same memory is easy to reason about — until something goes wrong, and then everything goes wrong at once. The appeal of shared state is that you can see the whole system at any moment. The cost is that any moment can be the moment the whole system fails.
It’s also true in organizations. The leader who insists on approving every decision has total visibility and total control — until they’re on vacation, or sick, or wrong. The organization that routes everything through a single decision-maker is a shared-memory architecture. It feels safe. It’s fragile.
The Alternative
The people who build things that actually work at scale — distributed systems, resilient organizations, good families — share a trait that looks like carelessness but is actually the deepest form of responsibility: comfort with ambiguity.
They don’t need to see the whole state. They design so that the whole state doesn’t need to be seen by anyone. They don’t prevent failure. They make failure recoverable. They don’t control agents. They trust agents and build systems that recover when anyone makes a mistake.
Joe Armstrong designed Erlang around a single assumption: everything will eventually fail. Not might. Will. The only honest response is to make failure recoverable — isolated processes, supervision trees, let it crash and restart clean. This wasn’t pessimism. It was the most realistic form of optimism: if you design for failure, the system survives things you never anticipated.
The same principle works in organizations. The best leaders don’t prevent their teams from making mistakes. They build environments where mistakes are recoverable — where decisions can be reversed, where deployments can be rolled back, where someone can say “I was wrong” without the whole system collapsing. The goal isn’t a team that never fails. It’s a team that recovers fast.
And in families. You cannot control your children. You can try — and the more you try, the more brittle the system becomes. The kids who were never allowed to fail don’t know how to recover when they inevitably do. The parents who need to see the whole state at all times build children who can’t function without being seen. The alternative is harder and scarier: build children who can fail safely, recover on their own, and come to you not because they have to but because they trust you.
The Tell
How someone architects a system reveals how they think about control.
Shared state and orchestration: “I need to see everything.” Message passing and supervision: “I trust the agents and design for failure.”
The person who builds a centralized AI agent framework — where every agent call is routed through an orchestrator, where all context is shared, where the system can’t function without the coordination layer — is expressing a relationship with control. They need to see what every agent is doing. They need to approve every action. They need the dashboard.
The person who builds with isolated agents, message passing, and supervision trees is expressing a different relationship. They accept that they can’t see everything. They design for the world as it is — partial, asynchronous, failure-prone — and build recovery into the architecture instead of prevention into the process.
This isn’t just an engineering preference. It’s a worldview. When the technical requirements don’t force the choice — when you’re not bound by ACID transactions or hard real-time constraints — the architecture reveals the architect. The person who defaults to orchestration when isolation would work is telling you something about how they think. The architecture is the autobiography.
You can see it in how companies adopt AI. The ones that are comfortable with ambiguity give an AI agent tools and let it work. The ones that need control build approval chains, review layers, orchestration frameworks — all of which slow the agent down to the speed of human oversight, which defeats the purpose of having an agent at all.
The enterprise reflex — “we can’t just let an AI agent do things” — is the same reflex as “we can’t just let engineers deploy” and “we can’t just let teams make decisions.” Sometimes it’s justified: some domains involve genuinely irreversible actions where prevention is the only option. But more often it’s the desire for control dressed up as risk management. The actual risk management would be: minimize the set of irreversible actions, make everything else recoverable, then let the agents work.
The Hard Part
The hardest skill in engineering is not technical. It’s emotional.
It’s accepting that you can’t prevent failure, you can only make failure recoverable. It’s letting go of the need to see the whole state. It’s trusting that isolated processes communicating through messages will produce a better outcome than a single centralized controller trying to manage everything.
This is uncomfortable. It goes against every instinct that says “if I just look harder, I can prevent the bad thing from happening.” But looking harder doesn’t prevent bad things. It prevents you from building systems that survive bad things.
The systems that work — the telephone networks that never went down, the internet that routes around failure, the Unix pipelines that compose indefinitely — were all built by people who made peace with ambiguity. Who designed for a world where state is always partial, messages might not arrive, and any agent can fail at any time.
That peace isn’t resignation. It’s the prerequisite for building something that actually works.
The Letting Go
Every generation rediscovers this. And every generation resists it.
The internet protocols were designed for unreliable networks — messages get lost, routes change, nodes go down. Then people built centralized web applications on top of them. Then they had to rediscover distributed systems when the centralized approach couldn’t scale. Then they built orchestration layers on top of the distributed systems — not all of which were centralizing (Kubernetes itself is a distributed reconciliation loop), but many of which reimposed the single-point-of-control pattern the distributed architecture was supposed to eliminate. The cycle repeats because the desire for control reasserts itself faster than the lessons of distributed systems can be internalized.
AI agents are the latest iteration. The technology is new. The cognitive pattern is ancient. The people building shared-context orchestration frameworks for AI agents are doing the same thing the people building J2EE application servers did in 2002, the same thing the people building internal clouds did in 2012, the same thing people have always done: reaching for control because ambiguity is uncomfortable.
The alternative has always been the same. It was the same in Erlang in 1986. It was the same in Unix in 1973. It will be the same in whatever comes after LLMs.
Accept that you can’t see the whole state. Design for recovery. Trust the agents. Let it crash.
The discomfort never goes away. You just learn to build with it instead of against it.