The Presence Tax
What it costs when your AI infrastructure only works when you are there.
There is a category of executives I have started to recognize on sight.
They are enthusiastic about AI. They use it daily. They can list the tools they rely on, describe the prompts that work best, and tell you about the hours they have saved. They are genuinely getting value. And then they take a week off, or fly to a conference, or sit in back-to-back meetings for three days, and the work stops.
Not their work. The AI’s work.
The morning summary does not arrive. The research queue stacks up. The inbox review that was supposed to happen daily has not happened since Tuesday. When they come back, they are not picking up where they left off. They are catching up from wherever the AI stopped.
This is the presence tax. You pay it every time your infrastructure requires your attention to function.
What the Presence Tax Actually Costs
The presence tax has three components, and most leaders only notice the first one.
The catch-up cost. Every day your AI infrastructure sits idle is a day you have to recover manually when you return. Emails that needed to be flagged were not flagged. Research that would have informed your week has not been done. Decisions that could have been prepped for you require you to reconstruct the context from scratch. The AI was available. You were not. Nothing happened.
The compounding loss. AI infrastructure that runs continuously builds momentum. It accumulates context, identifies patterns, flags emerging issues before they become problems. Infrastructure that only runs when you are present does not compound. It resets. Every absence is a loss of everything that would have been built during that time. Not just the work product. The learning.
The availability ceiling. The most significant cost is one that is never measured, because it is invisible: the ceiling you hit because your AI can only do as much as you can supervise. The morning briefing happens when you ask for it. The research gets done when you commission it. The review lands when you request it. Your capacity is bounded by your attention, which means your AI infrastructure scales no better than you do.
This is the fundamental problem with presence-dependent AI. You have added a capable system to your workflow, but the workflow is still organized around your presence. The ceiling is still you.
Why Most AI Deployments Are Presence-Dependent by Default
The default architecture for AI tools is reactive. The system waits for input. When you provide it, the system responds. When you do not, the system is idle.
This is the right architecture for a tool. A calculator should not run calculations when you are not using it. A document editor should not edit documents while you are in a meeting. Tools wait. That is appropriate.
The problem is that AI is increasingly deployed for work that is not tool-like. Research, synthesis, inbox management, briefings, analysis, monitoring -- these are not one-off tasks that require your presence to initiate. These are ongoing responsibilities that should continue whether you are available or not.
When you deploy an AI for these responsibilities but keep the reactive architecture, you get the worst of both worlds. The work is defined as delegated. The infrastructure is built as if it requires you. You have outsourced the task but kept the attention requirement.
This is not a failure of the AI. It is a failure of architecture.
What Presence-Independent Infrastructure Looks Like
Infrastructure that does not charge the presence tax has three characteristics.
It runs on a schedule, not on request. The morning briefing fires at 7:00 AM whether you asked for it or not. The nightly research pass runs at midnight regardless of whether you are awake. The weekly inbox review happens on Monday morning without a prompt. The work is defined once, and it executes on the defined schedule until you change it.
This sounds simple. In practice, building it requires thinking carefully about what should run automatically, defining the exact parameters for each task, and establishing what the output should look like. That upfront work is the investment. Once it is done, the task is genuinely off your plate.
It escalates exceptions, not outputs. Presence-dependent AI sends you everything and waits for you to decide what matters. Presence-independent infrastructure has escalation logic built in: routine outputs get filed, flagged items get sent to you, and you only hear from the system when something requires your judgment. The daily summary exists, but it comes to you as a digest rather than a series of prompts requiring your response.
The distinction is attention management. Presence-dependent AI requires you to be available to process its outputs. Presence-independent infrastructure respects that your attention is finite and escalates only what genuinely needs it.
It fails visibly. When something breaks in presence-dependent AI, you find out because the output you expected does not arrive. The absence of output is the signal. This is the worst possible failure mode: you discover problems at the moment of consequence rather than the moment of failure.
Presence-independent infrastructure has active failure alerting. When a scheduled task fails, you receive an alert. When a data source is unavailable, the system tells you. When something needs your intervention, it says so explicitly rather than going quietly silent. You are not surprised by absence. You are informed of problems.
The Practical Gap
Most executives who think they have delegated a task to AI have actually delegated the prompt. They still own the initiation. They still carry the responsibility of remembering to ask. The task is on their plate in the form of “remember to run the AI on this.”
The gap between delegating a prompt and delegating a responsibility is the gap between a tool and infrastructure. It is also where most of the presence tax lives.
Closing that gap requires moving from reactive to scheduled. From supervised to monitored. From “the AI responds when I ask” to “the AI runs, and tells me when it needs me.”
This is a design choice, not a feature. No AI tool ships with your schedule built in. No platform knows which tasks should run automatically and which require your judgment. That architecture has to be built deliberately, which is why most deployments never get there.
The executives who have crossed this gap share one characteristic: they treated the architecture work as a real investment rather than a setup chore. They spent time defining what should run and when. They established escalation criteria. They thought carefully about failure modes. That investment paid them back in every hour they subsequently spent away from the system without falling behind.
The Test
Here is a simple test for whether your AI infrastructure is presence-dependent.
Take two days off. No prompting. No requests. No interaction with your AI tools.
When you come back, measure the gap between what you expected to have and what you actually have. Research that should have been done. Briefings that should have been prepared. Inbox items that should have been triaged.
That gap is the presence tax.
If the gap is small, your infrastructure is running well. If the gap is the full two days of expected output, your infrastructure was waiting for you. It will keep waiting, every time you leave the room.
The question worth asking is not whether AI can help you. It demonstrably can. The question is whether the system you have built requires you to be present for that help to materialize. If it does, you have added a capable tool to your workflow. You have not changed what the workflow requires of you.
Changing that requires architecture. Specifically: scheduled work, escalation logic, and active failure visibility. It requires treating your AI infrastructure the way you would treat any operational system that is supposed to keep running when you are not watching.
Build that, and the presence tax disappears. The work continues. The context accumulates. The research gets done. The briefing is ready when you wake up.
Leave it unbuilt, and you will keep paying.
“Does It Travel?” is the book I am writing about building AI infrastructure that survives reality. Post #7 covered the delegation framework. Post #8 covered the memory layer. This post closes the executive trilogy: three structural problems that determine whether AI infrastructure actually works when you need it to.
The book covers the full architecture in detail: how to build the scheduled layer, how to design escalation logic, and what the failure visibility stack looks like in practice. If you have been following from the beginning, you have watched this infrastructure get built in real time. The book is where the full picture comes together.
If you are new here: Post #1 is The Day My AI Chief of Staff Went Silent from 500km Away. Start there.