Which model, and whose account

What it is, and what it is not

Two separable things: a routing layer that sends each request to a model sized for it, and the option to run every request under your own provider account instead of ours.

It is not model choice as a feature. Letting a customer pick a model per agent sounds like control and mostly produces a configuration surface nobody can reason about — a tenant running one agent on a small model and another on a large one has performance characteristics that vary by question in ways no user can predict.

It is also not a claim that the model does not matter. It matters a great deal for answer quality; what it does not do is change any security or permission property, because those are enforced at the tool layer beneath whichever model is running.

Routing: match the model to the work

Cheap mechanical work routes to smaller models. Classification proposals, similarity matching for duplicate detection, extracting structure from a pasted table — these are high-volume, low-ambiguity operations where a large model spends money to reach the same answer.

Multi-hop reasoning routes to larger ones. A digital thread traversal that has to weigh which of forty affected objects matter, or a change draft that has to assemble evidence from six domains, is where capability earns its cost.

The usage screen shows which model handled which request, so a monthly figure is explicable rather than a single aggregate you can only accept. That transparency is the point of routing being visible rather than a hidden optimisation.

Routing never changes what an agent is *permitted* to do. Tiers, tool allowlists and the tenant predicate sit below the model, so a request routed to a smaller model has exactly the same capability boundary as one routed to a larger one.

Every agent action is audited with the model that handled it, so a question about which model produced a given answer resolves to a row rather than an inference. That matters more with routing in play, because the answer is genuinely not the same every time.

Bring your own key: the stronger control

With your own key, requests go to your provider account under your contract, and Manufacturing PLM never holds the content. That is a materially different claim from a zero-retention arrangement we hold on your behalf, and for some organisations it is the only claim that passes review.

It changes three things. The provider relationship is yours, so their terms are ones you negotiated. The spend is yours, so our metering does not apply. And the data-boundary question has a shorter answer: content reaches a model provider you already contract with, rather than one you inherited by choosing us.

What it does not change is anything else. Permission tiers, tool allowlists, citations, the audit trail and the system-of-record matrix all behave identically, because none of them depend on which account the inference ran under.

The third option is simplest and worth naming: disable agents at tenant level. No content reaches any provider, agent features stop, and nothing else in the product is affected.

Metering attributes usage per agent, per user and per tenant. Under your own key we do not meter at all — the budget mechanism becomes yours to run, which is a trade some organisations want and others specifically do not.

Embeddings for semantic search are computed and stored within the tenant regardless of arrangement, carrying the object revision they were made from. Retrieval therefore behaves identically whether agents are enabled, disabled or running under your key.

The failure it prevents

A security review reaches the AI section. The reviewer's question is not whether the model is good; it is whether tenant content leaves the boundary and under whose contract.

In a product with one arrangement and no alternatives, the answer is a paragraph about zero-retention terms with a third party the reviewer has never assessed. That is frequently enough, and when it is not, the evaluation ends — not because the arrangement is bad but because the reviewer has no way to reduce the exposure.

Offering bring-your-own-key and tenant-level disablement turns a yes-or-no into a configuration. The reviewer who cannot accept our provider relationship can accept their own, and the one who cannot accept any inference provider can run the product without agents and lose nothing else.

How it meets your ERP

ERP-sourced values reach a model as ordinary context when a question needs them, and under your own key they reach your account rather than ours. For an organisation whose policy is that ERP data must not leave its contracted providers, that is the mechanism that makes agents usable at all.

The alternative for such an organisation is disabling the agents that read ERP context specifically, which is a per-agent decision rather than all-or-nothing — the Cost and Supplier agents are the ones that read it most.

No arrangement changes write behaviour. ERP-mastered fields are read-only beneath every agent under every key, because ownership is enforced below the model layer entirely.

Where the boundary is

We do not support arbitrary self-hosted models. Routing assumes providers with known capability and latency characteristics, and an evaluation harness that has been run against them. A model we cannot evaluate is one whose answers we cannot make any claim about, including the abstention behaviour the whole design depends on.

Per-agent model selection is also not offered, for the reason above: it produces performance that varies by question in ways no user can predict, and the support conversations that follow are unresolvable.