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.

From the beginning, I knew that in Zero Human Company I wanted to take execution out of human hands. It is the most obvious part of the experiment, and it is exactly where AI is making the fastest progress today. But the longer I design this company, the more clearly I see that automating execution alone is not enough.

Execution can be handed to the system. Being the person without whom nothing moves can remain. That is the trap I am trying to avoid.

AI can prepare an analysis, answer a customer, or carry out the next step in a process. And yet someone may still be needed to pass along context, decide where something should go, and trigger the next step.

There is less human execution. There can still be plenty of glue.

In the previous piece, I divided the work people do in a company into four types: glue, execution, judgment, and expertise. The first two matter especially for ZHC. Execution is simply much easier to see. An executor produces something: a document, a reply, an analysis, an invoice, a configuration, or part of a product. Glue is less visible. It exists because two parts of the company cannot connect on their own.

This is real work. But I increasingly think of it as a tax on the way we designed the company.

What glue looks like

Glue does not come in one form. I have started noticing several forms that repeat across very different parts of a company.

Handoff. Someone moves information from one place to another. A customer tells sales something, and sales passes it to product.

Status. Someone checks whether what was supposed to happen has actually happened. Is development done yet? Has the customer sent the data?

Translation. The information exists, but not in a form the next part of the company can use. Someone interprets it, structures it, or translates it into the language or format needed somewhere else.

Context. Someone knows something that is not in the system. They know why we made a certain decision three months ago, or that we promised this particular customer an exception.

Routing. Someone knows where an issue should go next. They do not solve it. They simply know who should get it.

Reconciliation. Two places show slightly different versions of reality, and a human is needed to determine what is actually true.

In practice, these forms often overlap. Status checking quickly turns into sequencing: one part of the company has to finish first, then someone has to tell another part so the next step can begin.

Each of these actions can be small. The problem is that a company can be made up of thousands of such connections that never appear on an org chart. Nobody hires a Head of Remembering What We Agreed or a VP of Asking Everyone If They’re Done. And yet someone does this work every day.

How to find glue

There are a few sentences I am starting to treat as a simple detector.

“Ask Kate, she knows.”

“Let me know when you’re done.”

“Copy that into the CRM as well.”

“Hold off on this until I’m back.”

An even more interesting test is:

What stops working if a specific person disappears for two weeks?

Not because they are the only person capable of doing difficult work, but because they are the only person who knows what is happening, what is missing, and what should happen next. That is probably where we have found glue.

Glue flows upward

In a small company, there is one person who is naturally connected to more things than anyone else. The founder. They know the customers, the product, the history, and the priorities. Often, they are the only person who can see several parts of the company at once. That is why all the seams the organization never properly designed tend to flow toward them.

You can build a small company, replace a large share of execution with AI, and still create a terrible job for yourself. The founder launches one agent, passes its output to another, adds context for a third, checks the result, decides what should happen next, and remembers the state of the whole thing.

There are fewer people. There is less human execution. But the glue has not disappeared. It has been concentrated in one person.

When I wrote the first piece in this series, “I Don’t Want to Be a CEO Again,” I was mainly thinking about the classic founder role drowning in operations. I see it a little more precisely now. Maybe a large part of what I do not want to do again is become the central glue in my own company.

Sometimes we create our own glue

Not every seam comes from an imperfect system. A founder can create one too. The company is capable of taking the next step, but:

“Show me before you send it.”

“I want to approve every discount.”

“Everything should go through me.”

Then the human becomes glue not because the system cannot continue without them. The system simply has not been allowed to continue. And this is where I increasingly separate two things: control and participation.

I can control a system without participating in every operation. I can define boundaries, limits, and situations that require escalation, then intervene when an exception appears. I do not have to be part of every transition to remain in control of the whole.

Recognizing glue is one thing. Removing it is another.

I now know where it hides and why it so easily ends up on the founder.

In the next piece, I will move from diagnosis to design.

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

For most of my life I have been drawn to automation. Not because I wanted to remove people, but because I kept watching people do work that no person should have to do. Retyping numbers from one screen into another. Chasing a status across three tools. Copying information from an email into a spreadsheet, from the spreadsheet into a system, from that system into the next one. Being the human bridge between places nobody had bothered to connect.

For sixteen years I built a B2B SaaS company for accountants and their clients, SaldeoSMART. We automated part of their work: reading documents, moving data, classifying, routing, tracking statuses. We took the dull, repeatable, transport-shaped work off people’s desks and handed it to software.

