Say the outcome, read the diff: a day with Sudo

Leon

• 2026-08-26

If you administer a Studio deployment, you have a backlog of small changes. A field on the ticket schema. An endpoint that returns open tickets grouped by product. A scheduled task that nobody owns any more. None of them is hard. Each one costs you an hour of finding the right file, the right scope and the right moment.

An assistant with write access should take that backlog off you. The fear is that it takes more than that. An agent's actions are the responsibility of whoever gave it the access, so the useful question is what access you give, and what you get to see before anything happens.

Sudo is the admin assistant in Curiosity Studio, and we wrote a guide for the people who use it every day: Working with Sudo. Two companion papers cover the case for a CIO and the sandbox in technical depth. This one is practical. Its argument fits in two sentences: ask for the outcome, approve the diff.

Questions cost nothing

Start by asking. Which endpoints are public? What can the triage agent call? Which node types have no index? What broke after the last deploy? Each of these is a read. Sudo greps code/endpoints/, opens one file in code/agents/, or reads /proc/exceptions and /proc/audit.

Despite the name, the assistant never takes elevated privileges, and its graph queries run under your own permissions. A session that only read leaves nothing behind.

The sandbox has nine mounts, and only two take writes: your configuration in /workspace, as the definitions export writes it, and scratch files in /tmp, which vanish with the session. Everything else is read-only.

Say the outcome, not the surface

When you want a change, describe what users should be able to do. "Users should be able to filter tickets by product" beats "add a facet". The answer might be a facet, an index setting or a schema field, and Sudo can look before it decides.

The paper's main example takes that sentence one step further: filter tickets by product, and show the product on the ticket card. That one request touches four surfaces: a field on the Ticket schema, a migration task to backfill it, index settings, and a renderer for the card. Sudo edits all four, compiles the schema and the code that uses it together, and stages one commit. If anything fails to build, the whole set is refused. Nothing has run, and the backfill starts only after you approve.

Reviewing is reading the diff

The pending changes panel opens the staged commit. You can read it file by file, side by side, or as one page with a comment box under each file. You can edit the right-hand side yourself, or comment and ask for changes. Then you press one of three buttons:

Button	What it does	Sudo's edits
Approve	Applies every file, as one commit	Applied, attributed to you
Discard	Throws the commit away	Kept, for another try
Reset	Returns Sudo's shell to live	Thrown away

If Sudo staged a newer commit while an older card was still open, the old card refuses to apply, because approving it would apply something nobody read. Discard says nothing in the chat, so silence is never taken as approval.

Figure 1. One request, four edits, one commit. A failed build refuses the whole set, and each button decides what happens to the commit and to Sudo's edits. The failing file is an example.

The habit the paper keeps returning to is one commit per idea. Work that only makes sense together, like a schema and the migration that fills it, goes in one commit. Everything else is split, so each review is one self-contained change.

What the sandbox cannot do

Simon Willison's lethal trifecta is a clear framing for agent risk: private data, exposure to untrusted content, and a way to communicate externally. Combine all three and an attacker can instruct the agent to send your data out. Remove any one leg and that attack fails.

Sudo cannot remove the first two. It reads your configuration, which is private, and it reads files you attach, which may contain text written by someone else. So the sandbox removes the third leg. There is no network, no host filesystem and no process spawning. curl, ssh and git are absent from the sandbox, which is stronger than refusing them.

The paper names the limit of this. Code you approve can call out once it runs. That is the code's authority, not Sudo's, and it is the main reason to read every line of a diff that adds an endpoint or a connector.

Every applied commit is one entry in the configuration history, attributed to whoever approved it. Code surfaces keep their own history, so a change made through the assistant rolls back like one made by hand.

Teach it once, with a skill

Sudo's voice and boundaries are a skill in your configuration, sudo-persona. It says to verify intent, target and impact first, to go ahead with small reversible work, to ask before anything destructive, security sensitive, externally visible or ambiguous, and never to report success it has not confirmed. Read it before your first real change.

Your own conventions belong in a skill too. The paper's rule of thumb: if you say it at the start of every session, it belongs in a skill.

The paper closes with five habits. I would start with two. Ask for the diff early: "show me what that would change" catches a misunderstanding while it is still one file. And hand over the file instead of describing it. Attach the spreadsheet, the PDF or the zip, and a CSV becomes columns and null counts before it becomes a schema.

Read the guide

Working with Sudo is 22 pages, with the mounts, the review screen, the run commands and a glossary. Read it before you hand Sudo its first real change, then open the admin dock and start with something small.

Read the whitepaper (PDF)