I’m Trying to Build Myself Out of the Loop

I keep discovering that a surprising amount of my work is not really the work I thought I was doing. It is keeping the work moving.

A project begins with an idea and gradually turns into people, software, decisions, messages, documents, customers, approvals, and all the small problems that appear between them. Somewhere along the way, I usually become part of the infrastructure. Someone needs context that I happen to have. Two systems disagree. A decision does not quite belong to anyone. Something stops, and I know enough about how the pieces fit together to get it moving again.

For years, I mostly interpreted this as competence. The more you understand a business, a product, or a project, the more useful you become when something falls between the formal parts of it. You know which rule matters, which assumption has changed, who should be involved, and what was actually meant when someone made a decision three weeks ago.

There is nothing wrong with being useful in this way. Some of the most valuable people I have worked with are exceptionally good at seeing across boundaries.

But usefulness can quietly turn into dependency.

The project works because you are there. The company remembers because you remember. The process continues because you notice that it has stopped. What looks like a well functioning system from the outside may depend on one or two people continuously reconstructing how it is supposed to work.

Lately I have started to see that as a design problem.

In my previous essay, I wrote about the capacity AI creates. Making a task faster does not automatically give the saved time back to the person. The surrounding system decides where that capacity goes.

I am now interested in another kind of capacity. Not the minutes saved inside a task, but the attention released when the task, decision, or process no longer has to travel through you in the first place.

When people become the integration layer

In software, middleware is the layer that helps different systems communicate. In many organizations, people end up doing something remarkably similar.

They move information from one system to another. They preserve context that was never written down. They translate what one team knows into something another team can act on. They remember the reason behind a decision after the meeting has disappeared from everyone's calendar. When the official workflow encounters reality and reality does not fit, they handle the exception.

This work is easy to underestimate because it often looks like ordinary communication. Send the message. Ask the question. Check the number. Remind the person. Update the document. Explain why the customer is unhappy. Tell finance that the delivery plan changed. Tell delivery what sales actually promised.

Taken individually, none of these things looks particularly important. Together, they can form the real operating system of a company.

The more experienced someone becomes, the more likely they are to carry this invisible layer. They know where the systems are incomplete and how to compensate for them. They know which information cannot be trusted without checking another source. They know when the process says one thing but the situation requires another.

Eventually, the organization starts borrowing that capability from them every day.

I have been thinking about this problem at the company level in The Executable Company. One of the ideas there is that a company can look integrated when its best people are actually doing the integration. The systems exist, the processes exist, and the dashboards exist, but the current state of the company still has to be reconstructed inside somebody's head before an important decision can be made.

The personal version of that problem is much easier for me to observe.

I can see myself doing it.

AI can make the bottleneck faster

I am using AI across an increasingly large part of my work. Research, writing, software development, publishing, product work, operations, and the coordination between them.

The interesting change is not that AI suddenly does all of these things perfectly. It does not. The change is that software can now operate inside more ambiguity than it could before. It can read material that was written for people rather than databases, work across several sources, follow a sequence of actions, use tools, preserve context, and make reasonable progress without every step being specified in advance.

That expands the amount of work software can carry.

It also creates a fairly obvious trap once you experience it.

You automate the research, then check the research. You automate the draft, then inspect the draft. You automate the software change, then verify the change. You automate publication, then require yourself to approve every publication. You connect several systems, then create a morning ritual for checking whether all the connections are still alive.

The work becomes faster, but it keeps coming back to the same place.

This is different from the simple productivity problem I wrote about before. The issue is no longer only that newly created capacity gets filled with more work. The structure itself may still depend on the same person. AI produces more, prepares more, and moves more quickly, while the human at the center becomes responsible for reconciling everything it produces.

You can automate a surprising amount of work and still make yourself more operationally important.

I have caught myself doing exactly that. I build something to reduce my involvement and then gradually give myself a new job supervising the thing I built.

There are good reasons to begin this way. New systems need observation. Consequential decisions deserve care. When I do not yet understand how something fails, I would rather see too much than hand over authority casually.

But temporary supervision can easily become permanent architecture. If every ordinary case eventually returns to me, I have not removed the dependency. I have increased the speed at which the dependency receives work.

I have made myself a more efficient bottleneck.

A different question about automation

This has changed the way I look at a process.

The obvious question is still useful: how can AI help me do this?

I increasingly follow it with another one: why does this need to come through me?

Sometimes the answer is obvious. The decision requires judgment. The relationship matters. The consequences are significant. I am making a promise and should remain responsible for it. The work carries my taste, my point of view, or my name.

