Customizing the AI¶

The AI tab in Workspace Settings is the single place to shape how Doable's agent behaves for everyone in your workspace. This page walks through every lever available to a workspace admin or owner.

Provider keys: BYOK vs Provider Bridge¶

Doable supports two ways to give the AI a credential:

BYOK (bring your own key): you paste an OpenAI, Anthropic, Google, Mistral, or custom OpenAI-compatible API key into the workspace. The cost lands directly on your provider account.
Provider Bridge: the platform admin has pre-provisioned a shared key (or a metered platform credential) and your workspace consumes that key under per-plan limits.

The choice is per-provider, not global. You can run Anthropic via the Provider Bridge while keeping a BYOK OpenAI key for image generation.

For full details (including provider validation, model discovery, the per-provider health badge, and the 3-step provider wizard), see AI → Provider Bridge.

Personal vs workspace AI scope¶

Doable separates personal and workspace AI credentials. As a workspace admin you only manage workspace-scoped entries; you cannot see personal credentials belonging to other members, even your own teammates.

Personal credential: owned by exactly one user, billed and audited to that user. Lives under Account → AI.
Workspace credential: shared across all members in the workspace, billed and audited to the workspace.

In the model picker inside the editor, each option is labeled with its scope (for example Anthropic (workspace) or OpenAI (personal)), so it is always clear which budget a conversation will draw from. See user-guide/workspaces.md#personal-vs-workspace-ai-scope for the full guarantee text and the privacy contract.

Allowed models¶

Inside Workspace Settings → AI → Allowed models you can restrict the list of models any member of the workspace is allowed to pick.

Use cases:

Block expensive frontier models on a free workspace.
Restrict to a single approved provider for compliance.
Force everyone to a model you have validated against your codebase.

When a model is removed from the allowed list, any saved conversation defaults that reference it fall back to the workspace default model on the next turn. Existing transcripts are not rewritten.

The allowed-models list does not restrict personal credentials: a member can still bring their own Anthropic key and use it. To enforce "no personal credentials," that decision happens at the platform-admin level (workspace admins cannot lock out personal scope today). This may change; verify against the current build before promising it.

Workspace default model¶

Sets the model used when a member opens a project without an explicit override. The resolution order at run time is:

Platform enforcement (if any): set by the platform admin
User override: picked in the editor model picker
Workspace default: this setting
Auto-select: Doable picks a sensible model

The badge next to each user's effective model in the platform admin Users view is color-coded along this same chain (red enforced, emerald user, blue workspace, grey auto). You will see the same chain at work in the chat header.

Custom skills¶

A skill is a reusable AI capability (a named bundle of instructions, sample inputs, allowed tools, and optional MCP server bindings) that any member can attach to a chat turn from the skill picker.

Workspace-scoped skills live under Workspace Settings → Skills. You can:

Add: create a new skill from a markdown body plus a JSON tool/MCP allowlist.
Edit: adjust the prompt or allowlist; changes are picked up on the next AI turn.
Disable: keep the skill in the catalog but hide it from the picker.
Delete: remove it entirely.

Workspace skills are visible to everyone in the workspace and selectable in every project. They override no platform-level skill defaults; they sit alongside them.

For the larger picture of how skills, tools, and modes interact, see AI → Tools & MCP.

Custom MCP servers¶

Doable is MCP Apps compatible (see the Model Context Protocol Apps overview). Under Workspace Settings → MCP servers (Connectors) you can register additional MCP servers for the workspace.

For each server:

Name and optional description.
Transport: HTTP, stdio, or WebSocket.
Endpoint: URL for HTTP/WS, command line for stdio.
Authentication: bearer token, OAuth, or none.
Allowed tools: optional subset; leave empty to allow everything the server advertises.

Once registered, the server's tools become callable from any chat turn in the workspace. UI resources returned by MCP tools render inline in the chat as McpUiResourceCard panels.

Knowledge bases¶

Under Workspace Settings → Knowledge bases you maintain markdown context the AI consults on every turn:

Workspace knowledge file: a single markdown document. Paste in your brand voice, naming conventions, technical glossary, escalation paths, on-call rotation, anything you want the AI to know across every project.
Uploaded documents: TBD in current builds. The underlying upload-and-index pipeline is in flight; verify what your build actually surfaces before promising team-wide RAG-style knowledge.

Per-project knowledge lives in the editor sidebar (Knowledge tab) and is documented in the user-facing editor guide. Workspace knowledge applies to every project in the workspace and is the right home for content that should never have to be re-pasted per project.

System-prompt customization¶

TBD. The platform supports per-workspace system-prompt prepends in the engine, but a dedicated UI for editing the system prompt at the workspace level is not surfaced in current builds. For now, the practical lever is the workspace knowledge file above; its contents are folded into every prompt. Watch the release notes for a dedicated system-prompt editor.

Sandbox allow/deny at the workspace level¶

Workspace admins can constrain what AI runs are allowed to touch:

Tool default action: allow or deny for any AI tool not explicitly listed.
Network default action: allow or deny for outbound network destinations.
Per-rule overrides: glob-pattern rules that override the default in either direction.

These rules are layered on top of platform-wide defaults set by the platform admin in /admin. Your workspace rules can be stricter than the platform default but cannot loosen a platform-wide deny.

For the model and full grammar, see:

security/sandboxing.md: overall sandboxing approach (bwrap, sandbox-exec, Psroot)
security/egress-firewall.md: network egress rules

The per-rule editor surface in the workspace UI is in active development (migration 073). If your build shows only the defaults toggle, the underlying API is still available; your platform admin can set fine-grained rules on your behalf in the interim.

Workspace audit visibility¶

Everything an admin or member does (every AI call, every tool invocation, every member role change, every AI allocation change, every sandbox rule edit, every MFA reset, every audit read) is recorded in the workspace audit log.

What you see as a workspace admin:

Conversations: full list of AI chat sessions in your workspace, with project, user, mode, message count, last user/assistant excerpts.
Session detail: click any row to see the full transcript, with PII redaction applied to log lines.
Admin actions: every administrative write that touched your workspace.

What you do not see:

Other workspaces' conversations.
Personal credentials owned by other users (only metadata: provider name, scope, internal owner id; never the key material itself).
The full platform audit log at /admin/audit/actions; that is platform-admin only.

What the platform admin sees that you do not:

Conversations across every workspace.
Aggregate platform-level statistics.

Both directions are auditable. When a platform admin opens a session that belongs to your workspace, that read shows up in your workspace audit log too, so you always know which platform admin looked at what, and when.

The workspace audit log replaces the "trust us" model with cryptographic evidence: every event has an actor, timestamp, client IP, user agent, and JSON details payload.