# Bring your own model is a compute decision


The model is one hop in the request. Ownership gets decided at the hops around it: who assembles the context, who runs the workflow and whose screen records the judgment.

> By Saad Bin Shafiq, Founder of Nodes · Oct 28, 2026
> Canonical: https://www.nodes.inc/blog/bring-your-own-model-illusion

**Answer:** Bring Your Own Model lets an enterprise choose the model behind a vendor's application, which can settle provider, cost and inference location. Context assembly, workflow orchestration, the interface and the record of human corrections can all stay with the vendor. Test the offer by asking what survives a change of vendor, then put those artifacts and rights in the agreement.

---
If a software vendor lets you bring your own model but still assembles the context, runs the workflow and owns the screen, you have brought your own compute to someone else's moat.

I understand why the offer lands. A data-sensitive enterprise has fair questions about any model: which provider, under what terms, in which region, on whose bill. A Bring Your Own Model feature can answer all of them from one configuration page. The security team gets a provider it has already reviewed. Finance gets to use a commitment it already signed.

Those gains are real and I would not talk anyone out of them. My objection is narrower. The word "own" is traveling further than the feature does.

Two swap tests separate the cases. Change the model and see what survives. Then change the vendor and see what survives. A model slot is built to pass the first. Ownership gets decided by the second, and the feature has nothing to say about it.

## What the documentation says

The documentation is more careful than the way these features get repeated in buying committees. Read it for what moves and what stays.

Salesforce's [Trailhead module](https://trailhead.salesforce.com/content/learn/modules/large-language-models/learn-how-salesforce-uses-large-language-models) says you can connect your own LLM for use in custom Prompt Builder templates, and that an external model "works just the same as an internally connected LLM," with the request routed through the LLM Gateway and the Einstein Trust Layer before content reaches users. A [2024 developer post](https://developer.salesforce.com/blogs/2024/03/bring-your-own-large-language-model-in-einstein-1-studio) pitches the feature to teams with an existing agreement with a model provider. Reasonable design. That wording also tells you exactly what changed: the endpoint.

Microsoft's [Copilot Studio documentation](https://learn.microsoft.com/en-us/microsoft-copilot-studio/bring-your-own-model-prompts), dated July 14, has you connect an Azure AI Foundry model to a prompt and add that prompt to an agent. Governance for the connection sits in the Power Platform admin center. The page says the connection must use a chat completions endpoint and that GPT-5 and later models are not currently supported on this path. It covers prompts only, and it mentions other ways to reach a Foundry model, such as a plugin or custom action.