That was automating work inside other people’s companies. Now I am asking something different.

For sixteen years I did not watch a company from the outside. I ran it from the inside: product, sales, customer support, finance, implementations, decisions, exceptions, people, and systems. Back then, automation mostly took single processes off human hands. Today the question moves up a level. What if this time we do not automate a slice of the work, but design the company itself, from day one, around a different division of labor?

To answer that, you have to take a company apart. Not as theory from a management book, but as a practical arrangement of work in which humans show up in many places, and not always in the same role.

So what is a company actually made of?

Fifty years of taking work off human hands

It helps to look at where software has already been. Not as a history of technology, but as a history of the work it quietly took off people.

First, computers took over counting and remembering. Before that, whole rooms of people did arithmetic by hand, kept the books, retyped data, and guarded the records. A large part of that work simply vanished, or moved into systems.

Then networks took over moving information. Data no longer needed a person to carry it from place to place. That was glue, at the scale of the whole economy.

Then process automation started taking over rule-following. Systems could run entire chains of “if this happens, do that.” That was the executor, but only its predictable half, the part you could write down in advance.

All of these stages shared one wall. They handled well what was structured: numbers, database fields, forms, rigid rules. The moment real mess showed up, a plain email, a contract in a PDF, an intent hidden between the lines, incomplete data, a customer’s emotion, the systems usually stopped and called for a human. That is why, after decades of computerization, companies were still full of people sitting in the middle of processes. Not only because people were cheaper or easier to find, but because only a person could read something unstructured and understand what it meant.

We did a piece of this ourselves, before anyone was talking about AI. The software read invoices and pulled the data out, taking on work someone used to retype by hand. It worked, but only on things with a fairly predictable shape.

Now the wall is starting to crack for real. Software is beginning to read the mess. It takes an angry message and recognizes it as a complaint, not a plain question. It reads a contract and surfaces the risks. It gets twenty documents in different formats and builds a coherent picture out of them.

Interpretation was the last big thing systems could not take off human hands. And that layer is now starting to change.

So what is a company?

Not just a product. Not just a team. Not just an org chart.

A company is a system that finds a problem, makes a promise, delivers value, collects money, handles exceptions, learns, and survives.

That definition is deliberately broader than a list of tasks. It has room for the things you cannot easily package into a procedure: trust, timing, reputation, responsibility, hard decisions, exceptions, and the reason the whole thing should keep existing. I do not want a definition of a company that quietly deletes those parts just to make automation look easy.

But if that still sounds abstract, let us bring it down to earth. Every company, whatever it sells, has to solve a similar set of problems.

The map below starts once a company has at least a rough answer to two questions: what problem it solves, and for whom. Finding and validating those answers is an earlier loop, built on the same four modes of work, and it deserves a map of its own. First there is the part that faces the customer.

The value loop: how a company turns a customer problem into value and money

• Problem — spotting the pain, naming it, shaping it into an offer. Someone has to hear the pain and put it into words.

• Customer — who buys, qualifying, segmenting. Someone screens, judges fit, turns away the wrong ones.

• Promise — positioning, message, what exactly we deliver. Someone makes it, often a little differently to each buyer.

• Marketing — content, campaigns, presence, leads. Someone creates it, publishes it, keeps it alive.

• Sales — conversations, negotiation, closing. Someone talks, meets, persuades, and closes.

• Input — collecting what the customer has to give us. Someone chases it and fixes what arrives in the wrong shape.

• Product — the mechanism, tool, or process that creates the value. Someone fills the gap where the product ends.

• Delivery — getting that value to a specific customer: setup, configuration, execution, handing over the result. Someone launches, configures, adapts to the case.

• Onboarding — getting the customer to a first success. Someone walks them through it by hand.

• Support — help when the customer gets stuck. Someone replies, puts out fires, explains it again.

• Money — pricing, invoices, payments, reminders, reconciliation. Someone bills, reminds, checks who paid.

Notice how the second half of each line keeps beginning the same way.

Someone. Someone. Someone.

The back office: what a company does just to keep existing

• Finance — budget, cashflow, forecasts, cost control. Someone runs the numbers and watches the runway.

• Accounting — records, filings, tax compliance. Someone — the accountant — puts their name on it where responsibility begins.

