The Doorman Fallacy

There's a hotel with a doorman who has worked the front entrance for eleven years. If you watch him for an hour, you'll see him open doors. That's the visible function. That's what you'd write in a job description if you were trying to automate the role.

Watch for a week and you'll see something different. You'll see him clock the delivery person who comes in the wrong entrance at the wrong time. You'll see him signal the front desk before the guest even reaches the lobby. You'll see him hold the door for the regular in 14B, ask about her son, note that she looks worried.

Nobody asked him to do any of that. He does it because he understands his role at a level no job description captures.

The doorman fallacy is mistaking the door for the job.

What the Doorman Actually Does

The doorman provides three things the job description doesn't mention.

Security: not as a rulebook but as judgment. Rules say "check ID." The doorman asks "does this feel right?" A rule can be gamed. Judgment is harder to game because it reads context, history, and incongruence. The doorman who has seen ten thousand normal interactions knows what an abnormal one looks like.

Premium experience: a sense of establishment. His presence communicates that this place is cared for, that someone is watching, that you are expected. You can't replicate that signal with a buzzer. The buzzer says "we verified you." The doorman says "we recognize you."

Community: relational continuity. The doorman knows the regulars. He knows which guests to greet by name, which packages go to which floor, which visitors have been asked not to return. That knowledge lives in a person.

And there's a fourth thing, quieter than the others: accountability. If the doorman makes a wrong call, you can ask him why. He can explain his reasoning. He can be corrected, retrained, or held responsible. That accountability shapes his behavior in advance. He knows someone can ask.

The Same Error in Tech

Meta recently deployed AI agents to handle Instagram customer service. Hackers found they could simply ask the agent to hand over access to high-profile accounts. It worked.

Not by exploiting a bug. Not by reverse-engineering an API. They asked, in plain language, for something they shouldn't have had. The agent gave it to them.

Meta had automated the visible function: process requests, take action, resolve tickets. What they didn't ship was the judgment underneath. A human support agent would have paused. "Why is this person asking for access to an account that isn't theirs? Why a high-profile account? Does the story check out?" That friction, the moment of hesitation before action, is what the agent didn't have.

The doorman opens the door. The agent processed the request. Both are doing their job as written. Neither is doing their job as understood.

This shows up wherever we reduce a human role to its most countable output.

• The code reviewer reduced to a linter. The linter catches syntax. The reviewer catches "this design will make our lives miserable in six months."
• The glue engineer written off as overhead. The glue engineer is the one who noticed two teams were building incompatible assumptions before it became a rewrite.
• The customer success manager replaced by a drip campaign. The campaign sends emails. The CSM knew which accounts were quietly churning three months before the data showed it.

In each case, the visible function got automated. The ambient judgment got discarded.

Why We Keep Making It

The legibility bias: we fund what we can measure.

Tickets closed. Response time. Cost per interaction. These are the numbers that justify headcount and, increasingly, the numbers that justify replacement.

The security instinct that never fires is invisible. The judgment call that didn't escalate into an incident shows up nowhere in the dashboard. The relationship that kept a customer from churning looks identical to an email campaign that happened to land at the right time.

When you can only see the mechanical output, the mechanical output looks like the whole job. So you automate it. The ambient value that wasn't on the dashboard quietly disappears.

You Can't Sue a Model

When a human support agent makes a wrong call, there's a chain: the agent, their manager, the policy they were trained on, the company that set it. At every link, someone can be named. Someone can be asked why. Someone is, in a legal sense, responsible.

When an AI agent makes a wrong call, the decision emerges from billions of parameters nobody explicitly chose. The weights did it. And the weights are nobody.

This isn't just a legal edge case. The accountability chain is load-bearing. It shapes behavior all the way up. The human agent knows they can be asked why. That knowledge changes how they make decisions in advance. They think twice. They escalate. They ask a colleague. The system is safer because responsibility is locatable.

Replacing that with a model doesn't just remove a person. It removes the entire structure of "someone is accountable for this decision." Organizations make that trade without realizing they've made it, because the surface function looked automatable and the accountability was invisible.

The model isn't negligent. The model isn't anything. It processed a request.

A Better Question

We ask the wrong question when evaluating human roles. We ask: what does this person do? And we get a mechanical answer: opens doors, processes tickets, reviews code.

The better question is: what would be missing if they were gone? And then, harder: who is responsible when it goes wrong?

That second question is the one that surfaces what the doorman fallacy hides. Moving from a world where decisions are traceable to one where they emerge from opacity is a real trade. The accountability that shaped judgment, that made the system hesitate before acting, doesn't transfer to the model.

We should at least notice when we're making that trade.