Why does access beat the prompt?
When the documents are right, access decides. What an agent may read and what it may change makes the difference. Set that up cleanly, and it fetches its own context, so the prompt can stay simple. The work moves from wording to granting rights. In the "Hey Jarvis" Deep Dive in July 2026 I describe a sequence. Prompt engineering looks for the best wording for one question. Context engineering hands the agent every file and structure it might need, so it can make the best decision on its own and genuinely knows everything. A weaker prompt often works fine after that. Access engineering goes a step further and sets where the agent may read and where it may change something. One word comes up often that evening: the harness. That is the environment an agent lives in, the program that hands it files, a terminal and tools. Codex and Claude Code are two of them. The harness is the frame around the model, and access is granted inside that frame.
Three steps in one order
In the "Hey Jarvis" Deep Dive in July 2026 I describe a sequence. Prompt engineering looks for the best wording for one question. Context engineering hands the agent every file and structure it might need, so it can make the best decision on its own and genuinely knows everything. A weaker prompt often works fine after that. Access engineering goes a step further and sets where the agent may read and where it may change something.
One word comes up often that evening: the harness. That is the environment an agent lives in, the program that hands it files, a terminal and tools. Codex and Claude Code are two of them. The harness is the frame around the model, and access is granted inside that frame.
Once you have the right documents, access becomes enormously important. What do you allow? Where do you allow reading?
What access covers day to day
Access sounds technical, but it is a list of places. For each place I decide two things: whether the agent may look inside, and whether it may change anything there. Here is how that looks for me.
One example of this comes from a recording of December 2025, months before the Deep Dive. For a Stripe checkout session I set what an agent may at least read, and I keep that explicitly separate from whether it may also change something. Read means it can look at it. Write means it can enter something, for example when a customer cancels. That exact separation is what I mean today when I talk about access engineering.
That gradation already sits inside perfectly ordinary tools. In the app permissions of ChatGPT there is a read action, where a service may read everything and change nothing, and a low-risk action, where it may also change some things. Walk through that menu once on purpose and you have done access engineering in miniature.
- Documents: project folders, offers, minutes, handbooks. Reading almost everywhere, writing only in the working folder of the current project.
- Email: the inbox for reading, so the agent knows the history of a matter. Writing happens in the drafts folder, sending happens through me.
- Calendar: appointments, places and lead times for reading. Entries only in my own calendar, invitations to other people go out after approval.
- Earlier decisions: the second brain with notes, decisions and the reasons behind them. Reading always, adding allowed, deleting never.
- Systems with consequences: deployment, payments, deletion, sending. Here one permission is granted per single operation.
What changes once access is right
Once the boundaries are clear, the agent fetches the relevant context on its own. The prompt can then stay short: use the access I gave you, get the context you need for the best result, and ask me back if something is unclear. The result stays good, because the selection comes from the access I set beforehand.
For that to hold, the agent needs something to read. A second brain that both humans and machines can read therefore comes before the rights. Grant rights over unsorted folders and you get an agent that searches quickly in the wrong place.
A month later, in the "Agenten-Mindset" Deep Dive, I made the same point again: the newer models need context and access, which makes it more about context engineering and the right access than about wording. A talk for the Young AI Leaders in Linz puts the same definition in one sentence: agents are language models with access, tools, context and process.
What good boundaries look like
Four boundaries matter day to day. They are written this way in the recap of the evening, because they repeat in every engagement.
From the Deep Dive
KI DeepDive "Hey Jarvis", 6 July 2026. Recap and transcript in the archive.
- Read access to the relevant project, knowledge and archive folders.
- Write access only where changes are wanted and reviewable.
- No secrets, customer data or private paths in public artefacts.
- Sending, deployment, payment and deletion only with explicit approval.
Where access leads
Access is one rung on a longer ladder. In the same Deep Dive I described six rungs, from paid chat up to rung five, your own agent computer with remote access, voice, terminal, browser, git and permanent automations. The image behind it is called Jarvis. The whole ladder, with a short self check, is in the note on the Jarvis ladder.
Two notes hang directly off this one. Whether good AI work comes from wording or from structure is in prompting or building systems. What happens when an agent has read access to the inbox and an email carries a hidden instruction is in draft before send. For the wider frame, see how AI really changes your work.
Sources and links
This note keeps growing
2026-09-03: Deepened with a recording of my own from December 2025: the same read/write separation at a Stripe checkout session, months before the Deep Dive.
2026-09-03: Deepened: harness and context engineering explained, a list of what access actually covers, the permissions menu as an everyday example, and the bridge to the Jarvis ladder.
2026-09-02: Planted from the "Hey Jarvis" Deep Dive, 6 July 2026.