Screens

Some answers end on a screen the user already has: the order, the subscription, the notification settings. Instead of describing how to get there, the copilot can offer it on a screens card, or on a button, and a tap opens it through your app's own navigation. Nothing is a web view and nothing new is built: you register a screen you already have, and say when it is the right one.

A screen is not an action. Opening it changes nothing, so it never needs a confirmation card; the user finishes whatever they came for on your own screen.

Registering a screen

Flutter:

Rendel.registerRoute(
  'order_detail',
  title: 'Orders › Order',
  description: 'One order: its items, delivery and payment.',
  params: {'order_id': RendelRouteParam.string(required: true, fromActions: true)},
  open: (p) => router.go('/orders/${p['order_id']}'),
);

Web:

Rendel.registerRoute({
  name: "order_detail",
  title: "Orders › Order",
  description: "One order: its items, delivery and payment.",
  params: { order_id: { type: "string", required: true, fromActions: true } },
  open: ({ order_id }) => router.push(`/orders/${order_id}`),
});

An app registers up to 50 screens. Both calls are safe before init; screens travel in the manifest with your actions. While your screen shows, the copilot waits in a small bubble in the corner (bubbleOffset keeps it above your own bottom bar), and a tap on the bubble brings the answer back as it was.

Prefer screens that already have a route or a deep link, and skip dialogs, onboarding and sign-in. A screen the user would never ask for by name is noise in the model's choices.

fromActions: values the model cannot invent

A param marked fromActions: true must equal a value one of your actions returned in this conversation. The order id that opens order_detail has to have come back from get_order or list_orders first. An id the model made up, read in a knowledge source or heard from the user does not open the screen, and the card falls back to its text.

Use it for every param that identifies something: an order, a booking, an account, an amount. Leave it off for values that are safe whatever they are, such as a settings tab name.

Before a reply leaves the server, every navigate in it is checked against your registered screens: the screen must exist, its params must be the ones it declares, of their types, the required ones present, and the fromActions ones traceable to an action result. See Values the server checks.

The Screens page

The console's Screens page lists what your app registers, from its latest build:

• Registered: in the latest build, with the title, description and params as the build describes them. A param marked from an action says so.
• Planned, not registered yet: screens a setup agent said it wrote in code, which no build has registered so far. They move up once a build that registers them runs. If one stays here, the registerRoute call is not running at startup.
• Not in your latest build: an earlier build registered these and the latest does not. Devices still on that build can open them.

Turning a screen off

Each registered screen has a switch. Turn it off and the copilot stops offering that screen at once, on every build, with no release. Your app is unchanged: people can still open the screen themselves. Turn it back on the same way.

It is the same idea as disabling an action: what your code registers is the most the copilot may do, and the console can narrow it at any time.

Trying one

Ask for it, on the Test page or in a paired build: "show me my last order" should come back with the order's card. If the copilot answers in words instead, sharpen the screen's description — say when it is the right screen, in the words your users use.