Admin Assistant

The Admin Assistant is an in-product chat in the Curiosity Workspace admin area that reads, designs, changes, and operates the configurable surfaces of your workspace — endpoints, AI tools, agents, prompt templates, scheduled tasks, indexes, NLP spotters, schema, search settings, access groups, and more.

It augments the manual admin pages; it does not replace them. Every change it makes goes through an explicit approval step, every applied change is one git commit, and the assistant reads schemas and configuration code only — never the contents of your data (search results, file bodies, messages).

What it does

Describe a change in plain language — "add an endpoint that returns open tickets per product" or "the support agent should also search the wiki" — and the assistant:

reads the relevant configuration to understand the current state;
drafts the change as code in the same export format the workspace-definitions zip uses;
compiles and round-trip-parses that code before showing it to you;
presents a per-change diff for you to review, edit, and approve;
applies the approved change as a single tracked git commit;
runs a verification check against the saved configuration.

If anything is ambiguous, it asks before proceeding instead of guessing.

The workflow

The assistant is not one model doing everything. It is a small set of role-specific agents coordinated behind the chat, each with a narrow set of tools:

flowchart TD U[Your request in plain language] --> P[Planner: reads config, drafts a plan] P --> C[Coder: writes code, compiles, proposes a change] C --> R[Reviewer: audits for security & policy regressions] R --> A{You review the diff} A -->|Approve| O[Operator: applies the change as one git commit] A -->|Edit / Deny| C O --> V[Verifier: tests the saved configuration] V --> U

Agent	Role	Can change config?
Planner	Reads the workspace and produces a step-by-step plan. Asks you when something is unclear.	No
Knowledge	Answers "how does X work in this workspace?" for the Planner.	No
Coder	Drafts the change as code, compiles it, and stages a proposal.	Stages only
Reviewer	Audits each proposal for security and policy regressions. Has no write tools, so it cannot "fix and continue" past a blocking finding.	No
Operator	The only agent allowed to apply an approved change.	Yes (after approval)
Verifier	Runs end-to-end checks against the change after it is saved. Has no propose tools, so it cannot mask a failure by editing the code under test.	No

Splitting the work this way keeps each agent's tool surface small and makes every step an auditable action in the workspace's run history.

Using the assistant

The assistant lives in the Workspace Admin Assistant chat in the admin area. Only system administrators can open it.

Start a session

Open the Workspace Admin Assistant chat. A new session starts read-only.

Choose read-only or allow changes

The empty chat asks whether this session may make changes. Leave it read-only to ask questions and explore configuration; toggle Allow changes (the pen icon) to let the assistant draft and apply proposals.

Describe what you want

Type your request in plain language. The Planner reads the relevant configuration and lays out a plan, asking follow-up questions if needed.

Review proposals

Each proposed change appears as a diff in the Proposals panel — the same before/after code the workspace-definitions export would produce. Read it, edit the "after" side if you want, then approve or deny.

Approve and verify

Approving applies the change as one git commit signed with your admin identity. The Verifier then runs a check against the saved configuration and reports back.

Read-only by default

A session can read configuration without the Allow changes toggle. Nothing is ever written until you turn the toggle on and approve a specific proposal.

What you can configure through it

The assistant covers the same surfaces as the manual admin pages:

Code surfaces — custom endpoints, AI tools, agents, prompt templates, scheduled tasks, data connectors, entity post-processing, custom indexes.
Schema — node types, edge types, renderers, and styles.
NLP — node spotters, pattern spotters, pipelines, and entity-to-node linking.
Search — facets, synonyms, forced replacements, and search settings.
Settings — front-end UI settings, embedding/model preferences, AI providers, and access groups.

See Read-only skills for everything it can inspect, and Change skills for everything it can propose and apply.

How it keeps changes safe

No silent writes. Every change flows through a proposal and an explicit approval click. The Operator is the only path that writes, and it refuses to run without a fresh approval token tied to the exact diff you saw.
Compile before approve. A proposal is never marked ready until its code compiles and round-trips through the same parser the workspace uses to load it.
One commit per approval. Each applied change is a single commit in the configuration-tracking git history, signed with your admin identity and tagged with the session.
Secret hygiene. A deny-list scans every change for API keys, credentials, and tokens before it can be committed.
Access-mode guard. Any change that would widen who can reach an endpoint or tool is flagged as blocking and cannot be batch-approved.
Closed tool list. The assistant only calls workspace built-ins — never external services or arbitrary HTTP.

Next steps

Read-only skills — what the assistant can inspect.
Change skills — what it can propose, apply, and verify.
Examples — concrete tasks you can hand to it.

Referenced by

Examples