Keep the JDE tool architecture independent of the model.
A capability upgrade should not require a permanent commitment to one hosted model. If retrieval, identity and tool execution are cleanly separated, the same EnterpriseOne-facing architecture can support hosted frontier models or local inference.
Why local inference can matter
Some JDE workloads involve commercially sensitive transactions, internal support logs, custom code, operational procedures or documents that organisations prefer not to send to a hosted model. Local inference can also make data-residency and predictable-usage requirements easier to reason about.
That does not mean every deployment should be local. It means model location should be a deployment choice rather than the architectural centre of the solution.
Keep three layers separate
| Layer | Responsibility |
|---|---|
| Model | Language understanding, reasoning and response generation. |
| Retrieval | Controlled access to documents, metadata and contextual evidence. |
| Tools | Typed calls to approved JDE and enterprise capabilities. |
When those layers are separate, changing the model does not require reauthoring the JDE action layer. The same Orchestration or MCP tool remains the same business capability.
Local does not automatically mean secure
Running a model on-premises removes one class of data movement. It does not solve permissions, prompt injection, tool overreach or service-account sprawl. The model still needs a controlled path to retrieval and actions.
Use local models for privacy or deployment reasons; use identity and policy controls for authority.
A practical mixed model
An organisation can use a local model for sensitive internal analysis and a hosted model for general reasoning, while keeping the same MCP and Orchestration surfaces beneath both. BrainStorm's model choice and local deployment options are intended to support that separation.