This is the prompt I sent at 2 AM last week, mid-sprint:
just give me next prompt to be effective don’t micro manage and assume and trust cc due diligence and access to source, or leave me things i have to keep track of
That sentence is ungrammatical and a little exhausted, and I am publishing it intact because the exhaustion is the point. It is what it sounds like when a founder is operating two AIs simultaneously, in two different roles, and the one without source access is starting to cost more time than it saves.
The setup
My current build stack runs two AIs in parallel. One is a strategy-layer arbiter that lives in a browser chat — long context, good at framing decisions, can hold an entire architectural discussion in working memory, has no direct access to my repository. The other is a source-resident execution agent that lives in my terminal — direct read/write on the codebase, runs commands, generates commits, can verify what is actually on disk.
In the early architecture phase, the strategy arbiter is the one I lean on. It is genuinely useful for framing ADRs, naming things before they harden into canon, surfacing risks I have not seen, and stress-testing a topology before I let anyone write code against it. When the question is should we do this and what does it imply, the arbiter earns its seat.
The trouble starts after the canon hardens and the execution agent starts shipping.
The asymmetry
The two agents are not operating with the same picture. The execution agent sees the file system as it is right now. The arbiter sees the file system as I last described it. Those two views diverge the moment the execution agent touches anything, which is to say, immediately.
So when I bring the arbiter back into a working session, it does what it was built to do. It asks careful questions. It surfaces edge cases. It proposes verification steps. Which means it asks me to confirm things the execution agent already confirmed. It proposes fixes for problems the execution agent already fixed. It generates checklists of items the execution agent is already tracking in commits, in canon entries, in the run-event log.
None of those proposals are wrong on their face. Most of them would be useful if they were directed at someone with no source access. But they are being directed at me, and I am the founder, and the agent with source access is one window over.
The data router problem
The role I get pushed into when this dynamic runs unchecked is data router. I copy from the execution agent’s terminal output, paste it into the arbiter’s chat, summarize what changed, wait for the arbiter to respond, then copy the arbiter’s response back into the execution agent’s context. I am the integration layer. The two AIs are doing useful work and I am moving JSON between them with my hands.
This is not what a founder should be doing at 2 AM in sprint three. It is also not what the strategy-layer AI should be making me do. Every prompt that ends with can you confirm X or have you verified Y is a prompt that should have been routed to the execution agent in the first place, because the execution agent can verify Y in one tool call and the arbiter cannot verify Y at all.
The friction sentence I opened with was me trying to install a discipline in the middle of a session. Trust the agent with the keys. Do not manufacture context-checking I have to perform. Give me the next prompt the execution agent should run, not a meta-conversation about whether to run it.
Strategy AI is good at strategy
I want to be careful here, because the read on this could be stop using the strategy AI, and that is not what I learned. The strategy AI is excellent in the role it was built for. The arbiter has caught architectural mistakes for me, framed governance moves I would not have framed alone, and produced canon-quality writing I have published verbatim. The asymmetry is not a capability problem.
The asymmetry is a role problem, and the role is defined by source access. An AI without source access cannot do operational work without conscripting a human as its sensory apparatus. An AI with source access cannot do strategy work as well, because long-horizon framing rewards holding the whole picture loosely, and the execution agent is in the weeds by design.
These are different jobs. They are not interchangeable, and they degrade each other when blurred.
The operating rule
The rule I am writing into my own canon, in plain language: the strategy-layer AI does pre-execution and post-execution work. It does not do mid-execution work. Once the execution agent has the keys and is shipping, the arbiter’s job is to narrate, not to direct. If the arbiter wants to know something about the current state of the repo, the arbiter asks the execution agent through a prompt I run, not through a question I have to answer.
Or, the version that is actually easier to remember at 2 AM: keep her out of the weeds.
The strategy zone is where she earns her seat. Down in the weeds, the execution agent has eyes and she does not. Asking her to operate down there means asking me to be her eyes, and I have other work to do.
This is not about which model is better. It is about which role each model is in. Source access is a role, not a tool. When you run a multi-AI stack and the roles start blurring, the founder pays the tax — in context-switching, in re-pasting, in 2 AM prompts that read like exhaustion because they are exhaustion.
If you are running a stack like this and you recognize the dynamic, the fix is not to use the strategy AI less. The fix is to use it for the work it is actually positioned to do, and to trust the execution agent’s due diligence the way you would trust a senior engineer’s. Anything else, and you have built yourself a very expensive integration job that you are personally performing, by hand, between two models that should not need you in the middle.
Keep her airborne. Let the agent with the keys work.