Design a Company That Doesn't Need Glue

AI can take over the next steps in a process. The more interesting question is why those steps need anything to hold them together.

Polski · Other languages via Substack’s built-in translation

---

The simplest answer to glue is: automate it. A human moves information? Let an agent do it. A human checks status? Add a workflow. A human passes context? Let AI do it.

But that makes it easy to repeat the same mistake with new technology. You replace the human with a system, but leave the company designed the same way.

What interests me now is something else: where does that seam come from, before anyone has to patch it?

In the previous piece, I tried to name the problem. A company can have less and less human execution and still need a human to maintain continuity between its parts. It gets worse when that glue starts flowing upward to the founder.

Now I want to go one step further. Not just find glue, but understand what in the design of the company makes it necessary.

Procedures and processes were the first war on glue

This problem did not arrive with AI. Companies have been trying to reduce it for decades with procedures and processes: checklists, CRMs, and approval matrices. They are all trying to do something similar: make the company less dependent on what a specific person remembers.

A good procedure tells you what to do without asking someone more experienced. A good process defines how work moves from one place to the next. But this approach had a ceiling.

Procedures and traditional automation worked well as long as reality fit into fields and rules someone had anticipated in advance. When a strange email arrived, data was incomplete, or something happened that nobody had documented before, the system stopped.

“Ask the manager.”

And the human came back into the loop.

AI changes two things here at the same time. First, software is becoming much better at dealing with unstructured reality. It can read a message, recognize intent, extract context, and route the issue without requiring a rigid form.

Second, AI changes the economics of building the connections themselves. For years, it could be cheaper to let a human move data between two systems every day than to commission, build, and maintain a custom integration. Today, building a small connector, workflow, or API adapter can be dramatically easier.

For years, a human was the most flexible adapter between systems. Increasingly, that is no longer the cheapest option.

A company should not need a human as its memory

As I design ZHC, I keep returning to one particularly large source of glue: state.

By state, I simply mean explicit, structured answers the company can give to a few basic questions: what exists, what its current status is, what has already happened, and what should happen next.

Every company has some state. The problem is that it is often scattered across CRMs, emails, tickets, documents, conversations, and human heads. Someone knows that a customer is waiting. Someone has to work out which version of the information is current.

If the next part of the system cannot clearly see what exists, what it is waiting for, and what should happen next, we need a human to explain it. And that human becomes glue.

Good state does not make a company autonomous. But it means the company no longer needs a human as its memory.

One thing the discussion around the previous piece made clear is that “shared state” can easily be misunderstood.

I do not mean one giant shared context that every agent reads and writes to.

State should be partitioned. Each piece of state can have clear ownership: one authoritative writer for that state, many possible readers. Each agent should retrieve only the part of state it actually needs for the task at hand.

Not everything belongs in shared state either. Some context can stay local or be exchanged directly between agents when needed.

The goal is not maximum sharing. The goal is to make the minimum necessary state explicit, authoritative, and available to whoever needs it.

That does not mean ZHC has to be fully autonomous from day one. A human can still make decisions, start actions, and set direction. But they should not be needed just so the system knows where it is.

You don’t have to build a Zero Human Company

You do not have to build an AI-first company from scratch to benefit from this. You can simply ask:

Where are people needed because they do valuable work, and where are they needed because the company needs them to stitch its own pieces together?

Zero Human Company pushes that question further. Who does the work and what connects that work are two different problems. AI helps with both, but guarantees neither.

That gives us four possible configurations:

High human execution, high glue. A common small-company pattern.

High human execution, low glue. A well-designed traditional company.

Low human execution, high glue. The founder manually stitches agents together.

Low human execution, low glue. The direction of ZHC.

AI can take over more and more execution. It also helps remove glue: it can interpret unstructured situations and lower the cost of building connections between systems.

But it will not automatically fix a company designed to need a human as the glue everywhere.

Don’t be a surgeon. Be an architect.

An existing company does not have the luxury of a blank slate. It has customers, procedures, and old systems. It has to find existing glue and remove it carefully. Sometimes it has to be a surgeon.

With Zero Human Company, I have another option. I can try to be an architect.

Instead of asking:

How do I automate the human who performs this task?

I can first ask:

Why does this task exist at all?

Why does information need to be moved manually? Why does someone need to remember state? Why does the next part of the system not know what it should do?

Maybe the best answer to some glue is not to replace a human with an agent.

Maybe the best answer is to make sure that seam never needs glue.

Until now, I have mostly been trying to understand what a company like this should be made of. Now it is time to start testing these assumptions in practice.

But where does company design actually begin?

Not with the first support team.

Not with hiring the first person.

Not even with the first customer.

If I want to be an architect instead of a surgeon, I need to start earlier.

Before the product exists.

What works, what breaks, and where humans still matter in AI-native company design.