> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/whats-new/release-6.4.md).
# Release 6.4
Tellius 6.4 is here.
Kaiya Apps now has a Plan mode: Kaiya works out what the App should be and stops there, so you can settle the shape of it before anything is built or run. Mission steps can be edited inline and applied together, keeping the plan yours through every revision. And Industry Packs let an administrator publish a library of ready-made Apps and Missions, so a team starts from working analysis rather than an empty workspace.
Read on to find more:
* **Plan mode for Kaiya Apps.** Shape an app over as many rounds as it takes. Nothing is built and nothing is run until you choose to build.
* **You work with one agent from question to result.** In Deep Insights, a single agent explores the data, builds the plan, runs it and checks the result. It asks you where the data doesn't support the question, and repairs a step rather than starting over. App creation keeps you in one conversation too: one agent handles it and brings in sub-agents for the plan and the code.
* **One space for Kaiya.** Move from a question to an App or a Mission without choosing the surface first; Kaiya carries the conversation across.
* **Inline editing of Mission steps.** Revise several steps and apply them in one pass.
* **Industry Packs.** An admin publishes App and Mission templates that a team can start from.
* **Tellius as an MCP client.** Kaiya can query the MCP servers you have connected and save the result as an input step in a Deep Insight, Mission, or App. It can also write back to Snowflake, with every write presented for approval.
* **Snowflake Cortex inference.** Kaiya can run on models hosted in your own Snowflake account, so LLM consumption draws on your Snowflake credits.
Further detail on the rest of the release follows below.
## **π New features**
### **Plan mode for Kaiya Apps**
App chat now runs in one of two modes, and you choose which.
* **Auto** is the default and works the way App chat always has. Describe what you want, approve the plan, and the turn runs through to a saved App β analysis plan, data, view layer, generated code, and the App itself.
* **Plan** stops before any of that. Kaiya reads your schema, works out what the App should be, and writes the App definition. Refine it over as many rounds as you need β nothing is built until you approve.
Because a **Plan** mode turn never queries your source, shaping an App costs no warehouse time.
The mode is set from a pill in the App composer, and it belongs to the whole conversation. Switch to **Plan**, refresh the page, and the conversation is still in **Plan**. Any conversation that has never been set opens in **Auto** by default.
#### **Working in Plan mode**
* **Ask before you build.** Questions about the data are answered in **Plan** mode. Asking what analysis is possible returns a set of options; asking what date range the invoice data covers queries the source and answers it. Neither authors an App.
* **Iterate on the definition**. Each round rewrites the App definition and saves it to the draft, so work carried out in **Plan** mode survives the turn and is still there when you come back.
* **Plan an App that already exists.** An existing App can be switched into **Plan** mode and reshaped (adding sections, converting it to use live queries) with the revised plan shown each round before anything is rebuilt.
* **Follow-up questions and actions.** After a response, Kaiya offers follow-up questions it can answer next, and actions it could build, each phrased as a specific App.
#### **Thought process**
App chat now shows a ***Thought process*** panel with Kaiya's reasoning for the current turn, and the steps it took: the schema it read, the skills it loaded, the queries it ran, and what each returned. If Kaiya is set up with a reasoning model, the panel also shows that model's thinking live, as Kaiya works through the turn.
#### **The Plan, laid out**
* The **Plan** tab presents an App as pages, sections, and analyses, with a running count of each. Pages can be expanded to show the sections they hold and collapsed again, and the analysis steps that feed the App are listed underneath. Each round of iteration updates the counts, so the effect of a change is visible before the App is built.
* The **Plan** also shows which analysis powers which part of the App. Each section is tied to the analysis step behind it, so before anything is built you can see where a given number on the page will come from.
* While you are revising an App that has already been published, the **Plan** on screen is the active version's. A new draft version is created at the point a new **Plan** is written, not before.
#### **Moving to a build**
Building always happens in **Auto**. When you are satisfied with the plan, choosing to build switches the conversation to **Auto** and starts the build. Asking for it in conversation does the same (you can say "ok, build it") and Kaiya switches the mode itself, without you touching the pill.
Where Kaiya makes that switch on your behalf, the build is put to you for approval first, for the rest of that turn.
#### **Reviewing a plan**
A Plan review has three outcomes:
* Approve it and the build proceeds.
* Cancel it and every tier is restored together (plan, data, views, and code) so an app is never left with a plan describing one thing and data describing another.
* Ask for a change, and the plan is revised and re-shown with the change named.
{% hint style="warning" %}
If you cancel a build that Kaiya switched modes to run, the chat goes back to Plan mode. Kaiya never changes a mode you picked yourself.
{% endhint %}
#### **Apps get publish-based versioning**
Previously each edit produced a version. Changes are now collected in a draft instead, and a version is created only when you publish, either from chat or from the interface. A version can also be given a name of your own in place of the date-and-time label, which makes a particular version easier to identify later.
The most recently published version is the **Active** one. Moving to an earlier version is an explicit switch, and that version then becomes the active one shown in the App chat.
Kaiya prompts you to publish at logical checkpoints. The interface also offers the option once an App has produced its first screen, so a working state is captured rather than overwritten by the next edit.
### **Deep Insights runs as a single agent**
Kaiya now runs a review pass over the work it produces before that work reaches you.
* Where automatic Business View selection finds several strong candidates, Kaiya narrows the choice using the other tools available to it and continues the conversation with that Business View in context.
* A Deep Insight is now planned, run, and checked by one agent rather than passed between several.
* Because the agent that writes the plan is also the one that runs it and sees what comes back, it can act on what it finds. It explores the data before planning, revises the plan when a check raises a problem, and repairs an incorrect step rather than starting over.
**Before planning.** The agent establishes what the data actually holds β whether the columns the question needs are present, and what values they carry. Where the data is missing, or several columns could satisfy the question, it asks you clarifying questions.
**While planning.** The plan is built one step at a time and appears as each step is ready, rather than arriving complete at the end. A longer analysis therefore starts showing its shape sooner.
**Before running.** The finished plan is reviewed for analytical soundness. Where a problem is found, it is revised and reviewed again before anything executes.
**While running.** Where a step fails, only that step is rewritten. The rest of the plan is kept and the analysis continues from there.
**After running.** The results are reviewed against the question that was asked. Where they do not answer it, the analysis is revised.
### **One space for Kaiya**
Conversations, Apps, and Missions are no longer separate places you decide between before you start. You can create a Mission or App right from the conversation.
Ask a question. When the answer suggests something worth keeping, ask for an App or a Mission and Kaiya opens a fresh thread scoped to that work β carrying a summary of the conversation across, shown to you, so you can see exactly what context came with it. You do not need to choose the surface up front; you follow the work and Kaiya takes you there.
After an answer, Kaiya offers the follow-ups that apply to that specific analysis such as drilling into the underlying data, creating an App, creating a Mission, or exporting to PDF or PowerPoint.
Chat history is unified in a single view rather than held separately per surface, so what you did in one place is available when you pick it up in another.
### **A single agent runs App creations**
App creation and editing are handled by one agent rather than passed between separate systems.
* It is the agent you talk to, and it spins up sub-agents for the parts of the work that need them: writing the app definition, planning the Deep Insights, generating the plan code, and generating the front-end code.
* Because the conversation and the coordination sit at one layer, the Agent can move between those capabilities on its own as your request changes, without handing you off or starting over.
* It can query your data directly. The agent is not limited to delegating. It can run its own queries to explore what the data holds, check a distribution, or test an assumption before committing to a plan. This means a question about your data can be answered on the spot without building anything, and a plan can be written against what the data actually contains rather than what it was assumed to contain.
* It knows when not to build. The agent holds guidance on what a Live App is and when one is not the right choice, so it can raise a concern rather than build something unsuitable.
* Kaiya builds and updates an App in small steps, so a single request can add new parts and change existing ones at the same time.
* It repairs what it can. Where a step fails (in the Deep Insights analysis or in code generation) the agent attempts to resolve it before involving you or waiting for you to select **Fix it.** Where it cannot, the error is surfaced to you.
### **Tellius as an MCP client**
The Tellius MCP server, introduced in 6.3, lets an external client such as *Claude Desktop* or *Cursor* call into Tellius. 6.4 adds the opposite direction: Tellius is now an MCP client. Kaiya can query the MCP servers you have connected and bring their data into an analysis.
* **An MCP server as an input step:** Until now, the only way to bring data into a Deep Insight, Mission, or App was a SQL query against your data sources. A connected MCP server can now do that job as well.
* **Kaiya queries the server directly and saves what comes back.** This saved result becomes a step in the plan, and the steps after it read from that step. Saving the result, rather than holding it in the conversation, is what allows a large set of records to be used. A Mission can pull the open opportunity list from your CRM, and a later step can summarise that list or write it into an export.
* **Writing back:** Kaiya can write to a connected MCP server as well as read from it, and Snowflake is supported for both. Every write is presented for review and executed only once approved. Each time, in conversation, in Apps, and in Missions alike, including part-way through a Mission run. The write is performed as the connecting user rather than under a shared identity.
* **Clear handling when a server is not connected:** Asking Kaiya to search a system you have not connected or authorised returns a message asking you to connect it.
### **Snowflake Cortex inference**
Kaiya runs on models from OpenAI, Anthropic, Google etc. It now also runs on models hosted in Snowflake through Cortex Inference.
For teams that would rather keep model execution inside their own Snowflake account, Kaiya can be configured to use it β which means LLM consumption draws on Snowflake credits already committed, rather than a separate model spend.
### **A new workspace for building, testing, and publishing a Mission**
Building a Mission now happens in a single, redesigned screen. Kaiya sits on the left as a conversation, and the Mission is on the right across four tabs: **Steps, Preview, Triggers,** and **Schedule.** Kaiya can now also detect the right Business View from the request itself, and the selector remains available when you want to set it yourself.
* **Outline** lists the steps in order, which suits reading a plan from start to finish.
* **Diagram** lays the same plan out as a map, drawing an arrow from each step to the steps that consume its result and naming the output each one produces. A Mission that branches, or one where a Python step draws on two earlier queries, is more readily followed in this form.
* The **Preview** tab goes further than showing the finished artifact. It runs the plan and shows what each individual step returned, before you publish anything. Each step is listed with a completion mark, and the generated summary appears underneath in full, with citations on the figures it reports. You can therefore check that a Mission produces the right answer while it is still a draft.
* The name, description, triggers, and schedule can all be edited from the conversation rather than the tabs.
* Asking Kaiya to send the report to a colleague adds that recipient, and asking it to also send to Slack or Teams enables that channel. Kaiya confirms each change in the thread. The description stays auto-generated and current as the Mission evolves.
#### **Debug the Mission from the conversation**
The Debug Assistant helps you work out why the Mission you are building behaves the way it does. In 6.4 you reach it inline: ask a debug question directly in the Mission conversation, without opening a separate mode.
* Replies in debug mode are not saved to your Mission and do not affect the planner, so a draft can be examined without altering it.
* Debug assistant opens with a set of starting questions covering the checks most often needed: whether the output is correct and which step is responsible, why a run is slow, whether the figures can be relied on, and how Kaiya approached the analysis. You can also ask your own question about the draft.
* Asking a question of a finished Mission run shows the working behind the reply β the steps that ran, the query behind each one, and what it returned. A response that does not match expectations can be traced to the step responsible.
#### **Every published version is kept**
* A Mission previously held one published version and one draft. It now retains each version you publish.
* A selector in the header lists them with the date and time each went live, and marks one as Active.
* You choose which version is active, and that's the one every run uses, whether you start it yourself or it runs on a schedule. Because earlier versions are retained rather than replaced, you can see how a Mission changed over time and which version produced a given briefing.
* A Mission previously ended at a single summary step, so every branch had to converge on the same conclusion and the wording had to cover all of them at once.
* A branched Mission can now end with a summary or artifact per path or step, letting each branch report its own finding.
* Run history is available from the Mission header. It lists every run with its date, duration, and how it was started, alongside the total number of runs, the success rate, and the average duration.
### **Export and import a Mission or an App**
A Mission or an App that works in one place can now be moved to another.
A Mission validated in a test environment can be promoted to production without being rebuilt there. A Mission built for one team can be handed to another running on a comparable Business View. And a package built once can be reused across tenants, rather than each one starting from an empty workspace.
The export carries the whole object, not just its definition. For a Mission, this includes the plan, the summary, the versions, and the chat. For an App it means the App definition, the Deep Insights plan, the generated code with its versions, and the chat. Apps that are not live also hold their own data, and those datasets travel with the export, so an imported App renders without being rebuilt.
### **Content Admin role**
A Content Admin role gives designated users standing read and edit access to all Datasets, Business Views, Vizpads and Kaiya assets β including content that already exists.
The role extends to Kaiya objects as well as Datasets, Business Views, and Vizpads, so a Content Admin can see and manage Kaiya content across the platform under the same standing access.
Content access previously came only from explicit ownership or manual sharing, so when a user left or changed teams their content could become orphaned with no one able to maintain it. A Content Admin can always see and manage content across the platform, which makes off-boarding a matter of reassignment rather than recovery.
### **Cross-datasource swap**
Datasource swap previously worked only between the same type such as Snowflake to Snowflake, MySQL to MySQL. It now supports cross-datasource migration, such as Snowflake to Redshift or MySQL to SQL Server, and is designed to accommodate further combinations.
Schema compatibility is validated before the swap completes. Where the target lacks a required column or a data type differs, a clear message describes the mismatches so they can be resolved. A force-swap path is available where a mismatch is understood and accepted.
### **Industry Packs**
An admin/superuser can now publish a library of ready-made Apps and Missions for a team to start from.
Industry Packs are configured under **Settings β Kaiya and AI β Industry Packs**. A Super User creates as many packs as needed, enables or disables each one, and adds App templates and Mission templates to them. A template is an exported App or Mission, so any App or Mission that already works can be turned into a starting point for others.
**Creating an App or a Mission now offers two paths:** start from scratch, or start from a template. Choosing a template shows the packs enabled for your workspace and the templates each one holds.
**Matching a template to your data.** A template was built against a particular Business View, which may not be the one you have. On import, Tellius matches by Business View name, Business View ID, and the underlying datasets, and reports how closely the columns match. Where the match is strong, the App or Mission builds in seconds. Where it is weak, you are told before the build begins and can proceed anyway β the conversation then asks about the parts it could not resolve, and **Fix with Kaiya** works through them.
This also gives a route between environments: a template exported from a development workspace can be uploaded to production rather than rebuilt there.
## π Enhancements
### **Kaiya**
Summaries answer the question asked. The Summary Agent now answers what was asked and stops. Where data is not found, that is stated clearly at the top of the response rather than within it. Database statistics, SQL fragments, and format analysis are kept out of end-user summaries.
Metadata questions without a Business View selected. Questions about the data itself are now answered when no Business View has been selected. Asking what data you have access to returns a summary of the Business Views available to you. Asking what metrics a particular Business View holds returns those metrics, without needing to select it first.
Upload a document or image to Kaiya chat. A file can be attached to a Kaiya conversation and asked about directly.
An uploaded file previously went to unstructured handling, and only unstructured could answer against it. Kaiya now decides where the question should go (structured, unstructured, or a Deep Insight) based on what is being asked, so an uploaded file and your Business View data can be reached in the same conversation.
Deep Insights across multiple Business Views. A Deep Insight scoped to three Business Views runs across both rather than prompting the user to choose one.
Where the data needed is missing or several columns could satisfy the question, Kaiya raises a clarification before planning rather than choosing on your behalf.
Previously, only at execution, the plan checked whether data for comparison existed. The check now happens first, so the plan is built against the data that is present. The step appears in the progress messages while a Deep Insight runs.
Row-level permissions across multiple group memberships. A user can belong to several groups, and those groups can each set the same Security Tag to a different value. That combination now resolves to a query that runs, instead of one that stops before it reaches the data.
Multi-fact Business Views on In-Memory. An In-Memory Business View is no longer flattened into a single joined table when it is published. Its datasets are kept as separate tables and joined at the point a question is asked.
Joining everything at publish meant a Business View holding more than one fact table duplicated rows before anyone queried it, so those models could not be supported in memory. Keeping the datasets separate and joining per question removes that constraint, so a Business View holding several fact tables can now be used in memory.
Existing In-Memory Business Views are converted as they refresh. Nothing changes on upgrade; a Business View moves to the new shape the next time it is published or refreshed on its normal schedule.
Time filters reach the query. A date range detected in a Deep Insights question is now passed through to the steps that follow. The query therefore filters on the range you asked about, rather than one fixed when the plan was written.
Credits on a custom window. Credit limits can be tracked against a configurable start and end date β a contract year, for example β rather than a fixed calendar window. Counters, thresholds, and alerts operate against that window.
Memory is saved when you choose to save it. Kaiya's memory remains explicit, with nothing stored in the background. A correction or a clarification in chat now offers a card to save it, so you decide what is kept. You can also ask Kaiya to remember something directly. Duplicate entries are consolidated rather than accumulating, the memories applied to a given answer are shown in the thought process, and a memory agent can report what is stored.
Recent items reflect active work. The Recent list is built from meaningful interactions such as editing or actively working with a conversation, rather than from every conversation that was opened and viewed.
Custom prompts are identifiable. System Settings distinguishes default prompts from customised ones, listing updated prompts separately so changes are visible at a glance.
Concurrent Skills edits. Two people, or one person in two browser tabs, can now edit Skills on the Context page without losing work. If a second save is based on an older version of the skill, it is reported rather than replacing the newer one.
### **Missions**
Briefings for manual runs. Briefings now appear for manually triggered runs as well as scheduled ones. This covers a run started from the Run button and a run started from a Kaiya conversation. A Mission's output history is therefore complete regardless of how each run began.
Provenance in chat. When a Kaiya answer came from a Mission, the answer names the Mission, the version that ran, and how it was started β Scheduled, Chat, or Run manually. The Mission name and an arrow control open that Mission directly.
**Inline editing of Mission steps**
Every part of a Mission plan can be edited in place, and your edits are applied together when you are ready rather than one at a time as you type.
Collecting the edits and applying them in a single pass keeps the Mission under your control while you shape it. A plan needing many small corrections is revised as one change, and the apply cycle runs once rather than once per field.
### **Kaiya Architect**
Multiple CSV upload. Several CSV files can be uploaded at once, creating a separate dataset for each.
Progressive disclosure of skills. Data Architect's single large system prompt is separated into discrete skills, with new guidance covering non-live sources in a multi-fact Business View.
Incremental thinking. Reasoning streams in progressively, the accordion expands automatically, and tool status is highlighted as work proceeds.
Join validation for datasets that are not live. Join coverage could previously be checked only for live datasets, because the check runs as a query against the source. Datasets that are not live are now loaded temporarily while the conversation is still in progress, so by the time you reach the join decision the same data-backed validation is available.
Suggested questions as links. Suggested questions render as clickable links.
Ask analytical questions before the Business View is published. Once Architect has produced a Business View plan, you can query it directly without publishing first. Questions run against the drafted model and return charts and tables in the analytical panel alongside the conversation.
Architect also generates a set of business metrics from the plan automatically, running a few analytical queries over the model so you can see representative KPIs as soon as the plan exists.
Because results are visible at plan time, a modelling problem surfaces before publication. Asking why a figure looks wrong prompts Architect to investigate the joins behind it, explain what it finds, and set out the options for fixing it β including restructuring the plan into separate Business Views with a soft link where a single joined view would inflate the totals. The revised plan replaces the original, and the same question can be re-run against it.
A final health check runs at publication, executing the metric queries once more against the published Business View.
A structured view of the model. The ML tab previously presented the raw model, which was difficult to read at a glance. A structured explore view now lists the Business Views with whether each is live and how many columns it holds. Opening one shows its columns with display name, data type, role, and source dataset, alongside calculated columns, date mappings, and dynamic parameters. A Datasets tab lists the connected datasets with their source, whether each is a fact table, and whether it is live. Where Architect has not yet produced a Business View, the connected datasets are shown on their own. The existing raw view is unchanged.
### **Kaiya browser extension**
Automatic routing to Deep Insights. Questions needing multi-step analysis route to Deep Insights automatically. A running status appears in the current view, with a link to open the full report when ready.
Charts in the panel. Charts render and persist in the extension. Where a chart is too large for the embedded view, a link opens it in a full tab.
Query context. The selected domain is passed by default for both automatic Business View selection and user query context. Uploaded images are treated as additional context for follow-up questions about a specific chart.
### **Kaiya Apps**
A single planner. Live and non-live planning run through one planner, so a non-live App refresh executes its existing plan rather than regenerating the SQL step.
Stable table names across refresh. Business Views carry a stable view name that is repointed at the latest underlying table on each save. Plans, queries, and Apps referencing a Business View continue to resolve after a refresh.
Where a remixed App came from. A remixed App links back to the App and version it was remixed from. If that source or its version has since been removed, the link explains why it is unavailable.
Narrative length is configurable. The maximum length of a generated narrative in an App is set through a runtime configuration option with its own interface control.
Clearer App creation flow. Once an App is generated, the interface says so and offers a link to open it alongside an option to create another, rather than repeating the original call to action.
### **Data and administration**
* Business View CSV download. A download that ends early now explains why. The notification offers a Download action in place of View, and states that the exported file is retained for five hours, after which it is cleared.
* Snowflake key pair guidance. The Public Key field carries a tooltip and supporting documentation explaining how to register the key in a Snowflake account, following Snowflake's policy of collecting public keys rather than private ones.
* Credit alerts and defaults. Credit usage alerts are sent as consumption rises past each further five percent, and the total credit allocation along with the per-user default can be configured directly.
* Multiple help videos and articles. Settings supports configuring several help videos and articles rather than one of each, with independent titles and URLs, surfaced on the Help & Support page.
* Left navigation. The left navigation is limited to five primary items β Context, Mission, Vizpad, Data, and Apps β with anything further under More. "Kaiya Architecture" is corrected to "Kaiya Architect", and labels are aligned with the pages they open.
### **Performance**
Long-running summary steps stay contained. A Summary step working over a very large result set is bounded, so it completes without holding up other work running at the same time.
Streaming Excel export for pivot tables. Pivot table Excel export writes rows to the workbook as it goes rather than holding the whole set in memory first, so large pivot exports complete without straining the server.
Dataframe loading. Dataframe loading performance is improved, including in the App archive and unarchive flow.
Live Narratives are cached and cleared. Narratives generated live in an App are stored, then removed automatically once they age out, so repeat views render without regenerating while storage stays bounded.
Faster tab and view switching in Vizpads. Switching tabs, changing view, entering edit mode, and saving are quicker, with background work removed from those interactions.
### **A redesigned home page**
The home page now opens onto the work already in progress rather than an empty starting point.
Chat history in one place. The standalone Kaiya page has been retired, and chat history is now unified in a single view rather than held separately per surface (Mission/App).
Suggestions that follow your work. The suggested section is built from what is already there, in order: a scheduled briefing due, then existing Missions, then the option to create a new one. Apps follow the same pattern β existing Apps first, then templates to start from.
## π»Deprecations
### **The Classic Editor for Missions is retired**
A Kaiya Mission is an analytical workflow that several agents carry out together. That has not changed, and Missions are not going away. What changes in 6.4 is how you build one.
In 6.3 a Mission could be authored two ways. You could describe it to Kaiya in conversation, or use the form-based Classical Editor, filling in each part on its own. An administrator setting decided which of the two a user saw. 6.4 settles on the conversational path. Every new Mission is now built by describing what it should do, and the Classic Editor is retired.
Missions built in the Classic Editor remain in place. Opening one shows its name, description, Business View, triggers, and steps as read-only reference, so the record of its configuration is preserved. These Missions are filtered out of the Mission Library by default, and a Type filter brings them back into view when you need them. That list is scoped to the people who own those Missions rather than shown to everyone. The "Classic Editor" and "Mission Editor" labels are removed throughout, and trigger phrases in Kaiya now resolve against Missions built in the current editor.
### **Learnings is being retired in favour of Memory**
Learnings and Memory both hold context Kaiya carries between sessions. Learnings has been read-only for some time and is now being withdrawn. The integration is removed from the modules that used it, and a note in the interface marks it as deprecated ahead of removal in the following release. Existing Learnings can be moved into Memory so nothing is lost.
### **Vizpad Classic mode is retired**
The Switch to Classic Mode option is removed from both the Vizpad interface and the Vizpad Configuration page. Vizpads always open in Modern mode, and Modern mode downloads are enabled by default.
Agentic Workflows is retired
"Agentic Workflows" is no longer used. Where the term appeared alongside Missions, the single term Agent now covers it. There is no separate Agentic Workflow concept to configure or migrate.
## **π οΈ Minor fixes**
### **Kaiya**
1. Improved the Plan view so it uses the full available width.
2. Improved PowerPoint export from a Kaiya conversation in three ways. Text now renders inside the slide boundaries. The number of slides is matched to the length of the conversation rather than to the template, so the deck length reflects the conversation. Where the available data does not support what was asked for, that is reported before the deck is generated.
3. Improved the Jump to Latest control so it navigates to the most recent query. Scroll behaviour during Deep Insight and Mission runs was also refined, so that newly generated steps do not pull the view away while earlier content is being read.
4. Improved conversation sharing so conversations shared before the current sharing model continue to appear for their recipients.
### **Missions**
5. Improved the Mission run action. Starting a Mission from either the listing page or the detail page now opens the Kaiya conversation with the Mission details rendered. The execution status updates in that conversation as the run proceeds.
6. Improved the layout of the Configuration surface. The header, banner, tab strip, titles, and step list now share the same left alignment. Each tab's view switch sits on the same row as its title rather than dropping to its own line. The artifact panel is labelled for the artifact it contains rather than repeating the tab name above it.
7. Renamed the Visuals tab to Artifact, and the tab is presented only when an artifact exists.
8. Improved the Mission listing and detail actions, with Create Mission as the primary action, View Schedules alongside it, and Configure and Create Schedule grouped under the overflow menu.
9. Applied the current design system to Mission briefings and conversation components.
10. Improved the Started At time on the run page so that it shows the moment the run was triggered. Query metadata was also refined, so that a query's updated timestamp changes only when the query itself is edited.
### **Apps**
11. Improved version handling so removing a KPI from a tab does not remove the tab, and analysis steps remain visible and current across versions.
12. Improved the App tab so it reloads after an App is published or its active version is switched. Neither action rewrites the App's generated code, so the tab previously continued to show the earlier version until the page was refreshed.
13. Resolved an issue where an App could render incorrectly immediately after a code update and correctly again once the page was refreshed. The generated code and the view definitions it renders against are now confirmed to be in step before the App is displayed.
14. Resolved an issue where the plan review card could fail to display when an App contained an unnamed section.
### **Vizpads**
12. Extended number formatting in Excel export to calculated columns, so decimals, currency, percentage, separators, prefixes, suffixes, and trailing zeros are carried over as they are for regular columns.
13. Improved table export to PowerPoint and PDF so a compare-filter measure renders its compare column.
14. Improved Vizpad stability so chart positions are retained and filters remain in place.
15. Improved column header behaviour so a tooltip shows the correct column name where a display name matches another column's original name.
16. Improved the quarter-to-date time filter so that it selects the expected number of days.
17. Improved column renaming so a new name is reflected when switching to table view and in the chart title, without a page reload.
18. Improved null-value filtering so it behaves consistently across the Equal and IN operators.
### **Data**
19. Improved connector search when connecting a Databricks Delta Lake datasource.
20. Improved dataset import so a Snowflake source using OAuth or key pair authentication can be created as a new source on import.
21. Improved the datasource delete dependency view so it lists Business Views, Vizpads, and insights from consolidated datasources alongside their datasets.
22. Improved notification accuracy so a completed data load is not reported as still running.
23. Improved decimal handling so high-precision numeric values are stored at their exact value rather than being narrowed to a floating-point approximation.
24. Improved CSV upload so a single upload reports a single completion notification.
25. Improved folder deletion on the Prepare page so the confirmation dialog can be dismissed, and ensured the confirmation appears on the Business View page.
### **Administration and access**
26. Improved SSO logout so a user returning to the login page is redirected to the configured SSO provider where automatic SSO login is enabled.
27. Improved routing so an unrecognised login URL resolves to the login page, and an embedded link that carries no campaign source parameter resolves to its intended page.
28. Improved project sharing so the project owner retains access to a Vizpad moved into the project by a shared user.
29. Improved the conversation window so it can be reopened after it is closed.
30. Improved custom view sharing so a shared view carries edit access by default, simplifying the share and revoke flow.
31. Improved Vizpad and Business View access so a Vizpad shared in edit mode stays reachable when the original recipient is removed and access is reassigned.
32. Improved session handling so signing out and back in from one browser tab keeps the other open tabs working.
33. Improved the Kaiya Apps chat panel so the bottom-right controls collapse into an overflow menu when the panel is narrow.
34. Improved App chat so history is held for the session and earlier messages load immediately.
35. Improved the archive flow so a remixed App can be unarchived in the same way as any other App.
36. Improved conditional and gradient formatting so both are carried into PDF, PowerPoint, and Excel export, including individual chart, tab-level, and Custom View exports.
37. Improved pivot table export so a requested row range beyond the available rows returns a clear message rather than an empty file.
38. Improved pivot table grand totals so null values are handled according to the include-nulls setting.
39. Improved the Share control so it is presented to users with the Discover role.
40. Improved job handling so a job that stops part-way through is reported as such rather than leaving a progress indicator running.
41. Improved Python step repair so a step beyond automatic repair reports that plainly, rather than continuing with placeholder data.
42. Improved Redshift write-back for columns holding longer values.
43. Improved usage records so sign-in activity is attributed to the correct user.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.tellius.com/whats-new/release-6.4.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
