Operators

An operator is the human (or agent acting under the human's permissions) who operates the Whet workbench. Each workspace has one or more operators with roles defined by better-auth.

What does an operator do?

Action	Where
Create pipelines	UI / CLI / MCP
Pause / archive pipelines	UI
Review artifact inbox	UI / CLI / MCP
Trigger refinement loops	UI / MCP (refine_post prompt)
Publish with confirmation	UI / CLI / MCP
Connect/rotate platform credentials	UI (Settings → Connected accounts) or MCP (connect_account)
Connect LLM provider BYOK	REST API (/api/v1/whet/llm_credentials)
Rotate API key + signing secret	REST API (POST /api_keys/{id}/rotate_secret, 24h overlap)
Rotate webhook signing secret	REST API (POST /webhook_endpoints/{id}/rotate_secret, 24h overlap)

note

Today the Settings UI only exposes Connected accounts. Rotating API keys, rotating webhook secrets, and managing LLM BYOK is done via the API (with scope admin:write). A unified credentials UI is on the roadmap.

The scope system today is basic: the API key carries scopes with value admin:write for administrative actions (api_keys management). Fine-grained scopes (pipelines:write, artifacts:publish, etc.) are on the roadmap. To limit an agent's actions, control which token you hand it and keep the publishing one close to a human who confirms.

Refinement workflow

The operator doesn't have to accept the first draft. For each artifact in ready state, they can trigger one or more refinements that produce child variants. Available actions:

• shorter — trims while preserving intent.
• change_tone — moves from one tone to another (analytical ↔ punchy, neutral ↔ snarky).
• match_voice — adjusts to the style_reference the operator passes with the action (the persistent voice profile is on the roadmap; see Patterns and Riffs · Voice model).
• more_punchy — adds friction / edge.

Each refinement creates a child artifact that preserves parent_id, so the full genealogy stays navigable. You can have a variant tree of depth N.

Publishing

Whet never publishes in the background. Every publication (via UI, CLI, or MCP) requires an explicit intent from the operator or from an agent with delegated permissions. The flow is:

1. Operator (or agent) picks a ready artifact.
2. Confirms the final text (optional override).
3. Whet marks the artifact as published and, if the pipeline has auto_fanout, triggers delivery to connected surfaces.

This policy is by design, not a toggle. It exists to defend the legal position (operator = responsible for their publication) and to prevent destructive agent mistakes.

Agents acting as operators

Via MCP, an agent can exercise any permission the agent token grants. Today the scope is all-or-nothing at the workspace level (except admin:write for api_keys management, which is separated). If you care about limiting an agent to "read but not publish," the robust form is operational: do not hand it the publishing token.

Recommendation: for production agents, use tokens in test mode (pk_test_…) — live-only endpoints reject these tokens with test_key_required 403, so you reduce blast radius while developing. Fine-grained per-action separation (pipelines:read, artifacts:publish, etc.) is on the roadmap.

Roles inside the workspace

Role	Permissions
Owner	Everything. The only one who can invite members and rotate the master key.
Operator	Operate pipelines and refinements; cannot touch billing or connections.
Viewer	Read-only on pipelines and artifacts.

Roles are managed from Settings → Members (better-auth organization plugin).