diff --git a/.cursor/rules/namings-rule.mdc b/.cursor/rules/namings-rule.mdc index 1eefc50ed014d..e16d25a45b9b9 100644 --- a/.cursor/rules/namings-rule.mdc +++ b/.cursor/rules/namings-rule.mdc @@ -21,6 +21,9 @@ Make sure to use correct terms. - **Account** - **Deployment** + - **Agent** (one per deployment by default; multi-agent is also supported) + - Rules + - Certified queries - **Analytics Chat** - **Workbook** - Tab @@ -90,3 +93,19 @@ Page naming inside the **Iframe embedding** group: - Use **Dashboards**, **Analytics Chat**, **Creator Mode** (not "Embed a dashboard", "Embed Analytics Chat", etc.) - Use **Private embedding**, **Signed embedding** for the auth-mode pages (the word "embedding" is part of the product term itself). +# Agent Terminology + +Every [Deployment](#product-taxonomy) ships with **one agent** by default. The agent powers AI features (Analytics Chat, ad-hoc queries, etc.) and is configured per-deployment with rules, certified queries, and other customizations. Multi-agent (multiple agents per deployment) is also supported, but the documentation primarily covers the default single-agent setup; multi-agent docs will follow. + +## Naming + +- **the agent** — default term in single-agent contexts. No qualifier needed because every deployment has exactly one by default. Example: "configure rules for the agent", "add a certified query to the agent". +- **Cube agent** — use only when referring to the agent feature in the abstract (product-level), not a specific instance. Example: "Cube agent supports certified queries." +- **Avoid "default agent"** — it implies non-default agents exist. Reserve this term for multi-agent docs where it contrasts with custom-created agents. +- **Avoid "deployment agent"** — wordy and doesn't add useful contrast in multi-agent contexts. + +## In multi-agent contexts + +- Refer to specific agents by their user-given names. +- Use **default agent** to contrast against user-created agents within a deployment. +- Continue to use **Cube agent** for product-level / abstract references. diff --git a/docs-mintlify/admin/ai/agent-rules.mdx b/docs-mintlify/admin/ai/agent-rules.mdx deleted file mode 100644 index 182d85cbbc393..0000000000000 --- a/docs-mintlify/admin/ai/agent-rules.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: Agent Rules -description: _Understanding Agent Rules configuration and behavior in Cube._ ---- - -Agent Rules in Cube provide a powerful way to customize and control how AI agents behave within specific spaces. Rules act as contextual instructions that guide agents' responses and analysis, ensuring consistent behavior aligned with your business logic and domain expertise. - -## Rule Types - -### Always Rules - -**Always Rules** are automatically applied to every agent interaction within the space, regardless of the specific query or context. - -**Use Cases:** -- Fundamental business definitions and context -- Consistent calculation methods -- Default analysis approaches -- Domain-specific terminology - -**Example Always Rules:** -```text -Sales efficiency is deal size divided by sales cycle length -``` - -```text -When analyzing customer data, always consider seasonality patterns from our retail business -``` - -```text -Revenue should be calculated using our standard GAAP accounting principles -``` - -### Agent Requested Rules - -**Agent Requested** rules are conditionally applied when the agent determines they are relevant to the current query or analysis. The agent intelligently selects which rules to use based on the context. - -**Use Cases:** -- Specialized analysis techniques -- Context-specific guidance -- Advanced calculation methods -- Scenario-specific instructions - -**Example Agent Requested Rules:** -```text -If you asked to analyze sales efficiency start with correlation to WSE -``` - -```text -For customer segmentation analysis, use RFM methodology (Recency, Frequency, Monetary) -``` - -```text -When analyzing marketing performance, compare against industry benchmarks where available -``` - -## Best Practices - -### Rule Hierarchy and Organization - -- **Start with Always rules** for fundamental business context -- **Use Agent Requested rules** for specialized scenarios -- **Keep rules specific and actionable** rather than vague -- **Test rules** with actual queries to ensure they work as expected - -### Writing Effective Rules - -✅ **Good Rule Examples:** -- "Customer churn rate should be calculated as customers lost / total customers at start of period" -- "When analyzing quarterly performance, always compare against same quarter previous year" -- "For financial analysis, use our fiscal year starting in October" - -❌ **Poor Rule Examples:** -- "Be helpful" (too vague) -- "Always be accurate" (redundant) -- "Consider all factors" (too broad) - -### Domain-Specific Rules - -**E-commerce Example:** -```text -Always Rule: "Customer lifetime value equals average order value × purchase frequency × customer lifespan" -Agent Requested: "For cart abandonment analysis, segment by device type and traffic source" -``` - -**SaaS Example:** -```text -Always Rule: "MRR growth rate should exclude one-time charges and setup fees" -Agent Requested: "When analyzing churn, differentiate between voluntary and involuntary churn" -``` - -### Contextual Guidance - -Rules should provide context that agents might not inherently understand about your business: - -```text -Always Rule: "Our peak season is Q4, with 40% of annual revenue typically occurring in December" -Agent Requested: "For inventory analysis, consider our 6-week lead time for international suppliers" -``` - -## Rule Conflicts and Resolution - -### How Cube Handles Conflicting Rules - -Based on the rule configuration system, when multiple rules could apply to the same query, the conflict resolution strategy would likely include: - -1. **Rule type hierarchy** (specific behavior needs verification) -2. **Rule specificity** - more specific rules typically override general ones -3. **Rule order** - the system may consider rule creation order or explicit priority -4. **Agent decision-making** for complementary vs conflicting guidance - -### Example Conflict Scenarios - -**Scenario 1: Direct Contradiction** -```text -Rule A (Always): "Revenue recognition follows monthly billing cycles" -Rule B (Always): "Revenue should be recognized quarterly" - -Resolution: The agent will flag this conflict and may ask for clarification -``` - -**Scenario 2: Complementary Rules** -```text -Rule A (Always): "Sales efficiency is deal size divided by sales cycle length" -Rule B (Agent Requested): "When analyzing sales efficiency, include pipeline velocity metrics" - -Resolution: Both rules work together - B provides additional context to A -``` - -**Scenario 3: Specificity Override** -```text -Rule A (Always): "Use standard deviation for all variance calculations" -Rule B (Agent Requested): "For customer behavior analysis, use median absolute deviation instead of standard deviation" - -Resolution: Rule B takes precedence for customer behavior queries due to higher specificity -``` - -### Best Practices for Avoiding Conflicts - -1. **Review existing rules** before adding new ones -2. **Use specific triggers** in Agent Requested rules -3. **Test rule combinations** with sample queries -4. **Document rule intentions** clearly -5. **Regular rule audits** to identify and resolve conflicts - -## Current Limitations - -### Current State: Space-Level Rules Only, Always Rules Only - -- Rules are currently configured at the **Space level** -- All agents within a space inherit the same set of rules -- Individual agent customization is not yet available - -## Getting Started - -1. **Assess Your Use Case**: Identify the key business context and calculations your agents need to understand -2. **Start Simple**: Begin with 2-3 Always rules covering your most important business definitions -3. **Add Specificity**: Implement Agent Requested rules for specialized scenarios -4. **Test and Iterate**: Use real queries to validate rule effectiveness -5. **Scale Gradually**: Add more rules based on actual usage patterns and feedback diff --git a/docs-mintlify/admin/ai/certified-queries.mdx b/docs-mintlify/admin/ai/certified-queries.mdx new file mode 100644 index 0000000000000..29eeea85ef003 --- /dev/null +++ b/docs-mintlify/admin/ai/certified-queries.mdx @@ -0,0 +1,81 @@ +--- +title: Certified queries +description: Provide a library of trusted SQL queries that the agent uses as reference examples when answering user requests. +--- + +Certified queries are pre-approved SQL queries that the agent treats as a **library of trusted examples**. They guide the agent toward correct business logic and well-formed query patterns without restricting it to a fixed set of queries. + +Certified queries are configured as code in your [data model repository](/admin/ai#agent-configuration), alongside your cubes and views. + + +The agent is not limited to running only certified queries. When answering a user request, the agent may: + +- Use a certified query directly if it matches the request +- Use a certified query as a **starting point** and adapt it (e.g., add filters, dimensions, or measures) to fit the user's question +- Generate a new query independently if no certified query is relevant + +Certified queries help the agent toward trusted patterns and correct business logic, but the agent retains full flexibility to construct the query that best answers each question. + + +## Defining certified queries + +Certified queries are defined as Markdown files under `agents/certified_queries/`. Each query lives in its own file: the YAML frontmatter holds metadata, and the Markdown body is the SQL query. + +```markdown + +--- +description: "Get revenue by fiscal quarter" +user_request: "What is the revenue by quarter?" +--- +SELECT + DATE_TRUNC('quarter', order_date) AS quarter, + SUM(amount) AS revenue +FROM orders +WHERE status != 'cancelled' +GROUP BY 1 +ORDER BY 1 +``` + +Files placed under a `certified_queries/`, `certified-queries/`, or `queries/` directory are treated as certified queries automatically — no `kind` property is required. The `name` is inferred from the file name (e.g., `quarterly-revenue.md` → `quarterly-revenue`). + +### Frontmatter properties + +| Property | Type | Required | Description | +|-----------------|--------|:--------:|--------------------------------------------------------------------------------------| +| `name` | string | No | Unique identifier. Inferred from the file name if omitted. | +| `description` | string | No | Human-readable description. | +| `user_request` | string | Yes | The user request pattern this query answers. | +| `sql_query` | string | No | The SQL query. Falls back to the Markdown body if omitted. | + +### Inlining certified queries in YAML + +You can also inline certified queries directly in `agents/config.yml` under a `certified_queries` key: + +```yaml +# agents/config.yml +certified_queries: + - name: total-revenue + description: "Calculate total revenue" + user_request: "What is the total revenue?" + sql_query: "SELECT SUM(amount) AS total_revenue FROM orders WHERE status = 'completed'" + + - name: monthly-sales + description: "Monthly sales breakdown" + user_request: "Show me sales by month" + sql_query: | + SELECT + DATE_TRUNC('month', order_date) AS month, + SUM(amount) AS total_sales + FROM orders + GROUP BY 1 + ORDER BY 1 +``` + +Inline certified queries accept the same properties as Markdown ones — `name`, `description`, `user_request` (required), and `sql_query` (required). + +## Writing effective certified queries + +- **Phrase `user_request` like a real user question.** This is what the agent matches against incoming requests. +- **Keep queries focused.** A certified query should answer one well-defined question; the agent will adapt it for variations. +- **Use canonical business logic.** Certified queries are the reference for "the right way" to compute something — encode the definitions you want the agent to follow. +- **Cover common patterns first.** Start with the questions users ask most often, and grow the library based on usage. diff --git a/docs-mintlify/admin/ai/index.mdx b/docs-mintlify/admin/ai/index.mdx index edf89f5288d55..23ab83a7fcb69 100644 --- a/docs-mintlify/admin/ai/index.mdx +++ b/docs-mintlify/admin/ai/index.mdx @@ -1,19 +1,141 @@ --- -description: Configure and manage AI-powered features in Cube Cloud, including spaces, agents, models, and memory isolation. +description: Configure the agent that ships with every Cube deployment — accessible views, LLM, runtime, and memory. title: Overview --- -AI tools help you configure and manage AI-powered features in Cube Cloud. +Every Cube deployment ships with an agent that powers AI features such as [Analytics Chat](/docs/explore-analyze/analytics-chat). You can customize the agent's behavior with rules, certified queries, accessible views, model selection, and memory configuration. +## Agent configuration -## AI tools +Agent configuration lives in your **Cube data model repository**, alongside your cubes and views. Configuration is defined as YAML and Markdown files under an `agents/` directory in your project: -Configure AI features to: +```text +your-cube-project/ +├── model/ +│ └── cubes/ +│ └── orders.yml +├── agents/ +│ ├── config.yml # Agent configuration +│ ├── rules/ # Rules as Markdown +│ │ └── fiscal-year.md +│ └── certified_queries/ # Certified queries as Markdown +│ └── quarterly-revenue.md +└── cube.py +``` -- Set up [spaces, agents, and models][ref-spaces] for your AI-powered applications -- Define [agent rules][ref-rules] to control agent behavior -- Manage [agent memories][ref-memories] for context persistence +Storing configuration as code in your repository enables version control, code review, and consistent behavior across environments. -[ref-spaces]: /admin/ai/spaces-agents-models -[ref-rules]: /admin/ai/agent-rules -[ref-memories]: /admin/ai/memory-isolation \ No newline at end of file + + Cube version 1.6.5 or above is required. Agent configuration is enabled by setting `CUBE_CLOUD_AGENTS_CONFIG_ENABLED=true`. The directory path defaults to `agents` and can be overridden with `CUBE_CLOUD_AGENTS_CONFIG_PATH`. + + +## Configure the agent + +Place agent properties at the root of `agents/config.yml`: + +```yaml +# agents/config.yml +llm: claude_4_sonnet +runtime: plain +accessible_views: + - orders_view + - customers_view +memory_mode: user +``` + +### Properties + +| Property | Type | Default | Description | +|---------------------|------------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------| +| `llm` | string or object | `auto` | LLM provider — `auto`, a [predefined model](#llm) name, or a [BYOM](/admin/ai/bring-your-own-model) reference. | +| `embedding_llm` | string or object | `text-embedding-3-large` | Embedding model — a predefined name or a BYOM reference. | +| `runtime` | string | `plain` | [Runtime mode](#runtime) — `plain` or `reasoning`. | +| `accessible_views` | array | _all views_ | List of view names the agent is allowed to query. If omitted or empty, the agent has access to all views. | +| `memory_mode` | string | `space` | [Memory isolation mode](#memory) — `space`, `user`, or `disabled`. | + +Rules and certified queries have their own dedicated pages: + +- [Rules](/admin/ai/rules) — instructions that guide the agent's behavior +- [Certified queries](/admin/ai/certified-queries) — a library of trusted SQL examples for the agent + +## LLM + +The default value is `auto` — Cube picks a recommended model on your behalf and may change it as better models become available. Use `auto` unless you have a reason to pin a specific model. + +To pin a specific model, set the `llm` property to one of the predefined models: + +**Anthropic Claude:** +- `claude_3_5_sonnetv2` +- `claude_3_7_sonnet` +- `claude_3_7_sonnet_thinking` +- `claude_4_sonnet` +- `claude_4_5_sonnet` +- `claude_4_5_haiku` +- `claude_4_5_opus` +- `claude_4_6_sonnet` +- `claude_4_6_opus` +- `claude_4_7_opus` + +**OpenAI GPT:** +- `gpt_4o` +- `gpt_4_1` +- `gpt_4_1_mini` +- `gpt_5` +- `gpt_5_mini` +- `gpt_5_3` +- `gpt_5_4` +- `o3` +- `o4_mini` + +To use your own model, see [Bring your own model](/admin/ai/bring-your-own-model). + +### Embedding models + +Predefined embedding models for the `embedding_llm` property: + +- `text-embedding-3-large` +- `text-embedding-3-small` + +BYOM is also supported for embedding models. + +## Runtime + +The `runtime` property controls how the agent processes requests: + +| Mode | Description | +|--------------|--------------------------------------------------------------------------------------------| +| `plain` | Default. Optimized for speed and cost. Recommended for most use cases. | +| `reasoning` | Enables extended thinking for complex analysis. | + + + `reasoning` is **experimental**. It may be unstable and is not yet feature-complete. Stick with `plain` unless you have a specific need for extended reasoning. + + +## Memory + +The `memory_mode` property controls how the agent persists context across conversations: + +| Mode | Description | +|-------------|----------------------------------------------------------------------------------------------| +| `space` | Default. Memories are shared across all users — useful when the agent serves a single team. | +| `user` | Memories are isolated per user — useful when each user has private context. | +| `disabled` | The agent does not persist memory between conversations. | + +See [Memories](/admin/ai/memory-isolation) for details on how memories are stored and used. + +## Customize the agent + + + + Define instructions that guide how the agent responds and analyzes data. + + + Provide a library of trusted SQL queries for the agent to reference. + + + Configure the agent to use your own LLM provider or model. + + + Control how the agent persists context across conversations and users. + + diff --git a/docs-mintlify/admin/ai/memory-isolation.mdx b/docs-mintlify/admin/ai/memory-isolation.mdx index 59b383a374f48..04b6a8c6345bb 100644 --- a/docs-mintlify/admin/ai/memory-isolation.mdx +++ b/docs-mintlify/admin/ai/memory-isolation.mdx @@ -1,6 +1,6 @@ --- -title: Agent Memories -description: _Learn how Cube enforces memory isolation across tenants, spaces, and users._ +title: Memories +description: How the agent stores, retrieves, and isolates memories across tenants, spaces, and users. --- Memory in Cube allows Agents to learn from and recall past interactions, user preferences, and contextual information. When users interact with Agents, relevant information is stored as memories that can be retrieved in future conversations, enabling more personalized and context-aware responses. Memories help Agents understand user preferences, remember previous decisions, and provide continuity across sessions. diff --git a/docs-mintlify/admin/ai/multi-agent.mdx b/docs-mintlify/admin/ai/multi-agent.mdx new file mode 100644 index 0000000000000..8c2254e849eeb --- /dev/null +++ b/docs-mintlify/admin/ai/multi-agent.mdx @@ -0,0 +1,189 @@ +--- +title: Multi-agent +description: Configure multiple agents within a single deployment, each with its own model, accessible views, rules, and certified queries. +--- + +Every Cube deployment ships with a single agent by default — see the [Overview](/admin/ai) for the standard configuration. For more advanced setups, you can configure **multiple agents** within the same deployment, each with its own model, accessible views, rules, and certified queries. + +Multi-agent is useful when: + +- Different teams need agents tuned to their own domain (e.g., a Sales Assistant and a Marketing Analyst). +- You want specialized agents with distinct instructions or tool access in the same deployment. +- You need to isolate context (rules, certified queries, memories) between user groups. + + + Spaces and agents must first be created through the Cube Cloud UI before they can be configured via YAML. The system matches YAML entries to UI-created spaces and agents by their `name` field. + + +## Architecture + +A multi-agent setup introduces one new concept on top of the single-agent model: **spaces**. + +- A **deployment** can contain one or more **spaces**. +- A **space** is an isolated context. It owns its **rules**, **certified queries**, and **memories** — they are not shared across spaces. +- Each **agent** belongs to exactly one space and inherits everything that space owns. Multiple agents can live in the same space and share the same rules, certified queries, and memories. + +This means you choose a space's boundary based on what context should be shared. Two agents serving the same team usually live in one space; agents serving different domains (Sales vs. Marketing) live in different spaces so their context stays separate. + +```mermaid +flowchart LR + classDef deployment fill:#4f46e5,stroke:#3730a3,color:#fff + classDef space fill:#e0e7ff,stroke:#6366f1,color:#1e1b4b + classDef agent fill:#10b981,stroke:#047857,color:#fff + classDef resource fill:#fef3c7,stroke:#d97706,color:#78350f + + D[Deployment]:::deployment + + SA[Space
sales-analytics]:::space + SM[Space
marketing-analytics]:::space + + SAR[Rules]:::resource + SAC[Certified queries]:::resource + SAM[Memories]:::resource + A1[Agent
sales-assistant]:::agent + A2[Agent
sales-reporter]:::agent + + SMR[Rules]:::resource + SMC[Certified queries]:::resource + SMM[Memories]:::resource + A3[Agent
marketing-analyst]:::agent + + D --> SA + D --> SM + + SA --- SAR + SA --- SAC + SA --- SAM + SA --> A1 + SA --> A2 + + SM --- SMR + SM --- SMC + SM --- SMM + SM --> A3 +``` + +In the [single-agent setup](/admin/ai), there is an implicit `auto` space that holds all rules, certified queries, and memories — you don't need to think about it. In a multi-agent setup, you define spaces explicitly and attach rules and certified queries to specific spaces. + +## What changes from the single-agent setup + +The [`agents/` file structure](/admin/ai#agent-configuration) is the same. What's different is how `agents/config.yml` is shaped: + +1. **Agents are defined as an array.** Each agent gets a unique `name` and an optional `description`, in addition to the standard agent [properties](/admin/ai#properties) (`llm`, `runtime`, `accessible_views`, `memory_mode`, etc.). +2. **Spaces are introduced.** A `spaces` array defines the contexts agents operate in. Each space gets a unique `name`. +3. **Rules and certified queries attach to spaces.** Use the `space` property in the frontmatter of each rule or certified query Markdown file to attach it to a specific space. + + + You cannot mix flat root-level properties (the single-agent style) with `spaces` or `agents` arrays in the same file. Use one style per file. + + +## Agents + +Replace the flat root-level agent properties with an `agents` array: + +```yaml +# agents/config.yml +agents: + - name: sales-assistant # Required + description: "AI assistant for sales analytics" + space: sales-analytics # Required: reference to a space + llm: claude_4_6_sonnet + accessible_views: + - orders_view + - customers_view + memory_mode: user + + - name: marketing-analyst # Required + description: "AI assistant for marketing analytics" + space: marketing-analytics # Required + llm: gpt_5 +``` + +The properties available on each agent are the same as in the [single-agent setup](/admin/ai#properties), plus: + +| Property | Type | Required | Description | +|---------------|--------|:--------:|------------------------------------------------------------| +| `name` | string | Yes | Unique identifier for the agent. | +| `description` | string | No | Human-readable description. | +| `space` | string | Yes | Name of the [space](#spaces) this agent belongs to. | + +## Spaces + +A space is the context an agent operates in. Spaces own the rules, certified queries, and memories that the agents inside them share. Define spaces alongside agents: + +```yaml +# agents/config.yml +spaces: + - name: sales-analytics # Required + description: "Space for sales team analytics and reporting" + + - name: marketing-analytics # Required + description: "Space for marketing team analytics" +``` + +| Property | Type | Required | Description | +|---------------|--------|:--------:|--------------------------------------------| +| `name` | string | Yes | Unique identifier for the space. | +| `description` | string | No | Human-readable description. | + +Each agent must reference exactly one space via its `space` property. Multiple agents can share the same space and inherit its rules, certified queries, and memories. + +## Attaching rules and certified queries to a space + +In the single-agent setup, [rules](/admin/ai/rules) and [certified queries](/admin/ai/certified-queries) belong to the implicit `auto` space. In a multi-agent setup, you must attach each rule and certified query to a specific space using the `space` property in the Markdown frontmatter: + +```markdown + +--- +space: sales-analytics +type: always +--- +Always use fiscal year starting April 1st when analyzing dates. +``` + +```markdown + +--- +space: sales-analytics +description: "Apply when the user asks about quarterly revenue" +user_request: "What is the revenue by quarter?" +--- +SELECT + DATE_TRUNC('quarter', order_date) AS quarter, + SUM(amount) AS revenue +FROM orders +WHERE status != 'cancelled' +GROUP BY 1 +ORDER BY 1 +``` + +You can also organize rules and certified queries into space-named subdirectories. Files placed under `agents/rules//` or `agents/certified_queries//` are attached to that space automatically — no `space` frontmatter required. + +## Complete example + +```yaml +# agents/config.yml +spaces: + - name: sales-analytics + description: "Space for sales team analytics and reporting" + + - name: marketing-analytics + description: "Space for marketing team analytics" + +agents: + - name: sales-assistant + description: "AI assistant for sales analytics and reporting" + space: sales-analytics + llm: claude_4_6_sonnet + accessible_views: + - orders_view + - customers_view + - products_view + memory_mode: user + + - name: marketing-analyst + description: "AI assistant for marketing analytics" + space: marketing-analytics + llm: gpt_5 + memory_mode: user +``` diff --git a/docs-mintlify/admin/ai/rules.mdx b/docs-mintlify/admin/ai/rules.mdx new file mode 100644 index 0000000000000..b2515fe0bce43 --- /dev/null +++ b/docs-mintlify/admin/ai/rules.mdx @@ -0,0 +1,136 @@ +--- +title: Rules +description: Define instructions in your data model repository that guide the agent's behavior. +--- + +Rules are instructions that guide the agent's behavior — encoding business definitions, calculation methods, domain terminology, and analytical approaches the agent should follow when answering questions. + +Rules are configured as code in your [data model repository](/admin/ai#agent-configuration), alongside your cubes and views. This enables version control, code review, and consistent behavior across environments. + +## Rule types + +| Type | When applied | Best for | +|-------------------|-----------------------------------------------------------------------------------------------|------------------------------------------------------------------------| +| `always` | Injected into every agent interaction. | Fundamental business definitions, default calculations, domain terms. | +| `agent_requested` | Conditionally applied when the agent determines the rule is relevant to the current request. | Scenario-specific guidance, specialized analysis methods. | + +For `agent_requested` rules, the `description` field is what the agent matches against the user's request to decide whether the rule is relevant — write it as a short summary of when this rule applies. `always` rules don't need a `description` since they're injected into every interaction regardless. + +## Defining rules + +Rules are defined as Markdown files under `agents/rules/`. Each rule lives in its own file: the YAML frontmatter holds metadata, and the Markdown body is the rule prompt. + +```markdown + +--- +type: always +--- +Always use fiscal year starting April 1st when analyzing dates. +Q1 is April–June, Q2 is July–September, Q3 is October–December, Q4 is January–March. +``` + +For `agent_requested` rules, add a `description` so the agent can decide when the rule applies: + +```markdown + +--- +description: "Apply when the user asks about cart abandonment" +type: agent_requested +--- +For cart abandonment analysis, segment by device type and traffic source. +``` + +Files placed under a `rules/` directory are treated as rules automatically — no `kind` property is required. The `name` is inferred from the file name (e.g., `fiscal-year.md` → `fiscal-year`). + +### Frontmatter properties + +| Property | Type | Required | Description | +|---------------|--------|:--------:|----------------------------------------------------------------------------------------------------------------------------------| +| `name` | string | No | Unique identifier. Inferred from the file name if omitted. | +| `description` | string | No | Required for `agent_requested` rules — used by the agent to decide when the rule applies. Optional and unused for `always` rules. | +| `type` | string | Yes | Either `always` or `agent_requested`. | +| `prompt` | string | No | Rule prompt. Falls back to the Markdown body if omitted. | + +### Inlining rules in YAML + +You can also inline rules directly in `agents/config.yml` under a `rules` key: + +```yaml +# agents/config.yml +rules: + - name: fiscal-year + prompt: "Always use fiscal year starting April 1st when analyzing dates." + type: always + + - name: efficiency-analysis + description: "Apply when the user asks about sales efficiency" + prompt: "When analyzing sales efficiency, calculate as deal size divided by sales cycle length." + type: agent_requested +``` + +Inline rules accept the same properties as Markdown rules — `name`, `description`, `prompt` (required), and `type` (required). + +## Writing effective rules + +Good rules are specific, actionable, and encode context the agent wouldn't otherwise know about your business. + +**Do:** +- "Customer churn rate is customers lost ÷ total customers at the start of the period." +- "When analyzing quarterly performance, always compare against the same quarter of the previous year." +- "Our fiscal year starts in October." + +**Don't:** +- "Be helpful." (too vague) +- "Always be accurate." (redundant) +- "Consider all factors." (too broad) + +### Domain examples + +**E-commerce:** + +```markdown + +--- +type: always +--- +Customer lifetime value equals average order value × purchase frequency × customer lifespan. +``` + +```markdown + +--- +description: "Apply when the user asks about cart abandonment" +type: agent_requested +--- +For cart abandonment analysis, segment by device type and traffic source. +``` + +**SaaS:** + +```markdown + +--- +type: always +--- +MRR growth rate excludes one-time charges and setup fees. +``` + +```markdown + +--- +description: "Apply when the user asks about churn analysis" +type: agent_requested +--- +When analyzing churn, distinguish between voluntary and involuntary churn. +``` + +## Resolving conflicts + +When multiple rules could apply, follow these guidelines: + +1. **Review existing rules** before adding new ones to avoid contradictions. +2. **Use specific triggers** in `agent_requested` rules so the agent knows when each rule applies. +3. **Prefer specificity over breadth** — narrowly scoped rules override broader defaults more cleanly. +4. **Test rule combinations** with sample queries before relying on them. + +If two `always` rules directly contradict each other, the agent will surface the conflict in its response. Resolve such conflicts by editing the rules in your repository and redeploying. diff --git a/docs-mintlify/admin/ai/spaces-agents-models.mdx b/docs-mintlify/admin/ai/spaces-agents-models.mdx deleted file mode 100644 index 2ce72d5979e34..0000000000000 --- a/docs-mintlify/admin/ai/spaces-agents-models.mdx +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Spaces, agents, models -description: _Understanding the core concepts of Spaces, Agents, and Models in Cube._ ---- - -Cube is an agentic analytics platform that combines AI agents with semantic data modeling to create intelligent, automated analytics experiences. This guide explains the three fundamental concepts that form the foundation of Cube: **Spaces**, **Agents**, and **Models**. - -## Core Concepts - -### 1. **Spaces** (Agent Spaces) - -**Agent Spaces** are isolated environments where AI agents operate and share context, rules, and [memories][ref-agent-memories]. Think of them as "workspaces" or "projects" that contain everything an agent needs to work effectively. - -#### Key Characteristics: - -- **Isolation**: Each space is completely isolated from others -- **Shared Context**: Agents within a space share rules, memories, and configurations -- **Ownership**: Spaces can be owned by users or shared across teams -- **Configuration**: Each space has its own settings and behavior rules - -#### What Lives in a Space: - -- **Agent Rules**: Instructions that guide how agents behave -- **Memories**: Shared knowledge and past interactions -- **Certified Queries**: Pre-approved, trusted queries provided as an example library the agent can reference, adapt, or extend (agents aren't restricted to using only certified queries) -- **Context**: Business logic and domain expertise - -#### Example Use Cases: - -- **Sales Analytics Space**: Contains sales-specific rules, KPIs, and historical analysis -- **Marketing Space**: Focused on campaign performance, customer segmentation -- **Finance Space**: Revenue analysis, budgeting, and financial reporting - -### 2. **Agents** (AI Agents) - -**Agents** are AI-powered assistants that can understand natural language, execute complex tasks, and interact with your data models. They're the "workers" that operate within spaces to help users achieve their analytics goals. - -#### Key Characteristics: - -- **Intelligent**: Can understand context and make decisions -- **Tool-Enabled**: Have access to various tools for data manipulation -- **Memory-Aware**: Can learn from past interactions -- **Specialized**: Can be configured for specific tasks or domains - -#### Agent Capabilities: - -- **Data Analysis**: Query and analyze data using natural language -- **Model Building**: Create and modify semantic models -- **Report Generation**: Build charts, dashboards, and reports -- **Code Generation**: Write and modify Cube model files -- **Workflow Automation**: Execute multi-step analytical processes - -#### Memory Modes: - -- **User Mode**: Memories are isolated per user -- **Space Mode**: Memories are shared within the space -- **Disabled**: No memory is stored - -### 3. **Models** (LLM Models) - -**LLM Models** (Large Language Models) are the AI engines that power the agents in Cube. They provide the natural language understanding, reasoning, and generation capabilities that make agents intelligent and conversational. - -## How They Work Together - -### The Cube Workflow: - -1. **Setup**: Create a space and configure [agent rules][ref-agent-rules] -2. **Deploy**: Connect your data source and build semantic models -3. **Configure**: Select appropriate LLM models for your agents -4. **Interact**: Users and agents query data using natural language -5. **Learn**: Agents build memories and improve over time -6. **Automate**: Agents can execute complex workflows independently - -### Example Interaction: - -```text -User: "Show me sales performance by region for Q4" - -Agent: -1. Understands the request (sales, region, Q4) -2. Queries the semantic model for relevant data -3. Applies business rules from the space -4. Generates a chart or report -5. Stores the interaction in memory for future reference -``` - -### Space-Agent-Model Relationship: - -```text -Space (Sales Analytics) -├── Rules: "Revenue = quantity × price" -├── Memories: Past Q4 analyses -├── Agents: -│ ├── Sales Analyst Agent (Claude 3.5 Sonnet v2) -│ └── Report Builder Agent (GPT-4o) -└── LLM Models: - ├── Claude 3.5 Sonnet v2 (Analytical reasoning) - ├── Claude 3.7 Sonnet Thinking (Complex analysis) - └── GPT-4o (Code generation) -``` - - -[ref-agent-memories]: /docs/agentic-analytics/memory-isolation -[ref-agent-rules]: /docs/agentic-analytics/agent-rules \ No newline at end of file diff --git a/docs-mintlify/admin/ai/yaml-config.mdx b/docs-mintlify/admin/ai/yaml-config.mdx deleted file mode 100644 index ba0c50e0b648c..0000000000000 --- a/docs-mintlify/admin/ai/yaml-config.mdx +++ /dev/null @@ -1,629 +0,0 @@ ---- -title: YAML Agent Configuration -description: Define and manage AI agents, spaces, rules, and certified queries as code using YAML and Markdown files. ---- - - - -This feature is available by request only. Please contact your Cube representative to enable YAML agent configuration for your deployment. - - - -YAML Agent Configuration allows you to define and manage your AI agents, spaces, rules, and certified queries as code. This approach enables version control, code review workflows, and programmatic management of your agent configuration. - -## Overview - -Instead of configuring agents through the Cube Cloud UI, you can create YAML and Markdown files in the `agents/` directory of your Cube project. These files are automatically loaded and validated when your deployment starts. - -An `auto` space and `auto` agent are always provisioned by default, so you can get started with just a few lines of configuration. For more complex setups, you can define [multiple spaces and agents](#multiple-agents-setup). - -### Key Benefits - -- **Version Control**: Track changes to agent configuration in Git -- **Code Review**: Review agent configuration changes through pull requests -- **Infrastructure as Code**: Manage agent configuration alongside your data model -- **Multi-file Support**: Split configuration across multiple YAML and Markdown files for better organization -- **Validation**: Automatic schema validation with helpful error messages - -## UI and YAML Interplay - -Understanding how YAML configuration interacts with the Cube Cloud UI is important for effective management. - -### Configuration Override Behavior - -When YAML configuration is enabled: - -- **Rules**: Defined in YAML files or Markdown files for the corresponding space -- **Certified Queries**: When YAML config is enabled, **only YAML is used** for certified queries. UI-based certified query management is disabled to ensure a single source of truth. -- **Agent Settings**: LLM provider, runtime mode, and memory mode can be overridden via YAML - -### UI-Only Settings - -The following settings are still managed exclusively through the Cube Cloud UI: - -- **Agent Embedding**: Embedding configuration and deployment settings - -## Environment Variables - - - -Cube version 1.6.5 or above is required to enable this feature. - - - -The following environment variables control the YAML agent configuration feature: - -| Environment Variable | Description | Default | -| --- | --- | --- | -| `CUBE_CLOUD_AGENTS_CONFIG_ENABLED` | Enables YAML agent configuration. Set to `true` to activate. | `false` | -| `CUBE_CLOUD_AGENTS_CONFIG_PATH` | Path to the directory containing agent configuration files, relative to the project root. | `agents` | - -## Auto Agent Setup - -When YAML agent configuration is enabled, an `auto` space and `auto` agent are always provisioned automatically. This is the simplest way to get started — you can customize the default agent without defining any spaces or agents explicitly. - -### File Structure - -```text -your-cube-project/ -├── model/ -│ └── cubes/ -│ └── orders.yml -├── agents/ -│ ├── config.yml # Agent configuration -│ ├── rules/ -│ │ ├── fiscal-year.md # Rule as Markdown -│ │ └── revenue-definition.md -│ └── certified_queries/ -│ └── quarterly-revenue.md # Certified query as Markdown -└── cube.js -``` - -The following file types are supported: - -- **YAML** (`.yml`, `.yaml`): Define agent settings, rules, and certified queries -- **Markdown** (`.md`, `.markdown`): Define individual rules or certified queries with YAML frontmatter - -### YAML Configuration - -Place agent and space properties directly at the root of your YAML file. This configures the default `auto` agent and `auto` space: - -```yaml -# agents/config.yml -title: "Sales Assistant" -description: "AI assistant for sales analytics" -llm: claude_4_sonnet -runtime: reasoning -accessible_views: - - orders_view - - customers_view -memory_mode: user -rules: - - name: fiscal-year - prompt: "Always use fiscal year starting April 1st" - type: always -certified_queries: - - name: total-revenue - user_request: "What is the total revenue?" - sql_query: "SELECT SUM(amount) FROM orders WHERE status = 'completed'" -``` - -The flat configuration automatically creates: -- A space named `auto` with the specified `title`, `description`, `rules`, and `certified_queries` -- An agent named `auto` in that space with the specified `title`, `description`, `llm`, `embedding_llm`, `runtime`, `accessible_views`, and `memory_mode` - -The `auto` name is fixed and cannot be overridden. - -#### Properties - -| Property | Type | Applies to | Description | -| --- | --- | --- | --- | -| `title` | string | Space and Agent | Display title | -| `description` | string | Space and Agent | Human-readable description | -| `llm` | string or object | Agent | LLM provider configuration | -| `embedding_llm` | string or object | Agent | Embedding model configuration | -| `runtime` | string | Agent | Runtime mode (`plain` or `reasoning`) | -| `accessible_views` | array | Agent | List of view names the agent can access | -| `memory_mode` | string | Agent | Memory isolation mode | -| `rules` | array | Space | List of agent rules | -| `certified_queries` | array | Space | List of certified queries | - -### Markdown Files - -In addition to YAML, you can define rules and certified queries as individual Markdown files. Each file uses YAML frontmatter for metadata and the body for content. Since everything targets the `auto` space by default, you don't need to specify a `space` property. - -#### Rules as Markdown - -```markdown ---- -description: "Use fiscal year for date calculations" -type: always ---- -Always use fiscal year starting April 1st when analyzing dates. -Q1 is April-June, Q2 is July-September, Q3 is October-December, Q4 is January-March. -``` - -The Markdown body is used as the rule `prompt`. If `prompt` is specified in the frontmatter, the frontmatter value takes precedence over the body. - -#### Certified Queries as Markdown - -```markdown ---- -description: "Get revenue by fiscal quarter" -user_request: "What is the revenue by quarter?" ---- -SELECT - DATE_TRUNC('quarter', order_date) as quarter, - SUM(amount) as revenue -FROM orders -WHERE status != 'cancelled' -GROUP BY 1 -ORDER BY 1 -``` - -The Markdown body is used as the `sql_query`. If `sql_query` is specified in the frontmatter, the frontmatter value takes precedence over the body. - -#### Kind Inference - -When the `kind` property is not specified in the frontmatter, it is determined automatically: - -1. **Directory path**: Files under a `rules/` directory are treated as rules. Files under `certified_queries/`, `certified-queries/`, or `queries/` directories are treated as certified queries. -2. **Frontmatter shape**: If the frontmatter contains `type` or `prompt`, it is treated as a rule. If it contains `user_request` or `sql_query`, it is treated as a certified query. - -If kind cannot be determined from either the path or the frontmatter shape, an error is raised. - -#### Name Inference - -When the `name` property is not specified in the frontmatter, it is inferred from the file name by taking the basename without the extension. For example, `fiscal-year.md` produces the name `fiscal-year`. - -### Complete Auto Agent Example - -``` -agents/ -├── config.yml -├── rules/ -│ ├── fiscal-year.md -│ └── revenue-definition.md -└── certified_queries/ - └── quarterly-revenue.md -``` - -```yaml -# agents/config.yml -title: "Sales Assistant" -description: "AI assistant for sales analytics" -llm: claude_4_sonnet -runtime: reasoning -accessible_views: - - orders_view - - customers_view -memory_mode: user -``` - -```markdown - ---- -description: "Use fiscal year for date calculations" -type: always ---- -Always use fiscal year starting April 1st when analyzing dates. -Q1 is April-June, Q2 is July-September, Q3 is October-December, Q4 is January-March. -``` - -```markdown - ---- -description: "Standard revenue calculation" -type: always ---- -Revenue should be calculated as quantity × unit_price, excluding cancelled orders and refunds. -``` - -```markdown - ---- -description: "Get revenue by fiscal quarter" -user_request: "What is the revenue by quarter?" ---- -SELECT - CASE - WHEN MONTH(order_date) BETWEEN 4 AND 6 THEN 'Q1' - WHEN MONTH(order_date) BETWEEN 7 AND 9 THEN 'Q2' - WHEN MONTH(order_date) BETWEEN 10 AND 12 THEN 'Q3' - ELSE 'Q4' - END as fiscal_quarter, - SUM(quantity * unit_price) as revenue -FROM orders -WHERE status != 'cancelled' -GROUP BY 1 -ORDER BY 1 -``` - -## Multiple Agents Setup - -When you need multiple agents with separate spaces, you can use the explicit configuration style with `spaces` and `agents` arrays. This gives you full control over how agents, rules, and certified queries are organized. - - - -You cannot mix flat root-level properties with `spaces` or `agents` arrays in the same file. Use one style per file. - - - -### File Structure - -``` -your-cube-project/ -├── model/ -│ └── cubes/ -│ └── orders.yml -├── agents/ -│ ├── config.yml # Spaces and agents -│ ├── rules/ -│ │ └── sales/ -│ │ ├── fiscal-year.md # Rule for sales-analytics space -│ │ └── revenue-definition.md -│ └── certified_queries/ -│ └── sales/ -│ └── quarterly-revenue.md # Certified query for sales-analytics space -└── cube.js -``` - -You can also split YAML configuration across multiple files for better organization: - -``` -agents/ -├── spaces/ -│ ├── sales.yml -│ └── marketing.yml -└── agents/ - └── assistants.yml -``` - -All YAML and Markdown files are merged together. The system validates that space names and agent names are unique across all files. - -### Spaces - -Spaces define isolated environments where agents operate and share context. - - - -Spaces and agents must first be created through the Cube Cloud UI before they can be configured via YAML. A space discovers available deployments based on its assigned agents, so you must create at least one agent in the UI and assign it to the space before YAML configuration from that deployment becomes visible. When selecting a YAML-configured agent in the UI, the system matches it to the corresponding space and agent by the `name` field. - - - -```yaml -spaces: - - name: analytics-space # Required: unique identifier - title: "Analytics Space" # Optional: display name - description: "Space for analytics agents" - rules: - - # Rule definitions... - certified_queries: - - # Certified query definitions... -``` - -#### Space Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `name` | string | Yes | Unique identifier for the space | -| `title` | string | No | Display title for the space | -| `description` | string | No | Human-readable description | -| `rules` | array | No | List of agent rules | -| `certified_queries` | array | No | List of certified queries | - -### Agents - -Agents are AI-powered assistants that operate within spaces. - -```yaml -agents: - - name: sales-assistant # Required: unique identifier - title: "Sales Assistant" # Optional: display name - description: "AI assistant for sales analytics" - space: sales-space # Required: reference to a space - llm: claude_4_sonnet # Optional: LLM provider - embedding_llm: text-embedding-3-large # Optional: embedding model - runtime: reasoning # Optional: runtime mode - accessible_views: # Optional: list of accessible views - - orders_view - - customers_view - memory_mode: user # Optional: memory isolation mode -``` - -#### Agent Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `name` | string | Yes | Unique identifier for the agent | -| `title` | string | No | Display title for the agent | -| `description` | string | No | Human-readable description | -| `space` | string | Yes | Name of the space this agent belongs to | -| `llm` | string or object | No | LLM provider configuration | -| `embedding_llm` | string or object | No | Embedding model configuration | -| `runtime` | string | No | Runtime mode (`plain` or `reasoning`) | -| `accessible_views` | array | No | List of view names the agent can access | -| `memory_mode` | string | No | Memory isolation mode | - -Additional spaces and agents can also be created through the Cube Cloud UI. When your deployment starts, the system matches YAML entries to UI-created spaces and agents by their `name` field. - -### Markdown Files with Space Targeting - -When using multiple spaces, set the `space` property in your Markdown frontmatter to target the correct space. If `space` is omitted, the rule or certified query is added to the `auto` space. - -```markdown ---- -space: sales-analytics -description: "Use fiscal year for date calculations" -type: always ---- -Always use fiscal year starting April 1st when analyzing dates. -``` - -### Complete Multiple Agents Example - -``` -agents/ -├── config.yml -├── rules/ -│ ├── fiscal-year.md -│ └── revenue-definition.md -└── certified_queries/ - └── quarterly-revenue.md -``` - -```yaml -# agents/config.yml -spaces: - - name: sales-analytics - title: "Sales Analytics" - description: "Space for sales team analytics and reporting" - rules: - - name: efficiency-analysis - description: "Sales efficiency methodology" - prompt: "When analyzing sales efficiency, calculate as deal size divided by sales cycle length." - type: agent_requested - - - name: marketing-analytics - title: "Marketing Analytics" - description: "Space for marketing team analytics" - rules: - - name: attribution-model - description: "Default attribution model" - prompt: "Use last-touch attribution model by default for campaign analysis unless otherwise specified." - type: always - -agents: - - name: sales-assistant - title: "Sales Assistant" - description: "AI assistant for sales analytics and reporting" - space: sales-analytics - llm: claude_4_sonnet - embedding_llm: text-embedding-3-large - runtime: reasoning - accessible_views: - - orders_view - - customers_view - - products_view - memory_mode: user - - - name: sales-report-builder - title: "Sales Report Builder" - description: "Specialized agent for building sales reports" - space: sales-analytics - llm: gpt_4o - runtime: plain - accessible_views: - - orders_view - memory_mode: space - - - name: marketing-analyst - title: "Marketing Analyst" - description: "AI assistant for marketing analytics" - space: marketing-analytics - llm: - byom: - name: custom-marketing-model - runtime: reasoning - memory_mode: user -``` - -```markdown - ---- -space: sales-analytics -description: "Use fiscal year for date calculations" -type: always ---- -Always use fiscal year starting April 1st when analyzing dates. -Q1 is April-June, Q2 is July-September, Q3 is October-December, Q4 is January-March. -``` - -```markdown - ---- -space: sales-analytics -description: "Standard revenue calculation" -type: always ---- -Revenue should be calculated as quantity × unit_price, excluding cancelled orders and refunds. -``` - -```markdown - ---- -space: sales-analytics -description: "Get revenue by fiscal quarter" -user_request: "What is the revenue by quarter?" ---- -SELECT - CASE - WHEN MONTH(order_date) BETWEEN 4 AND 6 THEN 'Q1' - WHEN MONTH(order_date) BETWEEN 7 AND 9 THEN 'Q2' - WHEN MONTH(order_date) BETWEEN 10 AND 12 THEN 'Q3' - ELSE 'Q4' - END as fiscal_quarter, - SUM(quantity * unit_price) as revenue -FROM orders -WHERE status != 'cancelled' -GROUP BY 1 -ORDER BY 1 -``` - -## Rules - -Rules provide instructions that guide agent behavior within a space. - -```yaml -rules: - - name: fiscal-year-rule - description: "Use fiscal year for date calculations" - prompt: "Always use fiscal year starting April 1st when analyzing dates" - type: always - - - name: efficiency-analysis - description: "Sales efficiency calculation guidance" - prompt: "When analyzing sales efficiency, calculate as deal size divided by sales cycle length" - type: agent_requested -``` - -### Rule Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `name` | string | Yes | Unique identifier for the rule | -| `description` | string | No | Human-readable description | -| `prompt` | string | Yes | The instruction text injected into agent context | -| `type` | string | Yes | Either `always` or `agent_requested` | - -### Rule Types - -- **`always`**: Applied to every agent interaction within the space -- **`agent_requested`**: Applied only when the agent determines the rule is relevant - -## Certified Queries - -Certified queries are pre-approved SQL queries that serve as an **example library** provided to the agent. The agent treats them as reference examples rather than a strict set of queries it must use. - - -The agent is not limited to only running certified queries. When answering a user request, the agent may: - -- Use a certified query directly if it matches the request -- Use a certified query as a **starting point** and adapt it (for example, adding filters, dimensions, or measures) to fit the user's question -- Generate a new query independently if no certified query is relevant - -Certified queries help guide the agent toward trusted patterns and correct business logic, but the agent retains full flexibility to construct the query that best answers the user's question. - - -```yaml -certified_queries: - - name: total-revenue - description: "Calculate total revenue" - user_request: "What is the total revenue?" - sql_query: "SELECT SUM(amount) as total_revenue FROM orders WHERE status = 'completed'" - - - name: monthly-sales - description: "Monthly sales breakdown" - user_request: "Show me sales by month" - sql_query: | - SELECT - DATE_TRUNC('month', order_date) as month, - SUM(amount) as total_sales - FROM orders - GROUP BY 1 - ORDER BY 1 -``` - -### Certified Query Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `name` | string | Yes | Unique identifier for the certified query | -| `description` | string | No | Human-readable description | -| `user_request` | string | Yes | The user request pattern this query answers | -| `sql_query` | string | Yes | The SQL query to execute | - -## Markdown Frontmatter Reference - -### Common Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `name` | string | No | Unique identifier. Inferred from the file name if omitted. | -| `kind` | string | No | Either `rule` or `certified_query`. Inferred from directory path or frontmatter shape if omitted. | -| `space` | string | No | Target space name. Defaults to the `auto` space if omitted. Only needed in [multiple agents setup](#multiple-agents-setup). | - -### Rule-Specific Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `description` | string | No | Human-readable description | -| `type` | string | Yes | Either `always` or `agent_requested` | -| `prompt` | string | No | Rule prompt. Falls back to the Markdown body if omitted. | - -### Certified Query-Specific Properties - -| Property | Type | Required | Description | -| --- | --- | --- | --- | -| `description` | string | No | Human-readable description | -| `user_request` | string | Yes | The user request pattern this query answers | -| `sql_query` | string | No | The SQL query. Falls back to the Markdown body if omitted. | - -## LLM Providers - -You can specify a predefined LLM model: - -```yaml -llm: claude_4_sonnet -``` - -Available predefined models: -- `claude_3_5_sonnetv2` -- `claude_3_7_sonnet` -- `claude_3_7_sonnet_thinking` -- `claude_4_sonnet` -- `claude_4_5_sonnet` -- `claude_4_5_haiku` -- `claude_4_5_opus` -- `gpt_4o` -- `gpt_4_1` -- `gpt_4_1_mini` -- `gpt_5` -- `gpt_5_mini` -- `o3` -- `o4_mini` - -Or use a Bring Your Own Model (BYOM) configuration: - -```yaml -llm: - byom: - name: my-custom-model -# Or reference by ID: -# llm: -# byom: -# id: 123 -``` - -### Embedding Models - -Available predefined embedding models: -- `text-embedding-3-large` -- `text-embedding-3-small` - -BYOM is also supported for embedding models using the same syntax as LLM providers. - -### Runtime Modes - -| Mode | Description | -| --- | --- | -| `plain` | Optimized for speed and cost | -| `reasoning` | Enables extended thinking mode for complex analysis | - -### Memory Modes - -| Mode | Description | -| --- | --- | -| `space` | Memories are shared across all users in the space | -| `user` | Memories are isolated per user | -| `disabled` | No memory is stored | diff --git a/docs-mintlify/admin/connect-to-data/index.mdx b/docs-mintlify/admin/connect-to-data/index.mdx index 4a75861f25593..e894f8ba2c09b 100644 --- a/docs-mintlify/admin/connect-to-data/index.mdx +++ b/docs-mintlify/admin/connect-to-data/index.mdx @@ -23,20 +23,6 @@ multitenancy. -## Advanced configuration - - - - Isolate tenants across databases, schemas, and caching layers. - - - Connect BI tools like Tableau, Power BI, Metabase, and others. - - - Reference secrets and connection settings from environment variables. - - - ## Recipes diff --git a/docs-mintlify/admin/connect-to-data/multiple-data-sources.mdx b/docs-mintlify/admin/connect-to-data/multiple-data-sources.mdx index a49c5f8c1d274..c11d129538fc3 100644 --- a/docs-mintlify/admin/connect-to-data/multiple-data-sources.mdx +++ b/docs-mintlify/admin/connect-to-data/multiple-data-sources.mdx @@ -95,14 +95,14 @@ cube(`orders_from_other_data_source`, { [ref-config-ref-env]: /reference/configuration/environment-variables [ref-config-ref-driverfactory]: /reference/configuration/config#driverfactory [ref-config-db]: /admin/connect-to-data/data-sources -[ref-config-multitenancy]: /admin/connect-to-data/multitenancy#multitenancy-multitenancy-vs-multiple-data-sources +[ref-config-multitenancy]: /embedding/multitenancy#multitenancy-multitenancy-vs-multiple-data-sources ## Cube Cloud Follow these steps to connect to multiple data sources in Cube Cloud: - Set up the `default` database connection when creating a new deployment. - Ensure you have the correct - [multitenancy](/admin/connect-to-data/multitenancy) configuration in + [multitenancy](/embedding/multitenancy) configuration in your `cube.js` file. - Configure the corresponding environment variables in **Settings → Environment variables**. diff --git a/docs-mintlify/admin/connect-to-data/multitenancy.mdx b/docs-mintlify/admin/connect-to-data/multitenancy.mdx deleted file mode 100644 index acc71238f08e5..0000000000000 --- a/docs-mintlify/admin/connect-to-data/multitenancy.mdx +++ /dev/null @@ -1,401 +0,0 @@ ---- -title: Multitenancy -description: Configure how Cube isolates tenants across databases, schemas, drivers, and caching using context-driven configuration hooks. ---- - -Cube supports multitenancy out of the box, both on database and data model -levels. Multiple drivers are also supported, meaning that you can have one -customer’s data in MongoDB and others in Postgres with one Cube instance. - -There are several [configuration options][ref-config-opts] you can leverage for -your multitenancy setup. You can use all of them or just a couple, depending on -your specific case. The options are: - -- `context_to_app_id` -- `schema_version` -- `repository_factory` -- `driver_factory` -- `context_to_orchestrator_id` -- `pre_aggregations_schema` -- `query_rewrite` -- `scheduled_refresh_contexts` -- `scheduled_refresh_time_zones` - -All of the above options are functions, which you provide in the -[configuration file][ref-config]. The functions accept one argument: -a context object, which has a [`securityContext`][ref-config-security-ctx] -property where you can provide all the necessary data to identify a user e.g., -organization, app, etc. By default, the -[`securityContext`][ref-config-security-ctx] is defined by [Cube API -Token][ref-security]. - -There are several multitenancy setup scenarios that can be achieved by using -combinations of these configuration options. - - - -See the following recipes: -- If you'd like to provide a [custom data source][ref-per-tenant-data-source-recipe] for each tenant. -- If you'd like to provide a [custom data model][ref-per-tenant-data-model-recipe] for each tenant. - - - -## Multitenancy vs Multiple Data Sources - -In cases where your Cube data model is spread across multiple different data -sources, consider using the [`data_source` cube property][ref-cube-datasource] -instead of multitenancy. Multitenancy is designed for cases where you need to -serve different datasets for multiple users, or tenants which aren't related to -each other. - -On the other hand, multitenancy can be used for scenarios where users need to -access the same data but from different databases. The multitenancy and multiple -data sources features aren't mutually exclusive and can be used together. - - - -A `default` data source **must** exist and be configured. It is used to resolve -target query data source for now. This behavior **will** be changed in future -releases. - - - -A simple configuration with two data sources might look like: - -**cube.js:** - -```javascript -module.exports = { - driverFactory: ({ dataSource } = {}) => { - if (dataSource === "db1") { - return { - type: "postgres", - database: process.env.DB1_NAME, - host: process.env.DB1_HOST, - user: process.env.DB1_USER, - password: process.env.DB1_PASS, - port: process.env.DB1_PORT - } - } else { - return { - type: "postgres", - database: process.env.DB2_NAME, - host: process.env.DB2_HOST, - user: process.env.DB2_USER, - password: process.env.DB2_PASS, - port: process.env.DB2_PORT - } - } - } -} -``` - -A more advanced example that uses multiple [data sources][ref-config-db] could -look like: - -**cube.js:** - -```javascript -module.exports = { - driverFactory: ({ dataSource } = {}) => { - if (dataSource === "web") { - return { - type: "athena", - database: dataSource, - - // ... - } - } else if (dataSource === "googleAnalytics") { - return { - type: "bigquery", - - // ... - } - } else if (dataSource === "financials") { - return { - type: "postgres", - database: "financials", - host: "financials-db.acme.com", - user: process.env.FINANCIALS_DB_USER, - password: process.env.FINANCIALS_DB_PASS - } - } else { - return { - type: "postgres", - - // ... - } - } - } -} -``` - -More information can be found on the [Multiple Data Sources -page][ref-config-multi-data-src]. - -### queryRewrite vs Multitenant Compile Context - -As a rule of thumb, the [`queryRewrite`][ref-config-query-rewrite] should be -used in scenarios when you want to define row-level security within the same -database for different users of such database. For example, to separate access -of two e-commerce administrators who work on different product categories within -the same e-commerce store, you could configure your project as follows. - -Use the following `cube.js` configuration file: - -```javascript -module.exports = { - queryRewrite: (query, { securityContext }) => { - if (securityContext.categoryId) { - query.filters.push({ - member: "products.category_id", - operator: "equals", - values: [securityContext.categoryId] - }) - } - return query - } -} -``` - -Also, you can use a data model like this: - - - -```yaml title="YAML" -cubes: - - name: products - sql_table: products -``` - -```javascript title="JavaScript" -cube(`products`, { - sql_table: `products` -}) -``` - - - -On the other hand, multi-tenant [`COMPILE_CONTEXT`][ref-cube-security-ctx] -should be used when users need access to different databases. For example, if -you provide SaaS ecommerce hosting and each of your customers have a separate -database, then each e-commerce store should be modeled as a separate tenant. - - - -```yaml title="YAML" -cubes: - - name: products - sql_table: "{COMPILE_CONTEXT.security_context.userId}.products" -``` - -```javascript title="JavaScript" -cube(`products`, { - sql_table: `${COMPILE_CONTEXT.security_context.userId}.products` -}) -``` - - - -### Running in Production - -Each unique id generated by `contextToAppId` or `contextToOrchestratorId` will -generate a dedicated set of resources, including data model compile cache, SQL -compile cache, query queues, in-memory result caching, etc. Depending on your -data model complexity and usage patterns, those resources can have a pretty -sizable memory footprint ranging from single-digit MBs on the lower end and -dozens of MBs on the higher end. So you should make sure Node VM has enough -memory reserved for that. - -There're multiple strategies in terms of memory resource utilization here. The -first one is to bucket your actual tenants into variable-size buckets with -assigned `contextToAppId` or `contextToOrchestratorId` by some bucketing rule. -For example, you can bucket your biggest tenants in separate buckets and all the -smaller ones into a single bucket. This way, you'll end up with a very small -count of buckets that will easily fit a single node. - -Another strategy is to split all your tenants between different Cube nodes and -route traffic between them so that each Cube API node serves only its own set of -tenants and never serves traffic for another node. In that case, memory usage is -limited by the number of tenants served by each node. Cube Cloud utilizes -precisely this approach for scaling. Please note that in this case, you should -also split refresh workers and assign appropriate `scheduledRefreshContexts` to -them. - -## Same DB Instance with per Tenant Row Level Security - -Per tenant row-level security can be achieved by configuring -[`queryRewrite`][ref-config-query-rewrite], which adds a tenant identifier -filter to the original query. It uses the -[`securityContext`][ref-config-security-ctx] to determine which tenant is -requesting data. This way, every tenant starts to see their own data. However, -resources such as query queue and pre-aggregations are shared between all -tenants. - -**cube.js:** - -```javascript -module.exports = { - queryRewrite: (query, { securityContext }) => { - const user = securityContext - if (user.id) { - query.filters.push({ - member: "users.id", - operator: "equals", - values: [user.id] - }) - } - return query - } -} -``` - -## Multiple DB Instances with Same Data Model - -Let's consider an example where we store data for different users in different -databases, but on the same Postgres host. The database name format is -`my_app__`, so `my_app_1_2` is a valid database name. - -To make it work with Cube, first we need to pass the `appId` and `userId` as -context to every query. We should first ensure our JWTs contain those properties -so we can access them through the [security context][ref-config-security-ctx]. - -```javascript -const jwt = require("jsonwebtoken") -const CUBE_API_SECRET = "secret" - -const cubeToken = jwt.sign({ appId: "1", userId: "2" }, CUBE_API_SECRET, { - expiresIn: "30d" -}) -``` - -Now, we can access them through the [`securityContext`][ref-config-security-ctx] -property inside the context object. Let's use -[`contextToAppId`][ref-config-ctx-to-appid] and -[`contextToOrchestratorId`][ref-config-ctx-to-orch-id] to create a dynamic Cube -App ID and Orchestrator ID for every combination of `appId` and `userId`, as -well as defining [`driverFactory`][ref-config-driverfactory] to dynamically -select the database, based on the `appId` and `userId`: - - - -The App ID (the result of [`contextToAppId`][ref-config-ctx-to-appid]) is used -as a caching key for various in-memory structures like data model compilation -results, connection pool. The Orchestrator ID (the result of -[`contextToOrchestratorId`][ref-config-ctx-to-orch-id]) is used as a caching key -for database connections, execution queues and pre-aggregation table caches. Not -declaring these properties will result in unexpected caching issues such as the -data model or data of one tenant being used for another. - - - -**cube.js:** - -```javascript -module.exports = { - contextToAppId: ({ securityContext }) => - `CUBE_APP_${securityContext.appId}_${securityContext.userId}`, - contextToOrchestratorId: ({ securityContext }) => - `CUBE_APP_${securityContext.appId}_${securityContext.userId}`, - driverFactory: ({ securityContext }) => ({ - type: "postgres", - database: `my_app_${securityContext.appId}_${securityContext.userId}` - }) -} -``` - -## Same DB Instance with per Tenant Pre-Aggregations - -To support per-tenant pre-aggregation of data within the same database instance, -you should configure the [`preAggregationsSchema`][ref-config-preagg-schema] -option in your `cube.js` configuration file. You should use also -[`securityContext`][ref-config-security-ctx] to determine which tenant is -requesting data. - -**cube.js:** - -```javascript -module.exports = { - contextToAppId: ({ securityContext }) => - `CUBE_APP_${securityContext.userId}`, - preAggregationsSchema: ({ securityContext }) => - `pre_aggregations_${securityContext.userId}` -} -``` - -## Multiple Data Models and Drivers - -What if for application with ID 3, the data is stored not in Postgres, but in -MongoDB? - -We can instruct Cube to connect to MongoDB in that case, instead of Postgres. To -do this, we'll use the [`driverFactory`][ref-config-driverfactory] option to -dynamically set database type. We will also need to modify our -[`securityContext`][ref-config-security-ctx] to determine which tenant is -requesting data. Finally, we want to have separate data models for every -application. We can use the [`repositoryFactory`][ref-config-repofactory] option -to dynamically set a repository with data model files depending on the `appId`: - -**cube.js:** - -```javascript -const { FileRepository } = require("@cubejs-backend/server-core") - -module.exports = { - contextToAppId: ({ securityContext }) => - `CUBE_APP_${securityContext.appId}_${securityContext.userId}`, - contextToOrchestratorId: ({ securityContext }) => - `CUBE_APP_${securityContext.appId}_${securityContext.userId}`, - driverFactory: ({ securityContext }) => { - if (securityContext.appId === 3) { - return { - type: "mongobi", - database: `my_app_${securityContext.appId}_${securityContext.userId}`, - port: 3307 - } - } else { - return { - type: "postgres", - database: `my_app_${securityContext.appId}_${securityContext.userId}` - } - } - }, - repositoryFactory: ({ securityContext }) => - new FileRepository(`model/${securityContext.appId}`) -} -``` - -## Scheduled Refreshes for Pre-Aggregations - -If you need scheduled refreshes for your pre-aggregations in a multi-tenant -deployment, ensure you have configured -[`scheduled_refresh_contexts`][ref-config-refresh-ctx] correctly. You may also -need to configure [`scheduled_refresh_time_zones`][ref-config-refresh-tz]. - - - -Leaving [`scheduled_refresh_contexts`][ref-config-refresh-ctx] unconfigured will -lead to issues where the security context will be `undefined`. This is because -there is no way for Cube to know how to generate a context without the required -input. - - - -[ref-config]: /admin/connect-to-data#configuration-options -[ref-config-opts]: /reference/configuration/config -[ref-config-db]: /admin/connect-to-data/data-sources -[ref-config-driverfactory]: /reference/configuration/config#driver_factory -[ref-config-repofactory]: /reference/configuration/config#repository_factory -[ref-config-preagg-schema]: /reference/configuration/config#pre_aggregations_schema -[ref-config-ctx-to-appid]: /reference/configuration/config#context_to_app_id -[ref-config-ctx-to-orch-id]: /reference/configuration/config#context_to_orchestrator_id -[ref-config-multi-data-src]: /admin/connect-to-data/advanced/multiple-data-sources -[ref-config-query-rewrite]: /reference/configuration/config#query_rewrite -[ref-config-refresh-ctx]: /reference/configuration/config#scheduled_refresh_contexts -[ref-config-refresh-tz]: /reference/configuration/config#scheduled_refresh_timezones -[ref-config-security-ctx]: /docs/data-modeling/access-control/context -[ref-security]: /docs/data-modeling/access-control -[ref-cube-datasource]: /reference/data-modeling/cube#data_source -[ref-cube-security-ctx]: /reference/data-modeling/context-variables#compile_context -[ref-per-tenant-data-source-recipe]: /recipes/configuration/multiple-sources-same-schema -[ref-per-tenant-data-model-recipe]: /recipes/configuration/custom-data-model-per-tenant \ No newline at end of file diff --git a/docs-mintlify/admin/deployment/auto-suspension.mdx b/docs-mintlify/admin/deployment/auto-suspension.mdx index a24759ee61b3b..ab6df74437f36 100644 --- a/docs-mintlify/admin/deployment/auto-suspension.mdx +++ b/docs-mintlify/admin/deployment/auto-suspension.mdx @@ -120,7 +120,7 @@ response times to be significantly longer than usual. [ref-deployment-pricing]: /admin/account-billing/pricing [ref-monitoring]: /admin/deployment/monitoring-integrations [ref-data-model]: /docs/data-modeling/overview -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [self-effects]: #effects-on-experience [ref-refresh-worker]: /cube-core/architecture#refresh-worker [ref-sls]: /docs/integrations/semantic-layer-sync#on-schedule diff --git a/docs-mintlify/admin/deployment/deployment-types.mdx b/docs-mintlify/admin/deployment/deployment-types.mdx index 0d9190019b9a5..757e6b94cf689 100644 --- a/docs-mintlify/admin/deployment/deployment-types.mdx +++ b/docs-mintlify/admin/deployment/deployment-types.mdx @@ -179,6 +179,6 @@ and select from the available options: [ref-ctx-to-app-id]: /reference/configuration/config#context_to_app_id [ref-limits]: /docs/deployment/cloud/limits#resources [ref-scalability]: /docs/deployment/cloud/scalability -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-auto-sus]: /docs/deployment/cloud/auto-suspension [ref-refresh-worker]: /cube-core/architecture#refresh-worker diff --git a/docs-mintlify/admin/deployment/warm-up.mdx b/docs-mintlify/admin/deployment/warm-up.mdx index e896f75158022..39caba49c71eb 100644 --- a/docs-mintlify/admin/deployment/warm-up.mdx +++ b/docs-mintlify/admin/deployment/warm-up.mdx @@ -94,5 +94,5 @@ and enable **Warm-up pre-aggregations before deploying API**: [ref-prod-multi-cluster]: /docs/deployment/cloud/deployment-types#production-multi-cluster [ref-data-model]: /docs/data-modeling/overview [ref-dynamic-data-model]: /docs/data-modeling/dynamic -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-pre-aggs]: /docs/pre-aggregations#pre-aggregations \ No newline at end of file diff --git a/docs-mintlify/admin/monitoring/performance.mdx b/docs-mintlify/admin/monitoring/performance.mdx index 7e1592944b560..647c7946d07c9 100644 --- a/docs-mintlify/admin/monitoring/performance.mdx +++ b/docs-mintlify/admin/monitoring/performance.mdx @@ -180,7 +180,7 @@ for queries and jobs. [ref-prod-cluster]: /docs/deployment/cloud/deployment-types#production-cluster [ref-multi-cluster]: /docs/deployment/cloud/deployment-types#production-multi-cluster [ref-pre-aggregations]: /docs/pre-aggregations/using-pre-aggregations -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-context-to-app-id]: /reference/configuration/config#context_to_app_id [ref-cache-types]: /docs/pre-aggregations#cache-type [ref-indexes]: /docs/pre-aggregations/using-pre-aggregations#using-indexes \ No newline at end of file diff --git a/docs-mintlify/admin/monitoring/query-history.mdx b/docs-mintlify/admin/monitoring/query-history.mdx index 080f59598a2af..9bc864d20c887 100644 --- a/docs-mintlify/admin/monitoring/query-history.mdx +++ b/docs-mintlify/admin/monitoring/query-history.mdx @@ -236,6 +236,6 @@ while the query is in the query execution queue: [ref-query-format]: /reference/rest-api/query-format [ref-cache-types]: /docs/pre-aggregations#cache-type [ref-security-context]: /docs/data-modeling/access-control/context -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-apis]: /reference [ref-query-history-export]: /admin/deployment/monitoring-integrations#query-history-export \ No newline at end of file diff --git a/docs-mintlify/admin/users-and-permissions/custom-roles.mdx b/docs-mintlify/admin/users-and-permissions/custom-roles.mdx index f907a15eda749..cd78df899d9ff 100644 --- a/docs-mintlify/admin/users-and-permissions/custom-roles.mdx +++ b/docs-mintlify/admin/users-and-permissions/custom-roles.mdx @@ -145,6 +145,6 @@ Policies can have the following actions associated with them. [ref-perf-insights]: /admin/monitoring/performance [ref-sql-runner]: /docs/data-modeling/sql-runner [ref-semantic-catalog]: /docs/workspace/semantic-catalog -[ref-ai-agents]: /admin/ai/spaces-agents-models#2-agents-ai-agents -[ref-ai-spaces]: /admin/ai/spaces-agents-models#1-spaces-agent-spaces +[ref-ai-agents]: /admin/ai +[ref-ai-spaces]: /admin/ai/multi-agent [ref-workbooks]: /analytics/workbooks \ No newline at end of file diff --git a/docs-mintlify/docs.json b/docs-mintlify/docs.json index cfa7c96a89904..c6ab5ee8c0840 100644 --- a/docs-mintlify/docs.json +++ b/docs-mintlify/docs.json @@ -382,11 +382,11 @@ "group": "AI", "pages": [ "admin/ai/index", - "admin/ai/spaces-agents-models", - "admin/ai/agent-rules", - "admin/ai/bring-your-own-model", + "admin/ai/rules", + "admin/ai/certified-queries", "admin/ai/memory-isolation", - "admin/ai/yaml-config" + "admin/ai/multi-agent", + "admin/ai/bring-your-own-model" ] }, @@ -704,6 +704,22 @@ } }, "redirects": [ + { + "source": "/admin/ai/agent-rules", + "destination": "/admin/ai/rules" + }, + { + "source": "/admin/ai/yaml-config", + "destination": "/admin/ai" + }, + { + "source": "/admin/ai/spaces-agents-models", + "destination": "/admin/ai/multi-agent" + }, + { + "source": "/admin/connect-to-data/multitenancy", + "destination": "/embedding/multitenancy" + }, { "source": "/embedding/private-embedding", "destination": "/embedding/iframe/auth/private" diff --git a/docs-mintlify/docs/data-modeling/access-control/context.mdx b/docs-mintlify/docs/data-modeling/access-control/context.mdx index 94e84a35455a7..00067ef3e1c7e 100644 --- a/docs-mintlify/docs/data-modeling/access-control/context.mdx +++ b/docs-mintlify/docs/data-modeling/access-control/context.mdx @@ -533,7 +533,7 @@ view(`total_revenue_per_customer`, { [link-auth0-jwks]: https://auth0.com/docs/tokens/json-web-tokens/json-web-key-sets -[link-multitenancy]: /admin/connect-to-data/multitenancy +[link-multitenancy]: /embedding/multitenancy [ref-config-queryrewrite]: /reference/configuration/config#query_rewrite [ref-config-sched-refresh]: /reference/configuration/config#scheduledrefreshcontexts [ref-config-sec-ctx]: /reference/configuration/config#securitycontext @@ -542,4 +542,4 @@ view(`total_revenue_per_customer`, { [ref-auth-integration]: /docs/data-modeling/access-control#authentication-integration [ref-extend-context]: /reference/configuration/config#extend_context [ref-dynamic-data-modeling]: /docs/data-modeling/dynamic -[ref-multitenancy]: /admin/connect-to-data/multitenancy \ No newline at end of file +[ref-multitenancy]: /embedding/multitenancy \ No newline at end of file diff --git a/docs-mintlify/docs/explore-analyze/dashboards/widgets/ai-summary.mdx b/docs-mintlify/docs/explore-analyze/dashboards/widgets/ai-summary.mdx index a72648b0e9502..c540118c2dd66 100644 --- a/docs-mintlify/docs/explore-analyze/dashboards/widgets/ai-summary.mdx +++ b/docs-mintlify/docs/explore-analyze/dashboards/widgets/ai-summary.mdx @@ -35,5 +35,5 @@ Click the refresh icon (or open the widget menu and choose **Refresh**) to regen By default, AI summaries use the agent configured at the dashboard level. You can override the agent per widget when you need a particular [agent's][ref-agents] tooling, model, or guardrails for a specific summary. [ref-workbooks]: /docs/explore-analyze/workbooks -[ref-agents]: /admin/ai/spaces-agents-models +[ref-agents]: /admin/ai [ref-controls]: /docs/explore-analyze/dashboards/widgets/controls diff --git a/docs-mintlify/docs/introduction.mdx b/docs-mintlify/docs/introduction.mdx index 72278d408466b..2a626e03947f3 100644 --- a/docs-mintlify/docs/introduction.mdx +++ b/docs-mintlify/docs/introduction.mdx @@ -101,6 +101,5 @@ Rather than inventing proprietary protocols, Cube implements widely adopted stan [ref-embedding]: /reference/embedding [ref-chat-api]: /reference/chat-api [ref-mcp-server]: /reference/mcp-server -[ref-spaces-agents-models]: /docs/agentic-analytics/spaces-agents-models -[ref-agent-rules]: /docs/agentic-analytics/agent-rules -[ref-agent-memories]: /docs/agentic-analytics/memory-isolation \ No newline at end of file +[ref-agent-rules]: /admin/ai/rules +[ref-agent-memories]: /admin/ai/memory-isolation \ No newline at end of file diff --git a/docs-mintlify/docs/pre-aggregations/refreshing-pre-aggregations.mdx b/docs-mintlify/docs/pre-aggregations/refreshing-pre-aggregations.mdx index 215b3bab81282..39216a65016c0 100644 --- a/docs-mintlify/docs/pre-aggregations/refreshing-pre-aggregations.mdx +++ b/docs-mintlify/docs/pre-aggregations/refreshing-pre-aggregations.mdx @@ -46,6 +46,6 @@ If you're using Cube Cloud, you can use a [production multi-cluster][ref-product that would automatically do this for you. -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-preaggs]: /docs/pre-aggregations/using-pre-aggregations [ref-production-multi-cluster]: /docs/deployment/cloud/deployment-types#production-multi-cluster \ No newline at end of file diff --git a/docs-mintlify/embedding/authentication/security-context.mdx b/docs-mintlify/embedding/authentication/security-context.mdx index d96a0cd516d0b..060f36ffabb25 100644 --- a/docs-mintlify/embedding/authentication/security-context.mdx +++ b/docs-mintlify/embedding/authentication/security-context.mdx @@ -533,7 +533,7 @@ view(`total_revenue_per_customer`, { [link-auth0-jwks]: https://auth0.com/docs/tokens/json-web-tokens/json-web-key-sets -[link-multitenancy]: /admin/connect-to-data/multitenancy +[link-multitenancy]: /embedding/multitenancy [ref-config-queryrewrite]: /reference/configuration/config#query_rewrite [ref-config-sched-refresh]: /reference/configuration/config#scheduledrefreshcontexts [ref-config-sec-ctx]: /reference/configuration/config#securitycontext @@ -542,4 +542,4 @@ view(`total_revenue_per_customer`, { [ref-auth-integration]: /docs/data-modeling/access-control#authentication-integration [ref-extend-context]: /reference/configuration/config#extend_context [ref-dynamic-data-modeling]: /docs/data-modeling/dynamic -[ref-multitenancy]: /admin/connect-to-data/multitenancy \ No newline at end of file +[ref-multitenancy]: /embedding/multitenancy \ No newline at end of file diff --git a/docs-mintlify/recipes/configuration/custom-data-model-per-tenant.mdx b/docs-mintlify/recipes/configuration/custom-data-model-per-tenant.mdx index 522da056a4d21..2067c7807dcee 100644 --- a/docs-mintlify/recipes/configuration/custom-data-model-per-tenant.mdx +++ b/docs-mintlify/recipes/configuration/custom-data-model-per-tenant.mdx @@ -522,7 +522,7 @@ Instead of using the `file_repository` utility, you would have to write your own code that fetches data model files for each tenant. -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-scheduled-refresh-contexts]: /reference/configuration/config#scheduled_refresh_contexts [ref-context-to-app-id]: /reference/configuration/config#context_to_app_id [ref-config-files]: /admin/connect-to-data#cubepy-and-cubejs-files diff --git a/docs-mintlify/reference/configuration/config.mdx b/docs-mintlify/reference/configuration/config.mdx index bc558cc272d81..4397463e26ffb 100644 --- a/docs-mintlify/reference/configuration/config.mdx +++ b/docs-mintlify/reference/configuration/config.mdx @@ -1518,7 +1518,7 @@ module.exports = { [link-jwt-ref-aud]: https://tools.ietf.org/html/rfc7519#section-4.1.3 [link-wiki-tz]: https://en.wikipedia.org/wiki/Tz_database [ref-development-mode]: /admin/connect-to-data#development-mode -[ref-multitenancy]: /admin/connect-to-data/multitenancy +[ref-multitenancy]: /embedding/multitenancy [ref-rest-api]: /reference/rest-api [ref-sql-api]: /reference/sql-api [ref-pre-aggregations-refresh-key]: /reference/data-modeling/pre-aggregations#refresh_key