Bring your own LLM to Salesforce

Every serious Salesforce AI conversation now hits the same fork: “can we use our own model?” Sometimes it’s a data-residency requirement — the security team has approved Anthropic Claude on your own Bedrock account in your own region and nothing else. Sometimes it’s cost — you’ve negotiated provisioned throughput and want your Salesforce prompts to run through it. Sometimes it’s capability — you have a fine-tuned model that knows your product taxonomy and you’d rather not re-teach it to a stock GPT.

The answer is yes, you can bring your own model. But “bring your own model” in Salesforce is not one feature, it’s three overlapping ones, and teams conflate them constantly. The surface that lets you register a custom model and point Prompt Builder at it is not the same surface that decides which model reasons for your Agentforce agent. Get that wrong and you’ll spend a sprint wiring a beautiful BYO endpoint into Model Builder, then discover your agent is still running on the Salesforce default because Agentforce never looked at it. This post is the map: what each surface does, where they connect, and the exact wiring for a custom model that stays inside the Einstein Trust Layer.

Three surfaces, three different jobs

Start by separating the three things people mean when they say “our own LLM.”

1. Model Builder (AI Models, formerly Einstein Studio). This is where you register a model — Salesforce-hosted or your own — as a foundation model in the Model Library and configure it. It’s a Data Cloud–adjacent tool. Registering a model here makes it available to generative features that read from the Model Library: chiefly Prompt Builder templates and the Models API.

2. The Agentforce model selector. This is a separate setting on the Agentforce Agents page in Setup. It controls which model the Atlas reasoning engine and your agent’s actions use. It is a short, curated list — not the open Model Library. This is the setting most teams forget exists.

3. The Models API. A developer surface — Apex methods and REST endpoints — that lets your own code call any model in the Library through the Trust Layer, with extras like embeddings and chat generations that carry history. This is how you embed a governed LLM call inside a Lightning web component or an Apex service without going through Prompt Builder at all.

The single most expensive misunderstanding here: registering a model in Model Builder does not change which model your agent reasons with. Agentforce reads its own selector, not the Model Library.

Hold that distinction and the rest falls into place.

What “bring your own LLM” actually means in Model Builder

BYOLLM (Bring Your Own Large Language Model) is the Model Builder feature that lets you add a foundation model hosted on an external platform, using your own provider account, and connect it to Salesforce. When you add it, Salesforce establishes an endpoint connection between your provider and the platform, and the model lands in the Model Library as a foundation model you can configure and test in a playground before anything touches production.

Out of the box, BYOLLM ships four built-in provider options:

OpenAI (your own OpenAI account)
Azure OpenAI
Google Gemini Pro (Vertex AI)
Anthropic Claude on Amazon Bedrock

That last one is why regulated industries lean on this path: Claude on your own Bedrock account lets you pin region and keep the model inside a boundary your security team already signed off on.

Those four cover a lot of the landscape, but not all of it. For everything else there’s the escape hatch.

The LLM Open Connector: any model, one contract

The LLM Open Connector is Salesforce’s answer to the combinatorial mess of point-to-point model integrations. Instead of building a bespoke connector for every provider, Salesforce published an OpenAPI specification, closely based on the OpenAI API, and said: implement this, and your model plugs into the same BYOLLM experience as the built-ins. It’s how customers connect Mistral, Llama, Cohere, IBM Granite, Databricks DBRX, AI21 Jamba, xAI’s Grok, models behind Hugging Face or Groq or SambaNova — or a model your own team hosts.

The contract is smaller than people expect. The spec requires exactly one endpoint:

POST /chat/completions

That’s it. /chat/completions is the endpoint Prompt Builder and Agentforce require; if your gateway serves that one route to the spec, you have a connectable model. A few sharp edges from the spec and the project’s own FAQ that trip people on the first attempt:

The endpoint URL must end in /chat/completions. Not /v1/completions, not a custom path. If your proxy exposes something else, add a route.
HTTPS on port 443 is required for a remote model endpoint.
Auth is a header. Register an API key against the api-key header, or for a bearer token put Authorization in the auth-header field and Bearer <token> as the value.
The created timestamp is in seconds, Unix epoch. If your model server returns milliseconds — a very common default — convert it, or Salesforce rejects the response.
The usage object differs slightly from OpenAI’s. Follow the Open Connector schema, not OpenAI’s, or you’ll get a usage-object error even though everything else works.

The request body will look familiar to anyone who’s called OpenAI — messages, model, max_tokens, and friends — because it’s deliberately close:

{
  "model": "your-model-id",
  "messages": [
    { "role": "system", "content": "You are a support assistant for ACME." },
    { "role": "user", "content": "Summarize this case in two sentences." }
  ],
  "max_tokens": 512
}

The practical shape of an Open Connector deployment is a thin gateway: a small REST service that accepts the Open Connector request, translates it to whatever your real model wants (a Bedrock InvokeModel call, a Vertex request, a self-hosted vLLM server), and maps the response back to the spec. Salesforce’s own einstein-platform repo ships recipes for exactly this against AWS, Hugging Face, Groq, IBM, and others. You host the gateway; Salesforce calls it. One more operational detail teams miss until a firewall blocks it: Salesforce calls out from a known set of IP addresses, and if your endpoint sits behind an allowlist you have to add the BYO Models and Open Connector ranges (published in Salesforce’s “Core Services — IP Addresses and Domains to Allow” article) before the connection will succeed.