A [ServiceNow community article](https://www.servicenow.com/community/now-assist-articles/using-external-llms-with-now-assist-including-byok-byollm/ta-p/3218103) by a ServiceNow employee, last updated July 20, lays the options out in a table. A model outside ServiceNow's certified providers can power custom skills and a limited set of out-of-the-box skills. AI Agents, custom or out of the box, are not currently supported on that option, although a key for an integrated provider is. You configure the connection yourself, scripting included.

The clearest statement of the trade I have found is in [Deepnote's documentation](https://deepnote.com/docs/ai-custom-models), which puts native and custom models side by side. Bring a custom model and the data location moves to your infrastructure and the bill moves to your provider. Agent compatibility goes from guaranteed to not guaranteed, support narrows to configuration issues, and the page warns that a custom model may lack features the agent relies on, such as function calling. I respect that page. It names what the buyer takes on.

Model infrastructure vendors are selling something different. As of mid-October, [Fireworks' enterprise page](https://web.archive.org/web/20261015155524/https://fireworks.ai/enterprise) led with a promise that you can own your AI, and offered deployment on its cloud or on your own cloud, hardware and regions. Agentic systems and retrieval appear there as things you can build on the platform. I read that as a clean boundary: the model layer is the product, and what sits above it belongs to whoever builds it. An application with a model slot draws that boundary somewhere else.

None of the application documentation above claims that connecting a model hands over the context, the workflow or the history. The vendors are straight about this. The gap opens when a four-word feature name gets summarized as ownership in a procurement memo.

## Trace one request

Here is a generic path for a question asked inside a software product with a customer-connected model. It is an illustrative pattern, and no single product above is being described.

1. A person asks a question on the vendor's screen.
2. The vendor's application decides which records to fetch, under whose permissions, and how to rank them.
3. A template on the vendor's platform packs those records, the tool list and the conversation so far into one request.
4. A gateway sends the request to your model, and your model answers.
5. The vendor's layer checks the answer and decides what happens next.
6. The result comes back to the vendor's screen, where the person accepts or changes it.
7. The vendor's system stores what happened.

Your model is step four. Three components around it hold most of what the company will learn.

### Context assembly

A model knows what lands in the request. Anthropic's engineering team [described context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) in September 2025 as curating the tokens a model sees during inference, a set that includes system instructions, tools, external data and message history. All of that gets decided before your endpoint receives anything.

Those decisions are your business written down. Which system wins when two disagree. What a renewal means in this region. Which old records stop counting. Configure them in a vendor's platform and you have written company knowledge in that vendor's format, however portable the model is.

### Workflow orchestration

Orchestration covers the next step, the permitted tool, the retry, the stopping rule and the moment a person gets asked. Every exception your team argues into a workflow is a business rule, and it lives wherever the workflow lives. The function-calling warning in Deepnote's page shows a second dependency. An agent gets built around certain model behaviors, so the slot is less neutral than it looks.

### The screen

The interface is where judgment gets recorded. A reviewer edits a draft, overrides a recommendation, types a reason. That correction may be the most valuable thing the system sees all week, and whoever hosts the screen decides whether it becomes a record you can query, a log line you can request, or nothing.

Your people built that knowledge. A model slot gives you no claim on it.

Apply the second swap test here. In [vendor lock-in is an architecture decision](/blog/vendor-lock-in-is-architecture) I argued that exit should be evaluated artifact by artifact, with company intelligence separated from the runtime. Bring Your Own Model adds no artifact to that list. Change the model, and the template, the workflow and the corrections all stay where they were, which is the design working as intended. Change the vendor and you find out which of them exist anywhere else.

## Identity, permissions and the boundary

In [the gap in the System of Intelligence thesis](/blog/vpc-gap-system-of-intelligence) I asked where the intelligence layer runs. A customer-hosted model answers that for one component. Draw the line around all of them: the application tier, the retrieval index, prompt logs, traces, tool credentials, telemetry and backups.

If the model sits in your cloud and the application reading your records sits in the vendor's, those records still reach the application tier on their way to becoming a prompt. That is often fine. Hosted software does not by itself mean a vendor trains on your data or shares it. Whatever the arrangement is, write it down for the specific configuration, because a private endpoint behind a hosted application is a different boundary from a private deployment.

Then there is identity. Ask what credential reaches your endpoint. If every call arrives under one connector credential, the model-side logs cannot tell you which employee asked, which record was read or which agent acted. Per-person permissions then have to be enforced upstream, and your evidence is whatever that layer exports. Two permission questions sit there that no model can answer: what may this person read, and what may this agent change.

## When it breaks, who can tell

Bring Your Own Model can separate responsibility from visibility. You carry the model's quality and its incidents. The vendor holds the evidence needed to diagnose them. Four failure modes show whether that split will hurt.

**Silent degradation.** A new model version answers differently. To tell a model regression from a retrieval change, you need the exact context that was sent, the template version and the output for the same case.

**Rollback.** A model and a template get tested as a pair. Ask whether you can pin both at their earlier versions, or only the model.

**Evaluation.** A candidate replacement needs testing on your own cases for task quality, latency, risk and total AI and human cost. Read-only replay lets you do that without touching production. If the corrected outcomes live in the vendor's store, so does your test set.

**Stopping the work.** Pulling your endpoint stops inference. It does not tell you what the last run did, and it reverses nothing that already happened in a downstream system. Pause and revoke controls belong at the workflow, with a record of what was in flight.

Approval has the same problem. A gate on the vendor's screen can work well. What matters is what it leaves behind: who approved what, and on what evidence. That record should outlast the software, and approving something once should never widen what the system may do next time.

## When a model slot is the right purchase

Often. If the application is a narrow tool and what it accumulates is disposable, a model slot gets you the provider and terms you wanted at low cost. If your real question is data location or a spend commitment, it may be the whole answer. A managed gateway and checking layer is also work you do not have to build, and for many teams that beats control over a component they would never staff.

The strongest objection is that a fine-tuned model is far more than compute. I agree. Weights can carry real company-specific behavior, and [open weights are not owned weights](/blog/open-weights-are-not-owned-weights) covers that purchase and its rights. A fine-tuned model still reads only what the application sends it, though, and its weights hold what the training set held. An override from last Tuesday reaches them only if someone captured it first, which brings you back to the screen.

An internal build is the other alternative. It gives you every artifact and every on-call rotation: retrieval, orchestration, permissions, evaluation and the interface all become yours to staff. Some companies should make that trade. Others will keep a vendor's application and negotiate for the artifacts, which can work if the rights are written down and tested. [This asset table](/blog/who-owns-your-agents-memory) is a good place to start.

## What to ask before you sign

Five requests will tell you more than the feature page.

1. Draw the boundary for our configuration, covering every component that reads our records, and name what leaves it.
2. Show the exact request for one real case: records, ranking, template version, tools and model version.
3. Show where corrections, approvals and outcomes are stored, and give us a sample we can read without your application.
4. Walk us through changing the model next month: which of our cases run, who reads the disagreements, and who can roll it back.
5. Walk us through changing vendors next year: what we hold that another system can use, and what we lose.

The same five apply to us. Nodes is a vendor, and we keep our applications, updates and platform IP. Nodes Engine provides the context graph, the intelligence layer and the system-of-action layer. The context graph is the company's knowledge graph connecting records, relationships, human judgment, decisions and outcomes. Models and agents can be swapped after evaluation, and the company retains its graph, business rules, Decision Traces and outcome history so new AI can use what the business already knows. Nodes works within configured permissions. Actions requiring approval remain gated by the customer's policy. Export formats and transition duties belong in the agreement, so ask us for the sample too.

Boundaries differ by deployment, and I will not collapse them. Nodes Cloud is a Nodes-managed environment and does not sit inside your cloud. A single-tenant customer VPC or customer-managed on-premises deployment can enforce zero customer production-data egress inside the approved boundary, when the models, tools, telemetry, backups and updates in that configuration support it. Deployment and approved model connections set the processing boundary, which can include customer-approved hosted inference where configured. Our public production evidence comes from a Fortune 1000 insurance carrier and supports that deployment only. It tells you nothing about how your model route will behave, so test it. The [security overview](/security) and [platform architecture](/platform) carry the detail.

A model slot is a fair thing to buy. Buy it as what it is: a choice about who serves the inference. The reviewer correcting your system is producing the one thing no model upgrade can replace. Bring any model you like, then find out who keeps the correction.

## Sources

- [Salesforce Trailhead: Learn How Salesforce Uses Large Language Models](https://trailhead.salesforce.com/content/learn/modules/large-language-models/learn-how-salesforce-uses-large-language-models)
- [Salesforce Developers Blog: Bring Your Own Large Language Model in Einstein 1 Studio](https://developer.salesforce.com/blogs/2024/03/bring-your-own-large-language-model-in-einstein-1-studio)
- [Microsoft Learn: Bring your own model for your prompts](https://learn.microsoft.com/en-us/microsoft-copilot-studio/bring-your-own-model-prompts)
- [ServiceNow Community: Using external LLMs with Now Assist (including BYOK/BYOLLM)](https://www.servicenow.com/community/now-assist-articles/using-external-llms-with-now-assist-including-byok-byollm/ta-p/3218103)
- [Deepnote documentation: Custom AI Models](https://deepnote.com/docs/ai-custom-models)
- [Fireworks AI enterprise page, Internet Archive capture of October 15, 2026](https://web.archive.org/web/20261015155524/https://fireworks.ai/enterprise)
- [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.*