> 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/tellius-6.4/kaiya/kaiya-apps/apps-built-before-tellius-6-4.md).
# Apps built before Tellius 6.4
Open an App built before Tellius 6.4 in the Unified Chat, see how its earlier messages carry over, change it in a draft, review its versions and publish when you are ready.
Apps you built before Tellius 6.4 keep working as they are. You don't need to rebuild them. In Tellius 6.4 you open them, ask questions about them and change them in the Unified Chat, the same Kaiya conversation you use for everything else, with the App open in a panel beside it.
{% hint style="info" %}
In releases before Tellius 6.4, each App had its own small chat pane on the App page, with the hint text **Ask a question about your app...** in its message box. That pane is replaced by the Unified Chat. Your earlier App conversation is not lost: it opens in the Unified Chat with the App.
{% endhint %}
### **Open an older App in the conversation**
1. Select **Apps** in the left navigation and open the App.
2. Select **Open app assistant**, the chat icon at the left end of the **Plan**, **Analysis** and **App** tabs. You can also open the App's three-dot menu and select **Open in chat**.
3. The App's conversation opens. The App's earlier messages are on the left, and the App is in a panel on the right.
The App page itself still has its other controls, such as **Remix**, the **Version** list, the refresh menu and the expand icon, which opens the App in a new browser tab.
### **How earlier messages look**
Messages from before Tellius 6.4 carry over into the conversation, but they look a little different from new ones:
* They show as plain text, without the Kaiya icon beside them.
* They have no **How Kaiya got this** panel, no **Based on** line and no **Open App** card.
* Their suggestions still appear under **FOLLOW-UP QUESTIONS** and **ACTIONS**.
New messages use the full layout. While Kaiya works, a status line shows what it is doing and how many steps it has taken so far, for example **Saving the app**. When it finishes, **How Kaiya got this** shows the steps it took and how long the turn took.
Kaiya has the context of the earlier messages. It reads the conversation history when it needs it and works from the App's existing plan, analysis and code. You can refer to something you asked for before, such as a section that needed a fix, without explaining it again.
### **Change the App**
Ask for the change in plain language, for example *"Add a chart for monthly revenue by region."* Kaiya updates the App in small steps, checks the result and tells you what changed.
Your change is saved as a draft. The draft appears in the **Version** list with the next version number and a **Draft** badge, for example **V2**. The version that is already published stays live, so people you share the App with keep seeing it until you publish. Kaiya says so in its reply and usually offers a publish suggestion under **FOLLOW-UP QUESTIONS** or **ACTIONS**.
To publish, select that suggestion, ask Kaiya, for example *"Publish this version"*, or select **Publish** from the App's three-dot menu. See [Publish and manage versions](https://help.tellius.com/kaiya/kaiya-apps/plans-and-versions-in-kaiya-apps#publish-and-manage-versions).
{% hint style="success" %}
**Change the App or Remix it?** Change the App itself when everyone who uses it should get the change: they see it once you publish. Select **Remix** when you want your own variation and the original should stay exactly as it is. A remix is a separate copy that links back to the App and version it came from.
{% endhint %}
### **The App panel beside the conversation**
The panel header holds the App's name and these controls:
* **Version:** shows the version you are looking at. Open it to list the versions, newest first. Each row shows the version number, a **Draft** or **Published** badge, an **Active** badge on the version people see, when it was saved and a short description of what changed. A check mark shows the version you are viewing, and the three-dot menu on a row holds the version options. Select a row to switch to that version.
* **Refresh icon:** refreshes the App's data. It is greyed out while you look at a draft, because a refresh updates the published version. Switch to the published version to refresh.
* **Open full view (expand icon):** opens the App's own page at the version shown in the panel. Use your browser's back button to return to the conversation.
* **Close (x):** closes the panel. The conversation stays open.
Under the header are the **Plan**, **Analysis** and **App** tabs. See [Plans and versions in Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps/plans-and-versions-in-kaiya-apps).
If the App changes while you have it open, for example when Kaiya saves a new draft, a banner at the top of the panel says the app has changed since you opened it. Select **View latest** to load the newest version.
{% hint style="info" %}
**Which version am I looking at?** After Kaiya saves a draft, the panel can still show the published version until you select **View latest** or pick the draft in the **Version** list. Check the version number in the header before you judge a change.
{% endhint %}
### **The Artifacts panel**
The narrow toolbar on the right edge of the screen has a stacked-layers icon. Select it to open **Artifacts**, which lists what this conversation has produced, grouped by kind, such as Apps, Missions and files. Each item shows when it was last changed. Select the open icon beside an App or Mission to open it, or the download icon beside a file to save it. Select the **x** to close the panel.
### **Refresh the App's data on a schedule**
On the App's own page, select the refresh icon to open its menu:
* **Refresh Now:** refreshes the data straight away.
* **Schedule Refresh:** sets the App to refresh on its own, at the frequency, day and time you choose.
* **Refresh History:** lists the refreshes that ran.
You can also ask in the conversation, for example *"Refresh this app every day at 6 a.m."* See [How to customize a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-customize-a-kaiya-app#refreshing-data-on-a-schedule).
### **Best practices**
* **Open the App before you ask.** Starting from **Open app assistant** gives Kaiya the App's plan, analysis, code and earlier conversation, so it changes the existing App rather than building a new one.
* **Review the draft before you publish.** Switch the panel to the draft, read the **Plan** tab and check the numbers. Viewers keep the published version until you publish.
* **Publish working states.** Publish once a change works, so the next change doesn't replace a version you want to keep.
* **Describe each version.** Use **Change description** in the version menu so others can tell versions apart.
### **Related pages**
* [How to customize a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-customize-a-kaiya-app)
* [Plans and versions in Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps/plans-and-versions-in-kaiya-apps)
* [How to create a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-create-a-kaiya-app)
* [Missions built before Tellius 6.4](https://help.tellius.com/kaiya/kaiya-missions/missions-built-before-tellius-6-4)
---
# 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 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/tellius-6.4/kaiya/kaiya-apps/apps-built-before-tellius-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 `automate deployments from our CI pipeline` 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.
