The AI Gateway
Several platform features use a language model. The gateway is where you say which provider each of them uses, so the choice is configuration rather than something baked into each feature.
Where to find it
Architect Panel → Data:
- AI Builder — one of the features that uses it
- Query Builder — another consumer
Architect Panel → Integration & Connections:
- AI Tool Access (MCP) — a separate thing — letting an AI reach in
This is outbound, and MCP is inbound
Worth separating immediately. The gateway is the platform calling a model. AI Tool Access and Agent Access are an AI calling the platform. Different directions, different risks, different settings.
The features that use it
- The signup wizard, turning a description into a starting blueprint.
- AI Builder, producing change sets against your application.
- Query Builder, turning a question into a query definition.
- The code editor, generating extension source.
Each can name its own provider and model, or inherit a default.
Per-role configuration is the point
The roles differ in what they need. Writing code rewards a strong model; producing a query definition does not need the same. Pointing each role separately means paying for capability where it matters rather than everywhere.
Anything left blank falls back to the default pair, so you can configure one provider and be done, then specialise later.
Provider and model travel together
A model identifier belongs to a provider. Setting a role's provider without its model — or the reverse — is how you end up handing one provider a model name belonging to another, which fails in a way that reads as the provider being broken.
Change them as a pair, or leave the model blank to take that provider's own default.
Query Builder sees field names only
Worth stating plainly, because it is the question people ask first. The Query Builder role is given field names, never a record value, and what comes back is a query definition rather than an answer.
So the model helps construct the question; it does not see the data, and the results are produced by running the query here. That is a meaningfully different privacy position from sending your records to a model, and it is worth understanding before assessing the feature.
Three ways a request can be delivered
- API — the platform calls the provider directly.
- Clipboard — the request is prepared for you to paste elsewhere. Nothing leaves the platform.
- CLI — handed to a locally installed tool.
Clipboard is the option to know about if you are not ready to send anything outbound: the feature remains usable and the platform makes no external call.
These are AI features, not AI decisions
Everything here produces a proposal for a person: a blueprint, a change set, a query, some source. Nothing is applied without somebody accepting it, which is the right arrangement and worth preserving as you configure.
Worked example
An organisation sets one default provider for everything, then points the code editor role at a stronger model because that is where output quality matters most. Query Builder is left on the default, on the basis that it only ever sees field names.
Recommendations
- Keep gateway and MCP separate in your thinking — opposite directions.
- Start with one default and specialise on evidence.
- Change provider and model together.
- Consider clipboard delivery if outbound calls are not yet agreed.