• Legal — contracts, risk, disputes, terms. Someone — the lawyer — puts their name on it where responsibility begins.

• HR — hiring, onboarding, pay, people. Someone recruits, manages people, handles the paperwork.

• Security — data, access, continuity, incidents. Someone watches and reacts.

• Data — collecting, measuring, market and competitor research. Someone gathers, tidies, and interprets.

• Memory — what worked, what didn’t, the org’s knowledge. Someone carries it in their head, usually the founder or the longest-tenured people.

Same pattern. Someone.

Above all of it: strategy

Strategy — direction, what we bet on, what we refuse to do, how we price, and how we react to the market. Here the founder decides, and does not hand it off.

That break matters. Worth holding onto.

Four kinds of “someone”

Go back to that word: “someone.” The map is full of it. But those someones are not doing the same work. When you cut a company’s work into smaller pieces, four different human roles start to show through.

Glue moves information around, chases statuses, holds together systems that do not talk to each other. It creates nothing. It transports. It is sometimes necessary, but only because something upstream was never connected.

The executor does repeatable tasks by a familiar pattern. Real work, sometimes even hard, but the output is fairly predictable. This is where the latest technological shift hits hardest, because more and more work is softly repeatable: a little different every time, but the same shape.

Of course, not all execution is digital. Software will not clean a hotel room, assemble a structure on a construction site, or rack a server in a server room. In this piece I stay with the part of a company where the work is informational, coordination-based, or a matter of judgment. The physical world has its own logic. I will come back to it separately.

Judgment begins where there is no pattern. Do we enter this market? Is this customer worth an exception? Did a competitor change the rules of the game, or just make noise? You recognize it because two smart people, given the same facts, can decide differently, and both can be right.

The expert is needed where someone has to put their name on the outcome: legal, tax, financial, technical. Software can already prepare the analysis, the draft, the checklist. But it has no license, no name, and no consequences when it gets it wrong.

The first two roles are cost. The last two are meaning. In practice it is messier, but as a first cut the split holds. A traditional company usually does not make that cut. It calls everyone “staff” and scales by adding people to everything at once.

Cut one aspect open

The names of departments, roles, and company buzzwords are containers. “Support,” “sales,” “invoicing,” “complaints,” “order handling,” “keeping an eye on the competition,” each of these sounds like one job. In practice it almost always blends several different kinds of work. That is why the question “who should handle this?” usually comes too early. First you have to ask: what exactly needs doing here?

Take a concrete example: support. It looks like one thing. Cut it open.

“Where do I change my password?”, for the twelfth time today. That is the executor. The same answer, by the pattern, no new decision required.

A bug report that stalled for three days because nobody pushed it forward. That is glue. Someone is not solving the problem, just making sure it does not get lost.

An angry customer of five years. Technically in the wrong, but it is a weak month for retention and maybe it is worth an exception. That is judgment. There is no simple pattern, and two reasonable people might decide differently.

“Can I process regulated data in your tool, and do you take responsibility for it?” That is the expert. Someone has to answer in a way the company actually stands behind.

One aspect, four roles inside it. In most companies all of this lands on a single team. In a small company, often on a single person, who spends the whole day jumping between answering for the hundredth time, chasing statuses, hard calls, and questions of liability, and then files all of it in one drawer labeled “support,” as if it were one job. It is not. Part of that support is cost and can move to a system. What is left is the rare hard call and the few places where someone has to take responsibility. Support does not have to disappear. It can shrink to its meaning.

The same mechanism shows up in a phrase that is not even a job title: “keeping an eye on the competition.” The quarterly market research, who launched what and how they priced it, is execution, work a system now reads thirty times faster than a person. The daily background monitoring, a feature on Tuesday, a price cut on Thursday, is glue. And the decision about what to do when a competitor halves its price is judgment, and that one stays with a human. One word, three different kinds of work, three different places in the company.

Other buzzwords come apart the same way: order handling, complaints, invoicing, marketing, sales, recruiting, security. From the outside they sound like one thing. Inside, they almost always hide different kinds of work.

There is one more seam worth noticing. A system that does the repeatable work well will still, sooner or later, hit a case it does not recognize. The trick is not to make it guess. It is to build it so that it knows what it does not know, and calls a human at exactly that point. Where to put that handoff is most of the real design, and a subject for another day.

A word on the name

