Insider One’s AI capabilities run on a routed, multi-provider architecture behind a single internal gateway, Minerva. This article covers where Minerva and its underlying model providers are hosted, how customer configuration and data are scoped on shared serving infrastructure, and how AI/ADM (automated decision-making) involvement in customer interactions can be surfaced on request.
This article covers the answers to the questions below:
Routed multi-provider architecture
Rather than calling model providers directly from individual product features, Insider One centralizes all partner-facing AI behind Minerva, which routes requests to a pool of underlying providers. This includes conversational agents, content and copy generation, recommendation scoring, and other AI-assisted workflows across the platform.
Routing everything through one gateway means that hosting location, provider selection, and tenant scoping can be reasoned about and audited in one place, rather than getting a different answer for each AI feature.
Layer | Role |
|---|---|
Minerva | Internal gateway for all partner-facing AI; routes requests to the appropriate provider in the pool. |
Provider pool | OpenAI, Azure OpenAI, Anthropic, Google, and Amazon Bedrock. |
AI application layer | Hosted in AWS eu-west-1. |
Bedrock inference | Routed through AWS eu-west-1, where Bedrock is the serving provider. |
Because every partner-facing AI request passes through Minerva instead of calling a provider directly from product code, hosting location, provider choice, and governance controls can be audited in one place rather than feature by feature.
Shared serving, scoped configuration
Model serving runs through a gateway and provider catalog shared across customers, rather than a dedicated model deployment per customer. What is dedicated is the configuration and supporting data layered on top of that shared serving infrastructure, scoped by:
Partner name: The identifier tying configuration and data to a specific customer account.
Agent: The specific AI agent or feature instance (for example, a support agent or shopping agent) configured for that customer.
Knowledge base: The customer-specific content and data the agent draws on, kept separate from other customers’ knowledge bases.
The model serving and supporting infrastructure is shared, not physically dedicated to each customer. If a requirement calls for fully dedicated models and data stores rather than scoped configuration on shared infrastructure, flag it and discuss it directly; the scoping model above is a strong tenant-isolation control, but it is a different architecture from dedicated hosting.
ADM / AI transparency
Where a customer needs to know which of their customer interactions involved automated decision-making (ADM) or AI, or needs to support a request for human review of an AI-driven outcome, the Insider One product team can provide this information on request, drawing on the underlying agent configuration, knowledge base, and decisioning logic for the relevant AI feature.
This support is available today on a requested basis, not through a self-serve inventory or log that a customer’s own compliance team can query directly. A standing inventory of ADM/AI models with purpose, inputs, and decision impact, generated and maintained without a request to the product team, is not yet a native, self-serve capability.
Data use in model training
Customer data processed by Insider One’s AI features is not used to train the underlying foundation models in Minerva’s provider pool. A customer’s data informs the responses generated by that customer’s configured agents and knowledge base, but it does not feed back into the shared underlying models used across the provider pool.