dotAI Setup, Simplified: Your Model, Your Rules, Live in Minutes

There are two different questions a team asks about AI in a content platform, and they usually get answered months apart.

The first is can it run on our AI? For a compliance-led organization this is not a preference. Security has an opinion about which provider is acceptable, legal has an opinion about what may be sent to it, and the answer is frequently "our own account on our own cloud, or nothing."

The second question arrives later, once someone has been told yes: does any of this actually work on our content? Not on a vendor demo corpus — on the policy library, the product catalog, the ten years of press releases.

dotAI has answered the first question for a while: seven providers, on your key, through your account — OpenAI, Azure OpenAI, Google AI (Gemini), Amazon Bedrock, Vertex AI, Anthropic, and the OpenRouter aggregator. What is new is how much less work it takes to get from the first answer to the second. dotAI now has a configuration screen built around the way AI is actually adopted, and a workspace where you can exercise every capability against real content before anyone commits to anything.

Configure one capability at a time

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.

That separation matters more than it sounds. Providers differ in what they serve; some cover all three capabilities, some only handle chat. In the configuration screen the provider picker tells you which capabilities each provider supports, and combinations that a provider cannot serve are not selectable, with the reason shown in place. You find out at the moment of choosing rather than at the moment of running.

It also means you can mix. Chat on one provider, embeddings on another, for whatever reason your architecture has — cost per token, latency, where a particular model is allowed to run. The active provider is visible per capability, so the answer to "what is this instance actually pointed at" is on screen rather than in someone's memory.

Once you pick a provider, the form asks for the fields that provider actually requires, and validates them as you type. Commonly used fields are surfaced; the optional ones stay out of the way until you want them. Model fallback is configurable. And for anything a given provider supports that the form does not model directly, there is an Additional properties section — a structured escape hatch, so no setting is out of reach.

Test the connection before you save

The single most useful thing on the screen is a button.

Test Connection runs per capability. It builds the real model client and issues one minimal live call against the provider you just configured — your endpoint, your credentials, your account — and tells you what happened. If it fails, you get an error you can act on, next to the field that caused it.

The reason it is per capability is that chat, embeddings, and image generation exercise genuinely different endpoints, with different failure modes and different timing. Image generation gets a longer timeout because real generation routinely takes longer than a chat round trip.

How the form knows what to ask for

For developers and architects, the implementation detail that matters most is this: the configuration form renders entirely from provider metadata returned by the backend. There is no per-provider frontend code.

Each provider describes its own fields — including cross-field rules, such as Azure's requirement that you supply either a model or a deployment name — and the UI builds itself from that description. The design constraint driving it was blunt: adding an eighth provider should not mean reopening the frontend. It is a metadata change.

The credential handling is deliberate and worth stating plainly. Secret fields are stored on the host. Once saved, a secret renders read-only and the real value never reaches the browser — what the UI holds is a mask. There is also a guard on the test path that prevents a stored secret from being sent anywhere other than the destination it was stored for, so a connection test cannot be turned into a way to extract a key to an endpoint someone else typed in.

If you configure dotCMS through automation rather than by hand, nothing changed for you: the underlying providerConfig contract still works, and configuration authored that way loads and renders correctly in the new screen.

Then actually use it

Configuration is the on-ramp. The dotAI workspace, under Developer Tools, is where you find out whether the thing is useful — and it has been rebuilt. It now picks up your installation's own theme, every string in it is translatable, and each tab is addressable by its own URL, so a specific view can be bookmarked or pasted into a ticket.

Five tabs:

Search runs a semantic search over an index of your content and returns ranked results, each with the passage that matched and how close it was, under a header showing the result count, how long it took, and the threshold in effect. Your last query is restored when you come back, because tuning retrieval is an iterative activity and retyping the query every time is a tax on it.

Chat answers questions grounded on that same index. Answers render progressively as they arrive, you can stop one mid-flight when it is obviously going somewhere you did not want, errors report inline instead of leaving you with a blank panel, and leaving the tab cancels the request rather than letting it run on.

Search and Chat share a retrieval settings panel — index, site, content types, response length, model, temperature, threshold, distance — and it persists between visits. This is the part that turns a demo into an evaluation. Threshold is a maximum distance, so raising it widens the net; watching result counts move as you adjust it is how you find the setting that suits your content rather than accepting a default.

Embeddings is where indexes are managed: a list of every index with its content count, coverage, an estimated cost, and its build status, plus a guided dialog for creating an index and adding content to it. Deleting and rebuilding sit behind confirmations.

Image generates from a prompt, previews the result, and shows you the rewritten prompt that was actually used. Saving to your asset library and downloading are two separate, explicit actions — nothing is written into your content without you asking for it.

Config Values lists every resolved dotAI setting with its key, its value, and where that value came from, with secrets masked. When one environment behaves differently from another, this is the tab that ends the conversation.

What this is for

A few scenarios it was built around.

Clearing an AI review. An architect points dotAI at the organization's own Bedrock or Azure OpenAI account, runs Test Connection in front of the security team, and can show where the credential lives, that it is never rendered back into the browser, and that it is never sent anywhere but the endpoint it was stored for. The configuration is then inspectable, with sources, from Config Values.

Proving semantic search is worth it. Build an index scoped to one site and a few content types, run the queries people actually ask, adjust the threshold until the ranked passages look right, and decide on evidence rather than on a vendor's sample data.

Standing up a new environment. Configure three capabilities, test each one, confirm the resolved settings match the environment you copied from — without reading documentation to remember the shape of a JSON object.

Generating imagery where the content lives. Produce an image from a prompt, review the rewritten prompt, and save it into the asset library in the same system that will publish it.

Where to start

If dotAI is already configured on your instance, the configuration you have keeps working — open the dotAI app configuration and it will render as a set of capability sections rather than as raw JSON. If it is not configured yet, start with chat, pick the provider your organization has already approved, and press Test Connection before you do anything else.

Then open the dotAI workspace, build one index over content you know well, and ask it something you already know the answer to. That is the fastest honest read on whether AI is going to be useful on your content — and it now takes an afternoon rather than a project.