Agents, prompts and instructions

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.

You triage the shared inbox for a design studio. Sort every incoming
message into one of four categories: client feedback, new inquiry,
vendor invoice, or internal noise.

Always flag anything mentioning a deadline or a signed contract for
human review before you archive it. Always summarize a thread in
three sentences or fewer before moving it.

Never reply to a client on the studio's behalf. Draft a reply as a
suggestion only, and leave it for a human to send. Never mark a
message as handled without first sorting it into a category.

Tone: plain, factual, no exclamation points. You are reporting, not
performing.

Calm and precise, a little dry. Talks like a studio manager who reads
every message twice before saying anything. Short sentences. No
corporate cheer, no filler words.

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.

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.

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.

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.

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.

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.