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. A rewrite you did not ask for — her repairing something she saw in her own check — says Fixing, over the panel title Fixing the app.
3. When it compiles, the panel is replaced by the app itself, marked Checking the app with a tinted line under the app’s title bar. Use it — you are not meant to wait. Ronja is opening it at the width it has here to see that it renders cleanly, and the reply finishes when that finishes. The box beside the composer says Checking the app… too, next to the stop button, so you can see why the reply has not ended without scrolling back up.
4. The header settles on Interactive, the tinted line goes, and — if you can build — a Make it an App button appears beside it. That is the whole app; nothing else is coming.

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

It arrives styled, in Ronja’s own design system — the same type, spacing and controls as the rest of the product — so there is nothing to ask for on that front and nothing to fix afterwards.

She looks at her own app before she stops

That check is Ronja opening the app the way you see it. If something came out broken, she says so in one line and fixes it — the app is rewritten in front of you rather than appearing a second time. She will do that at most twice; after that she stops and tells you what is still off, which is your cue to say what you want changed.

It is a check on the app, not on everyone’s access: she opens it as you, the person asking, so it says nothing about what a colleague you share the chat with will be able to load. And sometimes she cannot open it at all — a slow moment, or a busy one. The app is saved and yours either way; she will say she has not seen it, and if she closes by asking something specific, like whether the tiles fit on one row, the answer is worth giving. Pressing Stop generating is different: the reply ends there, so she says nothing about the app at all — it is still saved, and still yours.

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. The button appears once the header has settled on Interactive — while she is still checking the app there is no button for anyone, and a reply that ended without one (you pressed Stop generating, or it was cut short) leaves the frame without one for good. On a settled frame, though, no button means no build access — a colleague who has it 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.
• Saving a file. An inline app cannot download anything, so its tables have no Export CSV. Ask for an App if you need the rows in a spreadsheet.
• 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.