Release 6.3
Tellius 6.3 is here. The context your analysts carry in their heads is now encoded in a skills layer they control. Tune how Kaiya writes, charts, and reasons, without touching a system prompt or filing a ticket. The tab-switching between Salesforce, Slack, and your BI tool is gone, so your field team starts asking Kaiya questions from Salesforce or Slack/Teams without opening another tab. The ten-minute path from a raw data source to a live analytical conversation means new users who started recently stop waiting and start asking on day one. And when they land on the homepage, the work that matters is already waiting: briefings delivered, recent context preserved, team resources surfaced. Read on to find more:
You can now build agentic workflows conversationally by describing them (akin Kaiya Apps and Kaiya Architect).
The redesigned homepage surfaces scheduled mission outputs, recently viewed content, and personalized suggestions based on what your team is already using.
New user onboarding takes a user from a fresh login to a live Kaiya conversation in about ten minutes, with starter questions waiting for them when they arrive.
Skills gives admins a way to tune Kaiya's behavior for a specific user base without editing system prompts.
The Kaiya browser extension brings Kaiya into any web page as a side panel. Veeva, Salesforce, internal portals — the answer is always one keystroke away.
Slack and Teams integration lets users mention @Kaiya in any channel and trigger missions with slash commands.
There is more in 6.3 beyond the flagship features, so dig in.
🚀 New features
Build Kaiya Missions conversationally
You describe what the workflow should do, Kaiya drafts the steps, and execution starts from the same thread.
The Chat pane on the left shows the conversation thread and the Mission Steps pane on the right displays the full step sequence with type badges and real-time execution state. Each step is individually editable, so you can modify a step's logic mid-session and re-execute. When execution completes, a Summary tab appears alongside the Mission Steps tab, rendering the full generated output.
How it works in practice
Describe. Tell Kaiya what the workflow should do.
Review steps. Kaiya drafts a sequence of steps. You refine the draft conversationally and approve.
Execute. The workflow runs. Clarification cards appear in the thread when a step needs an input.
Schedule. Set a recurrence, or trigger the workflow from a sample query.
Deliver. The output lands as a PPTX, PDF, DOCX, or email.
Mission Draft Editor
Once a mission is created, it lives in a dedicated editor with three tabs:
Last Briefing. Displays the output of the most recent run. Each iteration is shown step by step (Input Collection, SQL Query, Python Analysis, Summary) with a checkmark on each completed step and the full rendered output below, including tables, charts, and narrative text. Follow-up questions are auto-generated at the end of every briefing, giving users a path to drill deeper without starting a new mission. A "What to do next" bar offers two actions: Create App (convert the briefing into an interactive Kaiya App) and Create new schedule for Mission (set up a recurring cadence for automatic delivery).
Configuration. A left-hand navigation panel organizes the mission into six sections: Basic Information, Knowledge Sources, Mission Steps, Triggers, Schedule, and Outputs. The Mission Steps panel lists every step with a type badge (Input, SQL, Python, Summary) so the step composition is visible at a glance. Each step has a pencil icon for inline editing directly in the conversation.
History. For scheduled missions, a run log showing every execution the mission has produced, most recent first. Total Runs, Success Rate, and Average Duration are displayed, giving an immediate health check. The history table lists each run with its job name, status, start time, end time, duration in seconds, a short summary of the output, and the logged timestamp.
What is different now
Interactive execution. Clarification cards appear during the run. If a step needs a date range, a territory filter, or a metric choice, Kaiya prompts for it at the point in execution where that input is required.
Variable passing. Parameters flow across steps automatically. State produced in one step (for example, a list of underperforming territories or a derived metric) is available to later steps without manual configuration.
Trigger from queries. Workflows surface in the conversation under the "Kaiya Mission" label, so a query can be converted into a recurring workflow.
Inline tabs. The previous configurations for triggering, scheduling, and generating output all move out of dialogs and into inline tabs in the conversation thread.
Output formats
Completed missions deliver output as PPTX, PDF, or DOCX. For scheduled missions, the artifact in the selected format is automatically emailed to configured recipients once the workflow completes.
Existing missions remain available and are labeled "Classical Editor". The classical editor remains available for existing missions; subsequent releases will transition users fully to the conversational interface.
Export generation for mission outputs now runs as a background job with pagination support, so large outputs are processed without blocking the conversation thread. Progress is tracked in the background, and the user is notified when the artifact is ready for download.
Homepage redesign: A home that learns your workflow
The Tellius homepage has been redesigned so that the new home surfaces what matters right now: outputs from scheduled missions, recently accessed content, and personalized suggestions based on what others in the same Business View environment are using.
What's on the new home page
Briefings. Outputs from scheduled Missions are delivered directly to the home screen.
Recently Viewed. The home picks up where the user left off, surfacing apps, Vizpads, and conversations the user was last working on.
Suggested for You. Surfaces high-interaction resources across the workspace: shared Vizpads, Missions, and Apps that other users are actively engaging with. This is a rename and continuation of the Trending tab from previous releases.
Adaptive by day, personalized by use
The homepage adapts to where you are in the lifecycle.
Day 0 - New user. User without data sources or Business Views. When a user logs in and has no configured data sources or Business Views, they are routed to Kaiya Architect to connect a source and conversationally build their first Business View.
Day 1 - Getting started. Starter briefings and suggested content appear, curated to the Business View the user just created. Apps shared by the team surface immediately.
Day 30+ - Power user. The full personalized content library is in place: briefings, recents, activity-based suggestions, and shared team resources in a single view.
A lightweight homepage version is available for customers who do not have Kaiya enabled. KPI pinning is deprecated. Favorites remain available.
The platform-wide font family has been updated as part of the homepage redesign, bringing typographic consistency across all modules and pages.
New user onboarding: From data source to first App in ten minutes
New users without existing data sources or Business Views can now move directly from a fresh login to a live Kaiya conversation, with starter questions auto-generated from the new Business View. There is no blank screen, no manual configuration, and no need to find a starting point on the user's own.
The Day 0 flow
A new user is routed into Kaiya Architect on first login. From there:
The user configures a data source. The data connection can be setup directly from the Architect chat, with real-time validation as connection details are entered.
The user builds a first Business View through the Kaiya Architect conversation.
An "Open in Kaiya" link appears once the Business View is published.
Kaiya opens with six auto-generated starter questions waiting in the thread. The starter questions are generated from the newly published Business View, so they reference real dimensions, metrics, and entities the user just configured.
Conversation continuity. When a Business View is built or updated during the onboarding flow, the Kaiya thread compacts and reloads with the latest Business View state, so the conversation reflects the current schema.
Source lock. Once tables are selected in Data Architect, the underlying data source is locked. This prevents a user from accidentally switching the source mid-workflow and producing inconsistent results.
Skills: Make Kaiya yours without touching core prompts
In 6.3, the context capabilities that make Kaiya behave like your team — Skills, Phrase Learning, Query Learning, and Memory — are now unified under a single tab: the Context.
Skills let you tune how Kaiya writes, charts, and reasons without editing the underlying system prompts. A skill encodes user-specific preferences (formatting rules, summary style, chart conventions, analytical framing, query patterns, chart rules, narrative style) and Kaiya applies them automatically during conversations. Skills are configured at the deployment (tenant) level, not per individual user: once a skill is published, it changes Kaiya's behaviour for everyone in that tenant.
The four layers of context
The Domain Reasoning Layer organizes context across four pillars. Each pillar represents a different way Kaiya absorbs and applies your team's context:
Skills
Layer 1 · Taught
Domain ontologies, investigation approaches, and business logic. Pre-built with Kaiya, extended by what you teach it about your domain.
Phrase learning
Layer 2 · Defined
Phrase-level patterns Kaiya learns from your team's vocabulary. Business terms, synonyms, and shorthand mapped to the data model.
Query learning
Layer 3 · Confirmed
Query patterns Kaiya has confirmed from your feedback. Preferred queries, business rules of thumb, what "good" looks like.
Memory
Layer 4 · Compounding
Compounding context Kaiya carries across sessions. The longest-tail layer; gets richer the more your team uses the system.
The All Layers view shows the full context graph with elements across all four layers, joined and continuously refining together.
When skills overlap, the precedence order is: User skills > Domain skills > Behavioural Layer > Implementation Layer. User-level customizations always win over broader defaults; the Implementation Layer (which defines core tool calls and platform functionality) sits at the foundation and is not overridden through user or domain skills.
Inside the Skills layer: four context layers
When you open the Skills tab, the left Context Layers panel shows the four layers that feed Kaiya's reasoning for a request, from the foundational platform instructions through to your tenant's own skills:
System Prompt. The base instructions Kaiya uses when planning and summarizing. It is read-only reference, and it is split into two sub-layers: the Implementation Layer (the core tool calls and platform functionality that make Kaiya operate correctly across the platform) and the Behavioural Layer (Kaiya's default behaviour, which super users can tune when platform-wide behaviour needs adjusting).
Business View Context. The schema, grain, and vocabulary passed to Kaiya with the active Business View. It is set by the workspace and is read-only here.
Domain Skill. Industry-specific rules and defaults, curated by Tellius and shipped with the platform (described below).
Custom Skill. Your tenant's own skills, authored from the specific requirements of your deployment (described below).
Domain Skills vs Custom Skills
The difference is who owns them, who can edit them, and how they are structured.
Domain Skills are curated by Tellius and ship with the platform. They hold industry-specific rules and sensible defaults for a vertical. A Domain Skill is organized into one or more sections, where each section has its own description and detail and teaches Kaiya one distinct thing. For example, one section for how to run a particular analysis and another for how to summarize the result. Domain Skills are editable by super users only; every other role sees them as read-only.
Custom Skills are created by your own organization, based on the specific requirements of your deployment (your vocabulary, preferences, and business rules). A Custom Skill is authored directly in the tenant and, once published, applies to every user in that tenant rather than to a single person. A Custom Skill carries a description, a detail body, and one or more routing labels (described below).
Give the skill a name, then complete it according to its layer:
For a Custom Skill, write a Description of what the skill does and when it applies, then fill in the Detail body. The detail accepts markdown, so a data dictionary, a formatting style guide, or a set of domain rules are all valid sources. Add one or more Labels to route the skill to the correct engine path.
For a Domain Skill, write a Description, then add the Sections that hold the skill's rules. Each section has its own description and detail.
A skill's layer (Domain or Custom) is chosen when it is created and cannot be changed afterward. Each skill also has a Status control, so it can be enabled or disabled without being deleted.
Anatomy of a Custom Skill
Skill name. A name for the skill.
Description. A short, human-readable summary of when and why the skill applies. The description is what routes the skill to the relevant Kaiya engine paths.
Detail. The skill definition itself — the instructions the engine executes. Accepts markdown.
Labels. One or more technical routing tags that determine which Kaiya engine path the skill applies to.
Status. A toggle to enable or disable the skill without deleting it.
What each Label controls:
Default
General behaviour where no more specific routing applies.
SQL
SQL generation for standard textual queries. Also the routing label for Deep Insights analytical framing.
SQL Editor
Semantic-cache queries — the fast path that returns within 3–5 seconds once the original query has been configured.
SQL Reflection
Reflection logic applied to textual SQL queries.
SQL Editor Reflection
Reflection logic applied to semantic-cache queries.
Highcharts
Chart selection and formatting via the Highcharts rendering library.
Chart Config
Legacy chart configuration (being phased out).
Narration
How chart titles, summaries, and result narratives are written.
How skills are layered and prioritized
A single request can match more than one layer at once. The layers resolve from the foundational platform instructions through to your tenant's own skills:
What each Label controls:
Layer
What it does
Layer 1a: System Prompt - Implementation
Defines core tool calls and platform functionality. The foundational layer that ensures Kaiya operates correctly across the platform.
Layer 1b: System Prompt - Behavioural
Defines default Kaiya behavior across the platform. Can be tuned by super users when platform-wide behavior needs adjustment.
Layer 2: Domain skills
Encodes vertical or Business-View-specific behavior. Scoped to a Business View.
Layer 3: User skills
Per-user customizations. Overrides domain and behavioural layers at runtime when both apply.
When more than one applies, a loaded Custom Skill overrides the Behavioural Layer, and a Custom Skill takes precedence over a Domain Skill where both apply. The Implementation Layer sits at the foundation and is never overridden by a skill.
Precedence in short: Custom Skill › Domain Skill › Behavioural Layer, with the Implementation Layer as the non-overridable foundation.
You do not select or invoke a skill when you chat with Kaiya. Enabled skills are matched and applied automatically, based on each skill's description and label routing — the same way Phrase Learning, Query Learning, and Memory are applied. To see which skills and other context were used in a given answer, open the thought process dropdown on that Kaiya response.
Who can manage skills
Skill management is role-based. Super users see and manage all four context layers, including Domain Skills. Admin users can manage Custom Skills. Power users and other roles can see the skills applied to their conversations but cannot add or edit them.
Kaiya Browser Extension: Ask Kaiya on any web page
The Kaiya browser extension brings Kaiya into any web page as a persistent side panel. Analysts who live in Salesforce, Veeva, internal portals, or web-based spreadsheets no longer need to switch tabs to ask a question.
One-click activation. The side panel slides in from any tab via the keyboard shortcut ⌘ Shift K.
Context-aware. The extension detects the active page and auto-selects the most relevant Business View for the context.
Highlight to query. Select any number or phrase on the page and ask Kaiya about it. The selection is passed into the conversation as context.
Full Kaiya capability inside the panel. Missions, Deep Insights, Apps, and PPTX export all run from the side panel.
SSO and zero re-login. The extension inherits the user's existing Tellius session, so there is no separate login for the side panel.
Capture screen. Pass a screenshot of the current page into the conversation as visual context, so Kaiya can reason about what's on screen.
Voice input. Dictate queries directly to the side panel.
Slack and Teams Integration: Kaiya in the channels you already use
Many data questions surface in Slack or Teams. In 6.3, a Kaiya bot can be added to Slack channels and Microsoft Teams channels so users can ask questions and trigger missions without leaving the conversation.
What the bot can do
Direct message the bot for individual questions, @mention the bot in any channel it has been added to, or add it to a group conversation so everyone can ask questions and see answers.
The first time you ask a question in a new conversation, Kaiya presents a data source picker. You can let Kaiya auto-detect the most relevant Business View, manually select one or more specific BVs, or query across unstructured documents (PDFs, text files). The selection persists for the rest of that conversation.
When a question requires multi-step analysis, Kaiya offers to run a Deep Insight workflow.
When Kaiya needs more context, it asks clarification questions and presents a dropdown with suggested options. You can select from the dropdown or type answer directly in the thread.
Follow-up questions in the same thread continue the conversation with full context — the data source and prior questions carry forward, so users can ask things like "now break that down by product" without re-specifying the BV.
Every response includes 👍 and 👎 feedback buttons and a View in Tellius button that opens the same conversation in the Tellius web app for deeper analysis, dashboard building, or sharing.
Slack vs Teams
The integration supports both Slack and Microsoft Teams with the same core capabilities. A few differences reflect how each platform works:
Conversation boundary
Slack threads. Each thread is a separate conversation. New top-level message starts a fresh conversation.
Continuous chat. Use the Change Data Source button to switch BVs mid-conversation.
Response length
Truncated at 2,900 characters (Slack's 3,000-character limit). Use View in Tellius for the full response.
No truncation. Full responses render in Teams.
Account linking
Credentials configured at the workspace level by an admin.
One-time per-user account linking flow. Each user clicks Link my Tellius account on first use.
Adding the bot to a channel
/invite @Tellius in the channel.
Add the Tellius app from the Teams app bar.
Kaiya MCP support
Tellius now has a Model Context Protocol (MCP) server, allowing MCP-compatible clients to call Kaiya's reasoning layer as a tool. An MCP client (such as Claude Desktop, an IDE like Cursor, or a custom or partner agent) connects to the Tellius MCP server and queries data through the same Business View definitions, row-level security, and access controls that govern Kaiya elsewhere in the platform. The connecting client does not receive a copy of the underlying data; it issues requests that Tellius resolves against the governed semantic layer and returns results for.
Governed access. Queries issued over MCP resolve against Business Views and respect the same row-level security and metric definitions as the Tellius web application.
Client-agnostic. Works with any client that implements the Model Context Protocol.
Admin-provisioned. Access to the Tellius MCP server requires authentication that a Tellius administrator configures before a client can connect.
📈 Enhancements
Quicker auto-routing in Kaiya
Kaiya's reflection necessity checker has been tuned. Basic queries that don't benefit from a reflection pass now skip it automatically, eliminating a few seconds latency that previously affected simple queries. In practice, only about 25% of basic queries still trigger reflection. There is no user-facing toggle — routing happens automatically based on the query type.
Fix with Kaiya
In Kaiya Apps, when a query fails, a Fix it action appears with the error. Selecting it passes the error into the Kaiya conversation panel, where Kaiya attempts a correction. The corrected output produces a new versioned result, and the original is preserved alongside it.
The error is the input. No re-typing the question, no describing what went wrong. Kaiya works directly from the failure.
When something breaks, the platform corrects it in-flow instead of handing the user off to engineering or support.
It's non-destructive. Every fix is versioned against the original, so users can compare the two, trust the result, and revert if needed.
Inline citations
Within a Kaiya Deep Insights run, hovering over a numeric result now reveals the underlying dataframe name, the exact SQL query that produced the result, and the row and column counts of the result set. The citation includes the Python aggregation logic where applicable, so users can trace how a specific number was computed. Natural language descriptions of the SQL load asynchronously alongside the result, so the citation is available immediately without blocking the rendering.
Apps: publishing and versioning
Publishing replaces sharing as the primary distribution model for apps. The publishing flow adds:
Version pinning. A specific app version can be marked as active so subscribers always see that version when the app refreshes.
Signed and unsigned URL support. Apps can be distributed via either, depending on the distribution context.
Public access toggle. A published app can be exposed to external stakeholders through a public access toggle, without setting up separate sharing rules.
Each published App now has its own dedicated Kaiya conversation thread, separate from the source Deep Insight conversation that originated the app. Questions asked inside the App stay scoped to the App's Business View and filters and do not pollute or get polluted by the parent Deep Insight conversation.
LLM Settings UI
LLM model configuration moves into a dedicated module split into two surfaces: LLM Configuration (where providers and models are defined as named entries) and LLM Assignments (where each Kaiya capability is mapped to a configured model). The new layout replaces the previous inline editing form with a cleaner card-based interface
Dataset Refresh Performance Improvement
Dataset refresh operations have been optimized for faster processing in 6.3. This reduces the time between initiating a refresh and having updated data available in Business Views and Vizpads, particularly for large datasets.
Chart Resizing Grid Enforcement
Chart resizing in Vizpads is now constrained to the grid boundary, preventing charts from being dragged beyond the layout edge. Repeated resize warnings are suppressed after the first notification, resulting in a cleaner editing experience when working with dense Vizpad layouts.
Pivot Table Drag-and-Drop Improvement
The drag-and-drop experience for configuring pivot tables has been refined, addressing interaction issues that could occur when rearranging fields.
Last updated
Was this helpful?