What we need
A real settings screen for configuring dotAI providers, replacing the hand-written JSON object in a textarea.
dotAI supports seven providers — OpenAI, Azure OpenAI, Google AI, Amazon Bedrock, Vertex AI, Anthropic, OpenRouter. Configuring any of them today means authoring a large JSON object by hand, with no field validation, no indication of which providers support which capability, and no way to check whether credentials work until something fails at runtime.
This is a configuration surface only. No new provider support, no change to how requests are made at runtime.
Why it matters
The capability is shipped and enterprise-ready. The configuration experience is the first thing a customer touches, and right now it's a blank textarea plus a documentation page.
Three concrete failures:
- A typo is silently accepted. A wrong key name or malformed JSON saves fine and surfaces later as a runtime error, far from the cause.
- Nothing states what a provider supports. Chat, embeddings, and image generation are configured independently and providers differ — some serve all three, some only chat. That knowledge lives in docs, so an admin can configure a provider for a capability it cannot serve and only discover it when it breaks.
- Credentials can't be verified. Save, then use the feature and hope.
Provider-agnostic AI with bring-your-own-key is what clears enterprise AI review. Requiring hand-authored JSON to exercise it works against the reason it was built.
What "done" looks like
An admin opens dotAI settings, picks a provider for each capability, fills in the fields that provider asks for, tests the connection, and saves — without consulting documentation or writing JSON. Invalid configuration is caught at entry rather than at runtime.
First-draft design: dotAI Provider Config.dc.html — interactive, worth clicking through. It establishes the intended shape: a section per capability (Chat, Embeddings, Image Generation), each independently configurable, plus a shared Settings section for prompts and behavior that apply across all of them. It is a draft, not a final spec — it still needs a design pass.
Providers can be mixed: chat on one provider, embeddings on another. The active provider per capability should be visible at a glance.
Acceptance criteria
Out of scope
- New provider support. Seven already ship; this configures them.
- Runtime or model-routing changes. No change to how requests are made or which model serves them.
- Prompt engineering features beyond exposing the prompt fields that already exist.
- Usage, cost, or quota views. Adjacent, but a separate concern.
- Per-site or per-role provider configuration. A scope decision in its own right, not a UI change.
Notes
Provider field sets differ more than they look. Bedrock needs AWS credentials and a region, Vertex needs a service account and project, Azure needs a deployment name and endpoint. Worth knowing what all seven actually require before settling the form model — if a shared-field approach is too narrow, the escape hatch becomes the primary path and the UI stops helping.
The eighth provider shouldn't reopen this work. Whatever the form is built from, adding a provider should be a configuration change rather than a UI change.
Customers have working JSON in production. Reading it into the new UI without mangling it is a correctness requirement, not a migration nicety.
A connection test costs the customer money. Verifying a chat provider means a real call against their key. Worth being deliberate about rather than discovering later.
Open questions
- Does the free-form JSON path stay? Remove it, keep it read-only, or keep it editable as the escape hatch. Product's inclination is a structured key/value escape hatch instead of a free-form textarea, but that risks stranding a provider-specific setting the UI doesn't model — happy to be told what the field sets actually demand.
- Is provider capability and field metadata available at runtime? Which capabilities a provider supports and which fields it needs should come from one source rather than being duplicated in the UI. If that doesn't exist today, exposing it is part of this work.
- Does a connection test need to be per capability? Chat, embeddings, and image generation exercise different endpoints, so one check may not prove all three.
References
What we need
A real settings screen for configuring dotAI providers, replacing the hand-written JSON object in a textarea.
dotAI supports seven providers — OpenAI, Azure OpenAI, Google AI, Amazon Bedrock, Vertex AI, Anthropic, OpenRouter. Configuring any of them today means authoring a large JSON object by hand, with no field validation, no indication of which providers support which capability, and no way to check whether credentials work until something fails at runtime.
This is a configuration surface only. No new provider support, no change to how requests are made at runtime.
Why it matters
The capability is shipped and enterprise-ready. The configuration experience is the first thing a customer touches, and right now it's a blank textarea plus a documentation page.
Three concrete failures:
Provider-agnostic AI with bring-your-own-key is what clears enterprise AI review. Requiring hand-authored JSON to exercise it works against the reason it was built.
What "done" looks like
An admin opens dotAI settings, picks a provider for each capability, fills in the fields that provider asks for, tests the connection, and saves — without consulting documentation or writing JSON. Invalid configuration is caught at entry rather than at runtime.
First-draft design:
dotAI Provider Config.dc.html— interactive, worth clicking through. It establishes the intended shape: a section per capability (Chat, Embeddings, Image Generation), each independently configurable, plus a shared Settings section for prompts and behavior that apply across all of them. It is a draft, not a final spec — it still needs a design pass.Providers can be mixed: chat on one provider, embeddings on another. The active provider per capability should be visible at a glance.
Acceptance criteria
Out of scope
Notes
Provider field sets differ more than they look. Bedrock needs AWS credentials and a region, Vertex needs a service account and project, Azure needs a deployment name and endpoint. Worth knowing what all seven actually require before settling the form model — if a shared-field approach is too narrow, the escape hatch becomes the primary path and the UI stops helping.
The eighth provider shouldn't reopen this work. Whatever the form is built from, adding a provider should be a configuration change rather than a UI change.
Customers have working JSON in production. Reading it into the new UI without mangling it is a correctness requirement, not a migration nicety.
A connection test costs the customer money. Verifying a chat provider means a real call against their key. Worth being deliberate about rather than discovering later.
Open questions
References