Ask for an inline app

Who can do this

Anyone in a Standard or Deep analysis chat — the two modes in which Ronja answers you. You do not need Build mode, and nothing is published or approved. A Build conversation does not offer one, and a Saved Agent, an automation or a Slack or Microsoft Teams reply never makes one. Turning one into a published App later is the one step that needs build access.

Sometimes the useful answer is not something you read but something you poke at: a list you filter, a threshold you slide. An inline app is that — a small interactive app Ronja writes into the conversation in place of her written answer.

It is not an App. An App is published: it lives in a feature, has its own page, and others open it by a link. An inline app lives in this chat and nowhere else — no publishing, no approval, no address to send anyone.

Ask for one

1. Ask an ordinary question, and say what you want to do with the answer. “Show me margin by product — I want to filter by region and change the discount assumption.”
2. Watch the answer column. Ronja writes her finding as text first, then a panel appears marked Building, naming each file as she writes it. When she patches one you already have, the panel says Refining and Patching instead.
3. When it compiles, the panel is replaced by the app itself, marked Interactive. Use it.

You need not ask for one by name: “let me play with it” lands in the same place.

Read the words above it, not only the app

The text before the app is the answer, and it is all anyone else gets: a reader in Slack, or anyone reading the conversation anywhere else, sees the finding, not the app. If the sentence above the frame does not say what you learned, ask her to say it.

It runs as whoever is looking at it

An inline app reads your data live with your own access — not Ronja’s, and not that of whoever asked for it.

That matters when you share the chat. A colleague opening the same conversation gets their own copy, reading as themselves: a table they may not see comes back refused for them and works for you, in the same app. The app shows the refusal rather than breaking, so a panel telling them they cannot reach that data is it working correctly — the wording is the app’s own, and Ronja writes a different one each time.

• Sharing the chat does not share the data. Handing someone the conversation gives them the app, not your reach.
• Outside systems are reached as the reader too. If the app calls an outside API or database, the call goes out with the credentials of whoever opens it — and what that call does there is up to that system, so an app that writes to an outside service writes as each reader.
• What it shows is live. Re-open the chat a month later and it re-queries; the numbers in the text above it are from the day it was written.

Changing it, and branching

Ask for changes in the same conversation — “add a date range”, “sort by margin” — and the app is rewritten in place rather than stacking up beside itself.

If you explore a tangent from a chat that has an inline app, the branch inherits it — but the app itself still belongs to the conversation you branched from. It works for you there. Someone shared only on the branch, and not on its parent, gets This app is not available. in its place. Change it in the branch and the branch gets its own copy, which then opens for them; the original is untouched either way.

Keeping one

An inline app lives and dies with its conversation: delete the chat and the app goes too.

When one is worth keeping, the frame’s header offers Make it an App to readers with build access. It opens a Build-mode branch seeded with the app’s source, where Ronja builds it as an App on its own page; this chat is left as it was. Publishing is your call, as it is for any App: Ronja asks to Publish 1 app and you click Approve — until you do, it is a draft only you can see. If the button is not in your frame, you do not have build access — a colleague who does can open the same conversation and click it.

That is where the access story changes too: a published App has one set of powers shared by everyone who opens it; an inline app gives each reader only their own. If the point was that people see different things, keep it inline.

What an inline app is not for

• A second screen. One view, one thing to interact with. More than that is an App.
• Changing anything in Ronja. It reads; it cannot change a table, send mail, or run a workflow.
• A number, a comparison, a trend or a ranking. Those are charts, easier to read and to forward.
• Slack or Microsoft Teams. A bridged conversation gets the written answer only.