But other answers are much less convincing. I am involved because I happen to know where the information lives. Because two pieces of software do not share enough context. Because nobody defined what should happen in the ordinary case. Because an exception was never converted into a rule after the fifth time it occurred. Because the organization has learned to ask a person instead of improving the system.

Those are very different reasons for having a human in the process.

For a long time, traditional software left a large territory between what could be formally programmed and what people could handle through common sense and experience. Human beings occupied that territory. We dealt with incomplete information, vague language, changing situations, inconsistent records, and exceptions that were too expensive to encode one by one.

AI does not eliminate that territory, but it changes its boundary.

Software can now interpret more of the information that used to require a person simply because it was messy. It can work with documents, conversations, previous decisions, instructions written in ordinary language, and information distributed across different systems. Given appropriate boundaries, it can often determine the normal next step without asking a person to repeat what the organization already knows.

That does not mean the goal should be to remove the human.

It means we can become much more demanding about why the human is there.

I do not want maximum automation

This is where the idea becomes more personal for me.

Trying to build myself out of the loop sounds, at first, like trying to make myself unnecessary. In some parts of my work, that is exactly what I want.

I do not want to be necessary because I remember a password, know which document is current, carry a decision from one conversation to another, or notice that a routine process has stopped. I do not want ordinary work to wait for me because the system has no representation of what should normally happen next.

But there are other places where removing myself would make the work worse.

There are decisions I want to make because deciding is part of what I contribute. There are people I want to speak to directly. There are products where direction and taste matter. There are commitments where a machine may perform most of the execution while responsibility should remain unmistakably human.

This is also why I am skeptical of treating "human in the loop" as a goal by itself. I have explored the organizational version of that problem more deeply in Responsibility Before Automation. A person placed at the end of an automated process is not necessarily exercising meaningful judgment. They may simply be the last place where the system deposits uncertainty and, eventually, blame.

At the same time, removing that person without understanding what they were actually carrying can be equally careless.

What matters is the reason for their presence.

In my own work, the distinction I am trying to make is between intentional presence and accidental dependence.

If I am there because the work needs my judgment, responsibility, taste, trust, or attention, that is one thing. If I am there because nobody designed what happens without me, that is another.

What should the system be able to carry?

This way of thinking changes what I try to build.

When something repeatedly comes back to me, I am trying to resist the instinct to simply handle it and move on. The return itself contains information.

Maybe the system does not have enough context. Maybe the information exists but cannot travel to where it is needed. Maybe a decision boundary is unclear. Maybe the normal next step has never been made explicit. Maybe the automation can act but should not be deciding. Or perhaps the case genuinely deserves a person.

These are not all AI problems, and that is important.

Sometimes the answer is better software. Sometimes it is a clearer process. Sometimes it is writing something down that has lived in people's heads for years. Sometimes two systems simply need to share state properly. Sometimes an organizational disagreement is being disguised as an information problem and no amount of automation will resolve it.

AI expands the set of things a system can carry, but it does not relieve us of designing the system.

This is also where the personal experiment begins to connect to the larger idea behind The Executable Company. I am interested in what happens when more of an organization's operating logic can live in the organization itself: not only in procedures and software, but in the ability to preserve context, understand the current state, act within clear boundaries, recognize when the ordinary path no longer applies, and bring a person in for a reason.

That is a much more ambitious idea than automating tasks, and I do not think we know exactly what it looks like yet.

I am starting with myself because the failures are easy to see.

Building for meaningful presence

I do not know whether becoming better at this will eventually make me work less.

It might. It might also allow me to build more things, because each one requires less continuous attention. I may use some of the released capacity to go deeper into work I care about and some of it for things that have nothing to do with work at all.

The first essay left that question deliberately open. Capacity does not decide its own destination.

What feels clearer to me now is that capacity can be created in more than one way. We can make individual tasks faster, but we can also redesign work so that fewer ordinary things require a person to carry them from one step to the next. The second kind may be harder to measure because there is no dramatic before and after for a single task. What disappears is the accumulation of interruptions, approvals, reminders, reconstructions, and small acts of coordination that quietly consume attention throughout the day.

That is the experiment I am running now.

When work repeatedly needs me, I want to understand the reason before I accept the dependency. Some of those reasons will survive the test because they are genuinely human reasons. Others will turn out to be remnants of systems that were never able to carry enough of their own context or logic.

I am not trying to build a world in which I am absent from everything I create. I am trying to build one in which being present is more often a choice, and where the things I leave behind do not stop simply because I looked away.