> 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/plan-and-auto-modes-in-app-chat.md).
# Plan and Auto modes in App chat
Shape a Kaiya App in Plan mode before anything is built, then build it in Auto mode and publish versions.
App chat is the conversation where you build and change a Kaiya App. It runs in one of two modes, and you choose which. **Auto** builds the App once you approve the plan. **Plan** works out what the App should be and stops there, so you can settle its shape before anything is built or run.
Use **Plan** when you want a say in the design before Kaiya builds. A build runs queries on your warehouse and takes a few minutes, so agreeing on the plan first means you build once and get the App you want. This page explains both modes, how to read the plan, how to move to a build, and how publishing creates versions of your App.
### **The two modes**
* **Auto** is the default. It works the way App chat always has. Describe what you want and approve the plan. The turn then runs through to a saved App: the analysis plan, the data, the views, the 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.
{% hint style="success" %}
**Benefit:** Writing and refining the App definition in **Plan** mode does not build data, views or code. Shaping an App this way costs no warehouse time.
{% endhint %}
### **Choose a mode**
The mode is set from a pill in the App composer. The pill sits at the left of the composer, ahead of the Business View selector. Select it to open a menu with a short description of each mode, then choose **Plan** or **Auto**. While **Plan** is on, the pill is highlighted, so you can always see that builds are on hold.
* **The mode belongs to the whole conversation.** Switch to **Plan**, refresh the page, and the conversation is still in **Plan**.
* **New conversations start in Auto.** Any conversation that has never been set opens in **Auto** by default.
* **You can also ask in words.** For example, say *"just plan it for now"* to work in **Plan** mode.
### **Shape an App in Plan mode**
1. Open App chat. For the ways to start an App, see [How to create a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-create-a-kaiya-app). To work on an App you already have, open it and select **Open app assistant**, the chat icon at the left of the **Plan**, **Analysis** and **App** tabs. This opens the App's own conversation, with the App in a panel beside it.
2. Select the mode pill and choose **Plan**.
3. Describe the App you want. Kaiya reads your schema, works out what the App should be and writes the App definition.
4. Review the result in the **Plan** tab. See [Read the Plan tab](#read-the-plan-tab).
5. Ask for changes. Each round updates the plan.
6. When you are happy with the plan, build it. See [Move to a build](#move-to-a-build).
#### **Ask before you build**
You can ask questions about your data in **Plan** mode. Neither kind of question below creates an App.
* **What is possible.** Ask what analysis is possible, and Kaiya returns a set of options.
* **Facts about the data.** Ask a question such as what date range the invoice data covers. Kaiya queries your source and answers it.
#### **Refine the definition over several rounds**
Each round rewrites the App definition and saves it to the App's draft. Work you do in **Plan** mode survives the turn and is still there when you come back.
#### **Plan an App that already exists**
You can switch an existing App into **Plan** mode and reshape it. For example, add sections, or convert it to use live queries. Kaiya shows the revised plan each round before anything is rebuilt. For more on live queries, see [Live data in Apps](https://help.tellius.com/kaiya/kaiya-apps/live-data-in-apps).
While you revise an App that has already been published, the plan on screen is the active version's plan. A new draft version is created when a new plan is written, not before.
#### **Follow-up questions and actions**
After each response, Kaiya suggests what you could do next, in two groups:
* **Follow-up questions** are questions about the data that Kaiya can answer in the chat. They don't change the App.
* **Actions** are changes Kaiya could make to the App, each written as a specific request. After a change has been saved as a draft, one of the actions is often to publish it.
Selecting a suggestion works the same as typing its text in the composer. When Kaiya has more suggestions than it lists, a link such as **Show 2 more** reveals the rest.
### **Read the Plan tab**
An App's page has three tabs: **Plan**, **Analysis** and **App**. An App opened in the panel beside the chat shows the same tabs in the same order.
The **Plan** tab lays out the App before it is built. Read it from the top down:
* **Purpose.** The first lines say what the App is for, then how it is put together and how a reader moves through it.
* **Counts.** A short line gives the number of pages, sections and analyses. Each round of changes updates the counts, so you can see the effect of a change before the App is built.
* **What it's for.** The goals the App is meant to meet, one per line, followed by **Audience**, the kinds of people the App is designed for.
* **Pages & Sections.** Each page of the App, with its name and a description of what it shows. Select the arrow at the right of a page or section to collapse it, and select it again to expand it.
Each section in a page has a number, a label for the kind of section it is, such as **KPI**, **CHART (BAR)**, **CHART (LINE)** or **TABLE**, and a name. Under the name:
* **Summary** describes exactly what the section will show: which measures, how they are grouped and sorted, and how values are formatted. Select the copy icon to copy the summary, for example to paste it into a request for a change.
* **Data from** names the analysis that supplies the section's numbers. Before anything is built, you can see where each number on the page will come from.
At the bottom, **Analyses** lists every analysis the App uses. Expand one to read what it computes from your data.
On older Apps, the **Plan** tab shows the plan as formatted text, with headings and bullet lists. A version that has no plan to show displays **No Plan Available**.
To copy the whole plan as text, open the App's three-dot menu and select **Copy**, then **Copy Plan**. **Copy Code** copies the App's generated code.
### **See what powers what in the Analysis tab**
The **Analysis** tab shows the steps that produce the App's data. It has two views.
* **Outline** lists the analysis steps in order. Each step shows its number, its type, such as **SQL**, and a one-line description. Expand a step to see **What this step does** in plain words. Expand **Sql instructions** to read the query the step runs. The bottom line names the step's **Output** and the **Business View** it reads from.
* **Diagram** draws the same steps as a flow, from left to right. The Business View feeds each step. Each step produces a view, and each view feeds an App section. Follow a line to see which data ends up in which part of the App.
### **Follow Kaiya's work in the Thought process panel**
App chat shows a **Thought process** panel with Kaiya's reasoning for the current turn. It also lists the steps Kaiya took:
* the schema it read
* the skills it loaded
* the queries it ran, and what each one 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 panel has a set height and scrolls. While Kaiya is working, it follows the newest content. Select the panel's header to expand or collapse it.
### **Move to a build**
Building always happens in **Auto**. You can start a build in two ways:
* **Choose to build.** When you are happy with the plan, choosing to build switches the conversation to **Auto** and starts the build.
* **Ask for it.** Say *"ok, build it"* in the conversation. Kaiya switches the mode itself, without you touching the pill.
When Kaiya makes that switch for you, it asks you to approve the build first. This applies for the rest of that turn.
#### **Review the plan before the build**
Before a build, Kaiya shows the plan for your review and asks what you want to do with it. Your answer is kept in the conversation, so you can see later what you approved. You have three choices:
* **Approve it.** The build goes ahead.
* **Cancel it.** Every part of the App is restored together: the plan, the data, the views and the code. The App is never left with a plan that describes one thing and data that describes another.
* **Ask for a change.** Kaiya revises the plan and shows it again, naming the change it made.
{% 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 %}
### **Publish and manage versions**
Your changes collect in a draft. A version is created when you publish. Until then, people you share the App with keep seeing the version that is already published, so you can keep working without changing what they see. After a change, Kaiya tells you when it was saved as a draft and which version is still live.
You can publish in three ways:
* Ask in the chat, for example *"publish the App"*.
* Select a publish suggestion under **Actions**.
* Open the App's three-dot menu and select **Publish**.
Some things to know about versions:
* **When to publish.** Kaiya prompts you to publish at logical checkpoints. The interface also offers to publish once an App has produced its first screen. Publishing then captures a working state, so the next edit does not overwrite it.
* **One draft at a time.** An App has at most one draft. A published version cannot be changed, apart from its name and description.
* **The active version.** The active version is the one people see when they open the App. The most recently published version becomes the active one.
#### **The version menu**
Select **Version** at the top right of the App to list its versions, newest first. Each version shows its name, a **Published** badge, the date and time it was published, and a description of what changed. The active version also has an **Active** badge, and a check mark shows the version you are viewing.
Select the three-dot menu on a version for these options:
* **Rename version:** give the version a name of your own. See [Name or rename a version](#name-or-rename-a-version).
* **Change description:** rewrite the note that says what the version changed, so others can tell versions apart.
* **Set as active:** make an earlier version the one people see. Use this to go back to a version that worked better. It then becomes the active version shown in the App chat.
* **Remix:** start your own copy of the App from this version. Changes to the copy stay separate from the original, and the copy links back to the App and version it came from.
* **Delete version:** remove the version.
**Set as active** and **Delete version** appear only on versions that are not active, so the version people are using can't be removed by mistake.
#### **Name or rename a version**
Versions are numbered **V1**, **V2** and so on. A version can have a name of your own in place of its number, which makes a particular version easier to find later. You can rename any version, active or not, and it keeps its published state.
1. Select **Version** at the top right of the App.
2. Select the three-dot menu on the version you want to rename.
3. Select **Rename version**.
4. Type the new name in **Version Name** and select **Save**. Select **Cancel** to keep the old name.
Tellius confirms with the message **Version renamed successfully.**
{% hint style="info" %}
Tellius keeps a set number of versions for each App, 10 by default. When an App passes that number, its oldest versions are removed. The active version and an App's last remaining version cannot be deleted.
{% endhint %}
### **Best practices**
* **Plan large Apps first.** The bigger the App, the more a build uses warehouse time and minutes. Settle the plan in **Plan** mode, then build once.
* **Use Plan mode before a big change to an existing App.** Adding sections or converting an App to live queries is easier to judge from the revised plan.
* **Check where the numbers come from.** Read **Data from** on each section, or the **Diagram** in the **Analysis** tab, before you approve a build.
* **Publish working states.** Publish when Kaiya suggests it, or once the App has its first screen, and give versions you may return to a clear name and description.
### **Related pages**
* [Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps)
* [How to create a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-create-a-kaiya-app)
* [How to customize a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-customize-a-kaiya-app)
* [Anatomy of a completed app](https://help.tellius.com/kaiya/kaiya-apps/anatomy-of-a-completed-app)
* [Live data in Apps](https://help.tellius.com/kaiya/kaiya-apps/live-data-in-apps)
* [Mastering prompts for Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps/mastering-prompts-for-kaiya-apps)
* [Kaiya Skills](https://help.tellius.com/kaiya/kaiya-skills)
---
# 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/plan-and-auto-modes-in-app-chat.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.