Where the Trust Layer sits — and why BYO doesn’t mean unguarded

A reasonable worry: if I route Salesforce prompts to my own model, do I lose the Einstein Trust Layer? No. Whether you call through Prompt Builder or the Models API, the request goes through the Trust Layer on its way to your registered model. That means the same pipeline you’d get on a Salesforce-managed model — dynamic grounding, PII masking, zero-retention agreements, toxicity scoring, and the audit trail — still wraps a BYO model. The value of BYO on Bedrock, for a regulated org, is precisely this combination: the model runs in your boundary, and the data-handling guarantees still apply on the way there and back.

What BYO does not do is absolve you of the data-quality and grounding work. A model you host will hallucinate on ungrounded prompts exactly like a hosted one. The Trust Layer governs how data flows; it doesn’t make a weak prompt correct.

The part everyone gets wrong: Agentforce reasons on its own list

Here’s the wall teams hit. You register Claude via BYOLLM, wire it into a Prompt Builder template, and it works. Then you assume your Agentforce agent — which is doing the real autonomous work — is now reasoning on Claude too. It isn’t.

Agentforce’s reasoning model is set by its own selector, on the Agentforce Agents page in Setup, and it applies globally to every agent in the org. The choices there are a short curated set, not the open Model Library:

Salesforce Default — a managed mix of trusted models (currently including OpenAI GPT-4o), tuned by Salesforce for accuracy and trust. Zero configuration.
AWS-hosted — Anthropic Claude Sonnet 4 on Amazon Bedrock, the option regulated orgs pick for residency control.
Google Gemini on Vertex AI.

Salesforce has been widening this list — Gemini support and GPT-5 selectability were announced at Dreamforce 2025 — but the point stands: the Atlas reasoning engine picks from Salesforce’s curated options, not from an arbitrary BYO endpoint you registered in Model Builder. If your requirement is “our agent must reason on our own fine-tuned Llama,” the model selector will not grant it today.

So how do you get a custom model into an agent’s behavior? Through an action, not the reasoning loop. A custom agent action that invokes a Prompt Builder template, Apex, or the Models API can reference any model in the Library — including your BYO model. The architecture that actually works looks like this:

Reasoning — planning, topic classification, tool selection — runs on a curated model via the Agentforce selector. This is the Atlas engine’s job and you want a strong, trusted general model here.
Specialized generation — a domain summary, a compliance-worded response, a translation into your product taxonomy — runs inside an action that calls your BYO model through a prompt template or the Models API.

You get the trusted reasoning core and the bespoke model exactly where it adds value, without pretending the selector does something it doesn’t.

A decision path

Put the three surfaces on the table and the choice is usually clear:

You want a custom or region-pinned model behind Prompt Builder templates or your own LWC/Apex. Register it via BYOLLM (built-in provider or Open Connector) and call it through Prompt Builder or the Models API. Fully supported today.
You want your agent’s reasoning on a specific vendor for residency or trust. Use the Agentforce model selector — Salesforce Default, Claude on Bedrock, or Gemini. You pick from the curated list, not your Library.
You want an arbitrary self-hosted model doing real work inside an agent. Register it via the Open Connector, then invoke it from a custom action’s prompt template or Apex — not the reasoning selector.
You just want a good agent and don’t have a model mandate. Stay on Salesforce Default. It’s a managed, tuned mix, and it’s the cheapest path to a working agent. Don’t add BYO complexity to satisfy a preference nobody’s actually enforcing.

The gotchas worth pricing in

BYO does not remove consumption cost. You pay your provider for the tokens and the Salesforce-side consumption still applies. Registering your own model is a control and residency decision, not a way to escape Agentforce’s credit meter. Model your year-one number with both.
You own the gateway’s uptime. An Open Connector endpoint is production infrastructure. If your /chat/completions gateway is down or slow, your prompts and agent actions fail or lag. That’s a service you now operate, with its own on-call.
Region and version drift. Pin the model version at the provider. A silent upgrade on your Bedrock or Vertex model can change behavior under a prompt you validated months ago — the same regression risk you’d get anywhere, but now it’s on infrastructure you manage.
The selector is global. Changing the Agentforce model applies to every agent in the org. There’s no per-agent reasoning model today, so a change to satisfy one regulated agent moves all of them. Test the whole fleet, not one agent.
Match the model to the job, not the brand. Reasoning quality on your topics and instructions matters more than the logo. Before you standardize on a BYO model for agent actions, run it through the same test harness you’d use for any agent change.

The takeaway

“Can we use our own model?” has a real yes behind it, but the useful answer is a question back: for what? Model Builder and the LLM Open Connector give you genuine freedom for Prompt Builder templates, the Models API, and custom agent actions — any provider, any self-hosted model, all still wrapped by the Trust Layer. The Agentforce reasoning selector gives you a curated, trust-vetted choice for the autonomous core, and deliberately doesn’t open that core to arbitrary endpoints. The teams that ship clean BYO architectures are the ones that stop treating “bring your own model” as a single switch and start placing each model where its surface actually reaches: trusted reasoning at the center, your own model at the edges where residency, cost, or specialization earn their keep.

If you’re weighing whether a model mandate is even worth the operational surface it adds, that’s an architecture-and-data question before it’s a model question — the Agentforce Readiness Assessment is a fast way to pressure-test where you actually stand.

Bring your own LLM to Salesforce: the honest map of Model Builder, the Open Connector, and what Agentforce actually lets you swap