Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mindset.ai/llms.txt

Use this file to discover all available pages before exploring further.

Mindset AI sits on top of your infrastructure, not inside it. Your MCP servers are the integration boundary — they receive structured requests from Mindset AI and query Snowflake on your behalf. Tenant isolation is enforced at the request level via the Context API. Business logic lives in two places: inside your MCP tools (the SQL and scoping rules) and in the agent configuration (domain vocabulary and orchestration rules). Getting both right determines agent accuracy. Your existing Snowflake RBAC, row-level security, and column masking apply unchanged throughout.

​
Three-layer architecture

Every Snowflake integration follows this pattern. Mindset AI handles the agentic experience. Your infrastructure handles data access. Snowflake stores the data and enforces governance. Three-layer architecture diagram Layer 1 — Mindset AI platform. The agent runtime, tool registry, and session management. This is where intent resolution, tool orchestration, and response generation happen. You configure agents here but don’t write data-access code at this layer. Layer 2 — your infrastructure. Your MCP servers, business logic, authentication, and any existing APIs. This is the layer you build and control. MCP servers receive structured JSON-RPC calls from Mindset AI and translate them into Snowflake queries. Credentials, SQL, and scoping logic all live here. Layer 3 — Snowflake. Your tables, views, row-level security policies, RBAC roles, and Cortex models. Nothing changes in how you’ve configured Snowflake. Your MCP servers query it the same way your application already does. The key boundary: Mindset AI talks to your MCP servers over JSON-RPC. Your MCP servers talk to Snowflake over SQL or the Snowflake SDK. Mindset AI never connects to Snowflake directly.

​
Data flow: a single request end to end

Here’s what actually happens when a user sends a message that needs Snowflake data. Data flow diagram
  1. User sends a message in your product’s interface.
  2. Mindset AI attaches tenant ID and user context via the Context API. This happens on every request, no exceptions.
  3. The agent resolves intent against registered tools. It decides which MCP tool to call based on tool descriptions and the user’s message.
  4. Mindset AI calls your MCP server with structured parameters — tenant ID, the specific query parameters, and any context needed.
  5. Your MCP server executes SQL against Snowflake, applying RBAC, row-level security, and any application-level scoping.
  6. Your MCP server returns filtered JSON results to Mindset AI. Only the data the user should see crosses the boundary.
  7. The agent generates a response and renders any widgets or visualisations.
Snowflake credentials, raw SQL, and unfiltered data never cross the security boundary. Mindset AI only ever sees structured parameters going in and filtered JSON coming back.

​
Tenant isolation

Mindset AI is built for B2B SaaS products serving multiple customers from a single deployment. Tenant isolation is enforced at the request level, not the infrastructure level. Tenant isolation diagram Every request carries a tenant ID via the Context API. It is not stored globally, not inferred, and not optional. Your MCP server receives the tenant ID as a parameter and applies your own scoping logic against Snowflake. How you filter data per customer is your decision — whether that’s Snowflake row-level security, application-level WHERE clauses, or both. Agent sessions are isolated per tenant. Conversation history, memory, and context never cross boundaries. One customer’s session cannot access another’s data or conversation state. One deployment serves all your customers. You do not need separate Snowflake schemas or separate infrastructure per tenant. Your existing Snowflake RBAC applies unchanged. Mindset AI does not bypass or replicate your security policies. Row-level security, role-based access, and column masking continue to work exactly as configured.

​
Where business logic lives

A common misconception is that business logic sits in Snowflake tables. In practice, it lives in two places, and getting both right determines whether your agents are accurate or unreliable.

​
Inside your MCP tools (query-level logic)

This is logic encoded in the SQL your MCP tools run against Snowflake: Calculation definitions. “How we calculate churn” — the specific SQL that defines what churn means for your product. For Cortex users, this is the set of approved queries you provide as a RAG basis. Scoping rules. “Never query March 2024 because the data was corrupted.” “Only pull from these tables for this tenant.” “Exclude test accounts.” Data validation. Transforming and validating Snowflake query results before returning them.
The narrower the tool, the higher the accuracy. A tool that only pulls available departments for a given hospital has almost no failure modes. A general-purpose “query anything against Snowflake” tool will fail regularly. Each tool should do one thing against one well-defined subset of your Snowflake data.

​
In the agent configuration (semantic-level logic)

This is logic that sits above the database — business terminology and orchestration rules: Domain vocabulary. When a user asks “which workflow is performing best,” the agent needs to know what “workflow” means in your product’s context. That’s not a Snowflake query — it’s business terminology injected into the system prompt. Tool descriptions. Tell the agent when to call each Snowflake-backed tool, in what sequence, and what the parameters mean. A well-written tool description is the difference between the agent calling the right Snowflake query and the wrong one. Orchestration rules. Which tools to call first, what data to gather from Snowflake before making a decision, what fallback behaviour looks like.

​
Security and data governance

Security boundary diagram Zero direct Snowflake access. Mindset AI calls your MCP servers, never your Snowflake instance. Credentials stay in your infrastructure. Connection strings, Snowflake API keys, and raw SQL never leave your environment. Your Snowflake governance applies unchanged. RBAC, row-level security, column masking, and access control policies continue to work exactly as configured. Multi-tenant isolation at the request level. Tenant context is explicit on every request. No shared state, no cross-tenant data leakage. Regional deployment. EU or US deployment available. All data processing within your chosen region. Certifications. SOC 2 Type II certified. GDPR and EU AI Act compliant. Open protocol, zero lock-in. MCP is JSON-RPC. No proprietary SDK. Everything you build on your Snowflake data is portable.