Experts, tools, and Skills

Usable Chat can become more specialized through Experts, tools, and Skills. These concepts work together, but they are not interchangeable.

• An Expert packages assistant behavior and available capabilities.
• A tool performs a concrete action or retrieval operation.
• A Skill is a reusable instruction fragment that Chat can discover from workspace context and load when needed.

Understanding the boundary makes configurations easier to test and safer to maintain.

Experts

An Expert is a reusable assistant configuration. Depending on the current product surface, it can include:

• a name, description, and visual identity;
• a system prompt or prompt source;
• a preferred model or Inherit behavior;
• enabled built-in tools;
• routing hints or keywords;
• parent tools when used in an embed.

Use an Expert when a recurring role needs a stable prompt and capability set, such as product support, research, or document review.

Keep an Expert focused. A single Expert with every tool and every responsibility is harder to route, test, and govern.

Choose an Expert model

The Expert model picker can search the available model registry and show capability or pricing hints. Choose Inherit when the Expert should follow the model selected in the conversation, or choose a direct model when the role needs a consistent capability.

Selecting a model in an Expert does not grant provider or subscription access. If the model is unavailable, the Expert still cannot use it.

Tools

Tools let the assistant search, fetch sources, execute code, generate images, query staged data, or ask the host application to perform a business action.

Tool availability can depend on:

• account and subscription features;
• the selected Expert;
• model compatibility;
• workspace permissions;
• embed configuration;
• host registration for parent tools.

A tool shown in an Expert definition can still be omitted at runtime when access is unavailable. This is expected fail-closed behavior.

For high-impact tools, require server-side authorization and validate the current user. A model deciding to call a tool is not authorization.

Skills

A Skill is a workspace fragment containing reusable instructions. Released progressive discovery finds Skill fragment metadata only in workspaces already included in Chat context.

This keeps discovery scoped and inexpensive:

• Chat does not browse unrelated workspaces for Skills;
• the initial catalog includes metadata, not full instructions;
• a Skill must be loaded into conversation context before its instructions are followed;
• normal workspace permissions still apply.

Where the feature is available, type /skill in the composer to search discovered Skills by title, summary, tags, or workspace. Selecting one inserts a canonical Skill reference. You can add arguments after the selection.

Chat then adds the Skill fragment to the current or pending context and turns the command into a normal instruction for the assistant.

Use /skill safely

1. Add the workspace containing the Skill to Chat context.
2. Type /skill and search for the intended title.
3. Confirm the workspace and summary, especially when titles are similar.
4. Select the Skill and add task-specific arguments.
5. Verify that the assistant loaded the Skill rather than merely mentioning it.
6. Review any actions produced by the Skill according to the available tools and permissions.

Skill discovery is capped and context-scoped. If a Skill is missing, narrow the workspace scope or add the exact Skill fragment as context.

Skills and Experts together

An Expert provides the stable role, model preference, and tool envelope. A Skill provides task-specific instructions that can be loaded for one piece of work.

For example, a documentation Expert might have source-search tools, while separate Skills describe how to review a guide, prepare release notes, or check public safety.

Do not claim that Expert-pinned Skills or other proposed composition features are available unless the current UI exposes them. Context discovery and /skill invocation are the verified baseline described here.

Parent-local Skills

An embedded assistant can receive parent tools with Skill metadata. This makes host-provided capabilities discoverable without exposing internal APIs directly.

The host still owns implementation and authorization. Skill metadata explains when to use a capability; it does not make an unsafe tool safe.

Good practices

• Give each Expert one clear responsibility.
• Enable only tools needed for that responsibility.
• Store durable task instructions as focused Skill fragments.
• Use clear Skill titles, summaries, and tags.
• Keep Skill discovery inside intentional workspace context.
• Test failure behavior when tools or models are unavailable.
• Review system prompts and prompt-source fragments after product changes.

Troubleshooting

/skill shows no results

Confirm the relevant workspace is in context and contains an active Skill fragment type. Search by a simpler term or add the exact fragment to context.

The assistant names a Skill but does not follow it

The catalog is metadata-only. Ensure the selected Skill fragment was added to the conversation context.

An Expert tool is missing

Check the account feature, selected model, Expert configuration, workspace access, and embed feature locks.

A parent tool times out

Confirm the host registered it after iframe readiness, handles the call, returns JSON-safe data, and uses an appropriate timeout.

Related pages

• Context and grounded answers
• Models, modes, and privacy
• Memory fragments