Sudo

Sudo is the admin-facing AI assistant of Curiosity Workspace: an in-product chat that reads, designs, changes and operates every configurable surface of your workspace. He works the way a developer works, by editing files and running commands, and nothing he writes reaches the workspace until you approve the diff.

using Transpose.Core;
using Tesserae;
using static Transpose.Core.dom;
using static Tesserae.UI;

namespace Tesserae.Tests
{
    internal static class App
    {
        private static void Main()
        {
            var sudo = PixelAvatar(42, PixelAvatarDesign.Sudo, PixelAvatarAnimation.AutoIdle)
               .PixelSize(8);

            var card = HStack().AlignItems(ItemAlign.Center).Children(
                sudo.PR(20),
                VStack().Children(
                    TextBlock("Sudo").Large().SemiBold(),
                    TextBlock("Admin assistant · Curiosity Workspace").Secondary().PT(2),
                    TextBlock("Despite the name, he never assumes elevated privileges. He asks first.")
                       .Small().Secondary().PT(8)));

            document.body.style.overflow = "hidden";
            MountCenteredToBody(card.Padding(16.px()));
        }
    }
}

He is not the assistant your end users talk to. That one searches the workspace and reads what it is handed. Sudo changes the workspace itself: endpoints, AI tools, agents, skills, prompt templates, scheduled tasks, indexes, schema, NLP, search settings, chat policies. The two wear different coats on purpose, so which one is in front of you is legible at a glance.

How he works, in one paragraph

Your workspace configuration already round-trips through the definitions export as plain files: that is what the export zip, the WebDAV mount and the git tracking are. So the configuration is handed to Sudo as a filesystem, and he changes it the way anyone changes files. He reads them with cat and grep, edits them with sed or a heredoc, compiles them with build, and hands the result to you with commit. There is one tool, one sandbox, and one way into the workspace.

Where he appears

The pane is aware of what you are looking at. The admin interface hands him a UI context block: the surface in the foreground tab is the active context, what "this endpoint" refers to when you say it, and everything open in adjacent tabs is background context used to disambiguate.

Two session modes

The empty chat asks how the session should work before anything else:

The Allow changes toggle (the pen icon in the chat toolbar) is the same switch and can be flipped mid-conversation. Turning it off does not take the shell away: taking the shell away would leave Sudo unable to read the workspace either. The toggle lands on the session and commit is what refuses, so an admin who forgot to turn it on does not lose the draft. Flip it on and the same commit works.

How he behaves

His voice and boundaries are a skill in your workspace (sudo-persona), so they are visible and editable rather than hard-wired:

• Verify before acting. Intent, target resource, and likely impact, checked before anything is drafted.
• Proceed on the small and reversible. Clearly requested, low-risk, reversible work goes ahead.
• Ask first on the rest. Destructive, security-sensitive, externally visible, broad-impact or materially ambiguous requests stop and ask.
• Smallest change that works. He edits the lines that need editing rather than retyping a file.
• No invented state, no unconfirmed success. He does not claim a change worked without a result to show for it, and does not imply permissions he does not have.
• Report what happened. What changed, where, whether it worked, what is left.

Competent first, charming second: he leads with the answer or the current status, and the cat shows up afterwards, if at all.

What he will not do

• Write without approval. There is no path from a draft to your workspace that does not pass through a diff you approved, and the approval is bound to the exact commit you were shown.
• Read your data. graph and query are read-only, run under the chatting admin's permissions and skip node types that are never returned to clients. Configuration, runtime state and files you staged are the whole of what he sees.
• Reach the network. The sandbox has no route out: no curl, no wget, no HTTP from a command.
• Manage users, teams or access-group membership. He can read access groups and reference one from a definition; membership is yours, under Manage / Access.
• Read a secret value. He can declare a secret and write code that reads it. He can never see one.
• Install packages, take backups, restart the workspace, or touch licensing.
• Replace the admin pages. Everything he does is something you can do by hand, and every change he applies lands in the same tracked history as a manual one.

Read next