dotAI Configuration

Description

For the administrators and developers who stand dotAI up, and the teams who then use it: dotAI App Configuration is where you configure AI against your own provider and the updated dotAI Tool is where you exercise it against your own content.

dotAI does three distinct things. Each gets its own section, and each can be turned on or off on its own — without losing its configuration when you do.

• Chat is text generation. It powers the AI Content block in the Block Editor, the workflow actions that generate copy, auto-tag content and write image descriptions across large batches of content at once, and the text endpoints and Velocity viewtool your own code calls.

• Embeddings turn your content into a semantic index. That index is what semantic search queries, and what grounds chat answers in your own content instead of the model's general knowledge.

• Image generation creates images from a prompt — on demand, or through a workflow action that writes the result straight into a content field.

Configuration is organized by capability. Chat, embeddings, and image generation are set up independently and can be enabled or disabled on their own without losing their configuration. Choosing a provider shows you which capabilities that provider supports, so unsupported combinations are never selectable, and each provider asks only for the fields it actually requires, validated as you type. You can mix providers — chat on one, embeddings on another — and the active provider is visible per capability. dotAI runs on seven providers: OpenAI, Azure OpenAI, Google AI (Gemini), Amazon Bedrock, Vertex AI, Anthropic, and the OpenRouter aggregator. Test Connection runs per capability, issuing one real call against your endpoint and credentials so you know the setup works before you save it.

The dotAI Tool, under Developer Tools, is the other half, rebuilt around five tabs — Search, Chat, Image, Embeddings, and Config Values. It picks up your installation's own theme, every string in it is translatable, and each tab is addressable by its own URL.

The configuration form renders from provider metadata returned by the backend rather than from per-provider frontend code, so new providers arrive as metadata. Secret fields are stored on the host and never rendered back into the browser. Automated setup through the providerConfig contract continues to work, and configuration authored that way renders correctly in the screen.

Benefits

For Developers and Platform Teams

• Verify a provider works with Test Connection before saving, per capability, against your own endpoint and credentials.

• Keep credentials on the host: saved secrets render read-only and the real value never reaches the browser.

• Configure through the UI or keep using the providerConfig contract for automated environment setup — both paths render the same configuration.

• Read every resolved setting with its key, value, and source from the Config Values tab when two environments disagree.

For Content and Marketing Teams

• Search your own content semantically and see ranked passages with a closeness value, result count, and elapsed time.

• Ask questions against your content library with answers that render progressively and can be stopped mid-answer.

• Generate images from a prompt, review the rewritten prompt, and save to the asset library as an explicit action.

• Work in a screen that picks up your installation's theme and language, with each tab addressable by URL so a view can be shared.

Use Cases

Clearing an AI review with your own account

An architect at a compliance-led organization points dotAI at the company's own Amazon Bedrock or Azure OpenAI account and runs Test Connection with the security team watching. They can show where the credential is stored, that it is never rendered back into the browser, and that it is only ever sent to the endpoint it was stored for. The resolved configuration is then inspectable, with sources, from Config Values.

Deciding whether semantic search earns its place

A developer builds an index scoped to one site and a handful of content types, runs the questions people actually ask, and adjusts the retrieval threshold while watching the ranked passages and result counts change. Retrieval settings persist between visits, so the tuning survives a coffee break and the decision rests on the organization's own content.

Splitting capabilities across providers

A platform team runs chat on one provider and embeddings on another, chosen for cost, latency, or where a given model is permitted to run. Each capability is configured and tested separately, and the active provider for each is visible on the screen.

Standing up a new environment quickly

An administrator configures chat, embeddings, and image generation, tests each one, and confirms the resolved values match the environment they were copied from — without reconstructing a JSON object from memory.

Resources

• Feature Blog Post

• Run dotAI on the AI provider you choose