One permission gates the entire agent surface in a delegated session: the ability to edit an agent's Instructions and Soul. This page covers what that gate unlocks, the two fields that actually shape behavior, and the difference between editing an agent and running one. For the full agent reference, see Agents.
The client-facing toggle is called **Allow reseller to modify agent Prompts & Instructions**. In the API and in this doc it is the scope `prompts_and_instructions`. It is not a per-tab setting, it is the gate for the whole Agents surface, and this page is scoped narrowly to what changes for you inside that gate, not a general tour of Agent Studio.
Without it, Agent Studio never opens at all. Not read-only, not grayed out: the route is locked before it renders.
Of the eight scopes a client can grant, this is the widest reaching by nav surface alone: Onboarding, Impact and Agents require it and nothing else, and Home requires it or `chat_history`. The other seven toggles each gate a single, narrower area. That is worth keeping in mind when you talk a client through what to enable first: this one toggle is doing most of the work. See Client permissions for how all eight sit together.
Everything you change on an agent's behavior comes down to two free-text Markdown fields on the Identity tab. They do different jobs, and conflating them is the most common way a first agent goes wrong.
A worked example for a plausible client agent, an inbox triage agent for a design studio. Notice the Instructions block states what the agent always does, what it never does, and how it should sound when reporting back, while the Soul block only carries voice.
The product's own readiness heuristics look for Instructions running past roughly 200 characters and Soul past roughly 40. Treat that as a rough floor, not a target: it flags an agent that is clearly underspecified, it does not certify one that is well written. A few sentences that name real behaviors will always beat a longer paragraph that only restates the agent's job title.
The mistake worth avoiding: don't fold personality into Instructions, and don't fold behavior into Soul. "Be warm and friendly" is a vibe, it belongs in Soul. "Always flag anything mentioning a contract" is a rule, it belongs in Instructions. A model asked to infer a rule from a voice description will apply it inconsistently, because it was never actually given a rule.
Both fields are plain Markdown, both are editable the moment you have `prompts_and_instructions`, and both save independently of the agent's Tools, Channels, or Schedule configuration. Changing one never resets the other.
Reaching any tab at all needs `prompts_and_instructions`. Three tabs then carry a second lock on top of that one, tied to their own scope. Everything else opens as soon as you have the agent scope.
Skills, Memory and Schedule are the exceptions, not the rule. A session with `prompts_and_instructions` but missing one of those three lands on that tab and finds it locked, while every other tab in the studio behaves normally. See Skills and Oversight for what those companion scopes gate elsewhere.
Reaching a tab is not the same as the agent being able to act on what you set there. Editing the Tools tab, for example, always works once you have the agent scope, but whether the agent can actually call the tools you enable depends on a completely separate set of scopes, covered next.
Four modes are selectable on an agent's Tools tab. A reseller with `prompts_and_instructions` can change the mode for a client's agent like any other Identity or Tools setting.
For a client who is new to automation, start cautious. **Ask each time** or **Guarded auto** give them a few weeks of watching the agent's tool calls before anything runs unsupervised, and moving to **Full auto** later is a one-click change, not a redo. Going the other direction, tightening a mode after something went wrong, reads worse to a client than starting careful and loosening on purpose. The full approval and blockers story, including what counts as a risky tool call, lives at Oversight.
For the inbox triage agent from the example above, **Guarded auto** is often the right starting point. Reading and sorting a shared inbox is low risk, so there is little reason to make a client approve every message, while anything the agent should escalate is already written into its Instructions as a flag for human review, not an action it takes on its own.
`prompts_and_instructions` controls whether **you** can edit an agent's configuration. It does not control what tools the agent itself can call when it runs. Those are separate, and each is gated by its own scope on the same delegated session.
You can have full edit access to an agent's Instructions and still watch it fail every tool call, because the client never granted the scope those tools need. That is expected behavior, not a bug to work around.
Not every scope on the client's Manage Reseller panel affects this. `chat_history`, `billing_summary` and `audit_logs` govern what a reseller can see, not what an agent is able to do, so they never appear in the table below.
When one of these is missing, the agent reports it plainly rather than failing silently, in code format: `Permission denied: reseller delegated session does not include {scope} access.` If a client asks why an agent you configured "isn't doing anything," check this table before you check your prompt. See Apps, tools and integrations and Skills for what granting each of these actually looks like from the client's side.
A concrete version of the mismatch: a client grants `prompts_and_instructions` but leaves `skills` off. You can open Agent Studio, rewrite the agent's Instructions to say "use the invoicing skill for any vendor bill," save it, and everything looks correct. The first time the agent runs, it cannot find that skill and reports the permission denial above. The fix is on the client's Manage Reseller panel, not in your prompt, no amount of rewording changes what scopes the session was minted with.
Chatting with an agent is gated on its own scope, `chat_history`, which is independent from editing that agent's configuration. Three combinations are possible, and only one of them lets you actually send a message.
Opening an agent's chat page needs `chat_history` at the route level. Sending anything into it needs both scopes together, `chat_history` for the history and `prompts_and_instructions` for the send action.
In practice, read-only looks exactly like the client's own chat view, scrollback, timestamps, tool call traces, with one difference: the composer at the bottom is disabled. There is no separate "view only" banner on that field, so if a client has only granted `chat_history`, expect the input to simply refuse focus rather than announce why.
If a client wants you to be able to reply, not just read, the fix is on their side, not yours: both toggles live on the same Manage Reseller panel. See Client permissions for exactly where.
Agents belong to the client organization that owns the workspace, never to you. Every delegated session is scoped to exactly one client, and Actionist actively clears cached workspace data on both ends of that session.
Entering a session and leaving one both clear the cached workspace data. The practical consequence: always leave a session with the **Exit** button, or the Escape key, rather than navigating away in the app or closing the window. That is what actually triggers the clear. Wandering off mid-session risks stale data from one client's workspace bleeding into your view of the next.
A delegated session runs for one hour. Scopes are resolved from the client's live grants at the moment you start it, so if a client flips a toggle while you are inside, your session keeps its original scopes until you use **Refresh permissions** in the banner to re-mint them, you do not need to exit and re-enter for that. Session expiry itself is silent: if the hour runs out mid-task, or the session is otherwise no longer valid, the app tears it down and drops you back at your own Reseller dashboard with no error dialog. If you find yourself unexpectedly back on your dashboard, that is very likely why.
A clear Instructions block, a sensible approval mode, and a scope list the client actually understands.
One scope gates the whole Agents surface. Tool access is gated separately, scope by scope.
Credentials and API keys stay off-limits regardless of what a client enables here.