The new skill is permission design
As AI agents move from answering questions to using company systems and taking approved actions, the useful skill is no longer just writing a better prompt. It is deciding what the agent is allowed to touch at each stage.
OpenAI’s recent Presence announcement describes this pattern clearly: agents can answer, resolve issues, use systems, take approved actions, and escalate to people. The permission map makes that pattern practical for a small team.
How to draw the map
Start with the desired outcome, then list every system the workflow touches. For each system, decide whether the agent may read, write a draft, suggest a change, or make the change. If nobody can explain why an action is needed, remove that permission.
Keep the map narrow. An agent helping with a billing dispute may read the approved policy and customer history, prepare a reply, and propose a credit. It should not independently change a balance, alter account access, or resolve an exception.
Copy this workflow brief
A small case study
A support team maps an AI billing assistant before launch. In week one, the assistant reads policy pages and creates draft replies. In week two, it adds a proposal lane for credits, but a manager must approve the amount and account. The team discovers that “update customer record” was too broad, so it splits that permission into “add internal note” and “change billing status.”
The result is not slower automation. It is faster review: people can see what the agent knows, what it prepared, and exactly where their decision is required.
The takeaway
Good agent design is a sequence of small permissions, not a single trust decision. Draw the map before connecting the tools, then revisit it whenever the workflow, data, or consequence changes.