Sudo

Sudo is the admin-facing AI assistant of Curiosity Workspace — Curiosity's pixelated cat, and the persona the Admin Assistant loop wears. He lives in a pane on the right of the admin interface: a system administrator opens him from the floating toggle, describes what they want in plain language, and he reads the workspace, drafts the change, and applies it once it has been approved.

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, access groups. The two have different faces on purpose, so which one is in front of you is legible at a glance.

Where he appears

Surface	What he is doing there
The admin chat pane	The conversation itself. It is collapsed by default and opens from a floating toggle carrying his avatar; both only appear inside the admin interface, for system administrators.
The composer, the transcript, the empty state	His avatar, idling and fidgeting between turns.
The built-in editors	He perches on the modal of a built-in AI tool, agent, skill or prompt template, which is how you can tell a built-in from something your workspace authored.

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. Each entry carries the canonical identifier his tools expect, so a request phrased as "make this one read-only" resolves to the right endpoint rather than a guess.

How he behaves

His voice and boundaries are a skill in your workspace (sudo-persona), which means 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 actions go 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 what needs editing rather than retyping a surface.
• 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.

Two session modes

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

The mode is per session — start a new chat session to switch. The Allow changes toggle (the pen icon) is the same switch, and it gates every propose.* and apply.* tool for that session.

What he can do

Answer questions about the workspace

Everything under Read-only skills is available in either mode: list and read endpoints, AI tools, agents, prompt templates, scheduled tasks, data connectors, indexes, NLP spotters and pipelines, search configuration, embedding preferences, UI settings and access groups; read the graph schema and node statistics; pull the API documentation for a type or for a code-execution scope.

So "which endpoints are reachable without authentication?", "what does this agent's tool set look like?" and "what is available inside an AI tool's scope?" are all answerable without enabling changes.

Diagnose what is happening now

• Metrics — call counts, latency and error rates for endpoints and AI tools over the last hour and the last 24 hours.
• Exceptions — recently recorded exceptions, which is usually how you find out what a change broke.
• History — the configuration-tracking git log: who changed what, when. He can also read the before/after of a single past version of a code surface, so "what did this endpoint look like before Tuesday?" is a question he can answer rather than reconstruct.

Build and change configuration

With changes allowed, he drafts against every surface listed in Change skills — code surfaces (endpoints, AI tools, agents, skills, prompt templates, scheduled tasks, data connectors, migrations, entity post-processing), schema (node types, edge types, renderers, styles), indexes, NLP (spotters, pipelines, entity linking), search (settings, facets, synonyms, replacements), and settings (UI, embeddings, AI providers, access groups and grants).

Each draft is compiled, round-trip-parsed, secret-scanned and policy-checked before it is offered to you, and each one arrives as a before/after diff you can edit in place before approving.

Run things, and undo them

• Test a saved surface — run an endpoint, an AI tool, an agent, a scheduled task, a search, or a spotter over sample text, and report what came back. This is how a change is verified after it is applied.
• Materialize an index and report the result.
• Roll back the most recent applied change when verification fails.
• Propose a shell script — a one-off C# script for you to read and run from the chat, for the work that is genuinely one-off and does not belong in a saved surface.

Read what you hand him

Files uploaded to the private Stage area — where files sit while they await review, before they are promoted into the workspace — are readable by him: extracted text for ordinary documents, and for CSV-style files the column metadata — headers, sample values, distribution, and whether a column is numeric, date-time or boolean. That is what makes "here is a CSV, build me a connector and a schema for it" a request he can actually start from.

He does not read your workspace's data — search results, file contents, messages. Configuration and staged files are the whole of what he sees.

Follow your workspace's own recipes

Sudo does not work from memory. Before planning, writing code, or proposing anything, he reads the skill for the surface involved — short markdown recipes stored in your workspace, listed under built-in skills:

Skill	Covers
add-code-endpoint / edit-code-endpoint	Creating and safely modifying a code endpoint.
create-ai-tool	[Tool] / [Parameter], ToolScope, return conventions, secrets.
create-agent	Tool set, output schema, system prompt.
add-node-schema-field	Adding or renaming a schema field, plus the migration that backfills it.
add-custom-code-index	Custom code and search indexes.
add-scheduled-task	Code-driven tasks, cron sanity, dry run.
add-pattern-spotter	Regex spotters wired into a pipeline.
graph-query-language	Q() / Query(), traversal, filtering, the typed N. / E. helpers.
embeddings-and-vectors, build-similarity-engine	Which encoders exist, and fusing signals into a ranked list.
workspace-shell, inspect-staged-files, code-helpers	The Shell, the Stage area, and his read-edit-propose loop.
sudo-persona, agentic-workflow-overview, propose-change-protocol, introspect-tools-overview	Who he is, and how the loop and its proposals work.

These skills are yours. They are ordinary workspace nodes: read them, edit them, or add your own, and the recipe he follows changes with them. That is the supported way to teach him a house convention — an authorization attribute every endpoint must carry, a naming scheme, a field your schema always sets — and it applies to every future session rather than to the one conversation you said it in. He treats a skill as a checklist and surfaces a conflict rather than silently overriding it.

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. The approval is bound to the exact content you saw.
• Batch-approve a widened access mode. Anything that broadens who can reach an endpoint or a tool is a blocking concern and needs explicit per-change approval.
• Read your data. Configuration and staged files only.
• Reach outside the workspace. He calls workspace built-ins — no external services, no arbitrary HTTP, no cross-workspace work.
• Replace the admin pages. Everything he does is something you can do by hand, and every change he applies lands in the same git-tracked history as a manual one.

Cost and accountability

Every tool call he makes is metered into the workspace's own metrics under an Admin Agent bucket, separately from ordinary chat tools, and each session tracks its own call count, error count and total duration. Every applied change is one commit in the configuration-tracking history, signed with your admin identity and tagged with the session it came from, so a change made through Sudo lands in the same history as a manual one and carries the session that produced it.

Next steps

• How the loop works — Planner → Coder → Reviewer → approval → Operator → Verifier.
• Read-only skills — everything he can inspect.
• Change skills — everything he can propose, apply and verify.
• Examples — tasks to hand him.