Someone knocks. "Got a minute?" Forty minutes later you have answered three questions, none of which were the one you were about to write the answer to before they walked in. Multiply by every team member, every day, and the founder is not running the company. The company is interrupting the founder.
The standard advice on this is real and partially right. Office hours. Async first. Write the SOP so the team stops asking. Build a wiki. Use Loom. Block your calendar. The advice is correct that interruption load is the most expensive tax on founder time. It stops one substrate short of the answer.
Here is what the documentation school of process consulting cannot explain. Founders who have written full SOP libraries still get interrupted. Founders who have run the most rigorous async cultures still get the question that was not in the doc, that could not have been in the doc, that needs context the founder has and nobody else does. The interruption that sticks is not the one the SOP would have prevented. It is the one the SOP cannot reach.
Why? Because the question is rarely "what is the rule." The question is usually "given the rule, what do I do here." Given the SOP for proposal pricing, what is the right number for this prospect, who has this history, who came in on this lead, who already pushed back on this thing, who is being introduced by this referral. That is not a rule. That is runtime context.
Runtime context lives in three places in most companies. The founder's head. Recent emails. Slack threads from last Tuesday. None of the three are a place the team member can query at the speed of the question. So the team member knocks.
You cannot solve this with better documentation. You cannot solve this with calendar discipline. You solve it by moving the runtime context into a substrate the team can query without interrupting you.
For twenty years that substrate did not exist. Wikis went stale. CRMs were the last thing anyone updated. The Slack history was searchable, but the search returned a chronological list of fragments, not the answer. The runtime context stayed in the founder's head because there was no other place to put it that could be read fast enough. The interruption was the only fast path.
Now there is an agent layer. An agent in a seat holds the SOP, the recent corrections, the deal history, the active commitments, the in-flight context. The team member who would have walked into your office walks up to the agent instead. The agent answers from the same substrate the founder would have answered from. Most of the time that is enough. The team member did not need the founder. They needed the runtime context that used to only live with the founder.
What does the founder see now? Only the cases the agent could not resolve. The novel ones. The ones that genuinely require a judgment call the agent has no precedent for. The questions the founder gets are harder, not fewer. That is the right shape. Easier questions got caught one routing layer earlier. The founder's day stops being a queue of routine clarifications and starts being a queue of decisions that actually need a founder.
This is not the same outcome as a wiki, and the difference is worth being precise about. A wiki holds documents a human has to remember to read. An agent holds runtime context a human can ask directly. The wiki's failure mode is "they did not open it." The agent's failure mode is "they asked, the agent did not know, it routed to the founder." Same teammate, same question, different substrate. Only the second substrate has an exhaust path that does not end in the founder's office.
There is a second-order effect that matters more than the time saved. Every interruption that reaches the founder is a signal of a missing SOP. When you are the substrate, the signal is buried in the noise of every other question. When the agent is the first substrate, the signal is sharp. The questions that escape the agent and reach you are precisely the gaps in the SOP. You answer the founder-only ones and you patch the gap. The next session, the agent has the answer. The next interruption of that shape never reaches you.
We built OTP on the premise that the runtime context belongs in a place the agent can read every session. Every tile on a team chart, human or agent, carries SOPs. The agent under the founder seat compiles its SOP and the founder's SOP into its system prompt. When the team member asks the agent a question, the answer is not a search of a stale wiki. It is the live SOP plus the current state of the work. When the founder edits the SOP at noon, the agent that boots at 12:01 has the new version. When the team member asks at 12:02, they get the new answer.
If your interruption problem feels permanent, it is not because your team has not internalized the SOP. It is because the SOP has not internalized the work. The substrate that does both is an agent the team can ask. The questions that escape that layer are the ones that should reach you. The rest were never yours to answer.