Zero Human Company sounds cold, so let me be clear about what it is not. It does not mean a company without humans. It means a company where humans stop being the default operating layer. That is: they stop being the default glue and executor, the ones who move data and grind through repeatable work because there is no one else. Systems take that part over. People stay where they are the point: direction, judgment, quality, responsibility, and the exceptions. I chose a sharp name on purpose. A softer one, like “AI-first company,” would have been safer, but it would have let me dodge the real question: where does a human genuinely have to stay, and where were humans in the company only because systems could not yet read and understand?

My first piece in this project was called “I Don’t Want to Be a CEO Again.” Taking a company apart this way, I understand better what I meant. I never minded the work of running something. I minded being the glue and the executor across twenty aspects at once. Being the person who moves the data, chases the status, answers for the hundredth time, patches the loose processes, and becomes the manual connector in every part of the company. In a small company the founder is often all four roles at once. Glue, executor, judgment, and expert-at-everything, even when they should not be. That is why founders drown.

I don’t want to be the glue again. I want to stay at judgment.

The point

This is not really a piece about automating everything. It starts earlier: stop treating every hidden task as “someone’s job.”

A company is not one thing. It is a stack of aspects. And inside each one sits work that can be glue, execution, judgment, or responsibility. For years we paid people to be all four at once, rarely asking which part actually needs a human.

If I want to build a company differently from the very start, that is the first thing I have to see clearly. Which parts are value, which are glue, which are judgment, and which are responsibility.

That is the question behind Zero Human Company. Not: how do I add AI to an existing company. But: what kind of company do I choose, and how do I design it from day one, so that a human does not have to be the glue and the executor in every corner of it.

The honest answer starts before the company exists. With deciding what not to build.

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

For the last 16 years, I have been building a SaaS company.

A real one.

With customers, product development, implementation, support, sales, finance, lawyers, partners, investors, roadmaps, hiring, leaders, meetings, priorities, conflicts, communication, structure and all the invisible work that appears when a company starts to grow.

I am grateful for that journey.

But I also know one thing very clearly:

I don’t want to be a CEO again.

Not in the classical sense.

Not as the person who keeps building a larger human organization around every operational problem.

Not as someone who responds to every increase in complexity with another role, another team, another leader and another layer of coordination.

For years, this was the natural way to build a company.

A problem appears. You hire a person.

The problem grows. You create a role.

The role gets overloaded. You build a team.

The team grows. You need a leader.

The structure grows. You need meetings, reporting, processes and synchronization.

This is the classic path of a company.

And very often, it works.

But it also gets heavy.

Over time, the founder spends less energy designing the system and more energy servicing the organization.

Less creating.

More coordinating.

Less asking what should exist.

More maintaining what already exists.

I am not saying this is wrong.

I am saying I don’t want to build a company this way again.

Not because people are the problem.

But because, over the years, I have seen how much human energy companies spend on work that was never truly human work.

People often become the glue between systems.

They move information.

They coordinate.

They wait for decisions.

They handle exceptions.

They translate between systems.

They copy data.

They send status updates.

They follow up and remind.

They manually connect processes that should have been designed differently in the first place.

For a long time, this was normal because we did not have a better alternative.

Software helped, but it still often needed a human as the interface.

The human was the default operating layer of the company.

If something had to happen, someone had to do it.

If something had to be checked or connected, someone had to do it.

If a process had an exception, someone had to resolve it.

AI changes the question.

Not completely.

Not magically.

Not without risk.

But enough to ask a different question than before.

Not only:

How can AI help people work faster?

But rather:

What would a company look like if it were designed from the beginning around AI, automation and systems, instead of humans as the default execution layer?

This is the question Zero Human Company starts with.

I don’t know if a true “zero human” company is possible.

Maybe the honest answer will be a low-human company, not a zero-human company.

Some functions will probably move almost entirely into systems, while others will always require human judgment, trust, taste, responsibility or boundary decisions.

That is exactly what I want to test.

Publicly.

Not as a finished method.

Not as a promise.

Not as another newsletter about AI.

I want to document the process of finding the answer before it becomes polished and named after the fact.

What works.

What breaks.

Where AI creates real leverage.

Where it only looks like it has agency.

Where a workflow is enough, and where a human still needs to be involved.

And where a human should never have been used as the operational solution in the first place.

I don’t want to be a CEO again.

I want to find out what replaces that role when a company is designed around AI-powered systems, not around human operational work.

And I want to document that path in its raw form, before it becomes complete, structured and polished.

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