Agents in apps

Agents build apps, and they work inside them under the same roles, field access and write rules as people. Nothing an agent does in an app bypasses the approvals you set.

The App Builder

Build an app on the Apps home and Build with AI in the designer open a chat with the App Builder: the Records Manager agent with the apps tools. It drafts, previews and proposes; publishing is an approval card with the diff. Build an app.

Agents working in your data

• Agents read and update Records through their Records tools. A write raises an approval card bound to the exact parameters, with a field-by-field diff, unless the agent's autonomy level lets it act without asking.
• The app's write rules apply to agents exactly as to people. A matching rule holds even an autonomous agent's write as a request for the approvers, and the tool reports the change as not made yet.
• Agents see fields through the same field access as the person they work for; a sensitive field is at most masked, even for an administrator.
• Pause all agents (the organisation kill switch) stops agents and automations from writing. A held request made by an agent stays open while agents are paused.
• Analyse only, the lowest autonomy level, gives an agent no tools at all, so it can discuss app data it is shown but cannot read or write it.
• Record-change and time triggers start Automations, and an interface action can run an automation under that automation's own governance.

The App assistant and askAgent

Renly has a built-in agent for app users, the App assistant, separate from the Records Manager that builds apps. It is scoped to one app at a time and has its own autonomy level and action rules, so an administrator can set it to Analyse only, or say never to running actions, without touching the builder. It is never offered in an agent picker; admins see it in the Agents admin.

App chats

• An app chat is a normal Renly chat with an app context: the app, the viewer's roles, each type they can read with its fields as they see them, their row scope, live sources, interfaces, the actions in their audience, the write rules, and the open page and record. The model call runs on the organisation's governed path: AI configuration, quota, evidence, autonomy and pause all apply.
• Its tools are limited to the app: app_query, app_get and app_aggregate read as the viewer, with their row scope and field access, through the same closed grammar as pages. app_run_action runs one of the interface's declared actions. The chat engine offers only these tools in an app chat, and refuses them anywhere else.
• app_run_action raises an approval card naming the app, the action, the record and each value. Approving runs exactly that call as the agent for the viewer; a matching write rule still holds it as a request. Pause all agents applies.

askAgent actions

• An askAgent action runs the App assistant for one turn on the current record with the action's prompt (Draft a reply, Summarise the history), filled from the record's fields as the viewer may see them.
• The reply may carry a proposal: one declared action of the same interface, with its inputs. Nothing is written. Applying the proposal is the person's own run of that action, through the write rules.
• Limits: 6 asks a minute and 200 a day per person. Asks are refused while agents are paused; a paused app answers without a proposal.

Plays an app recommends

A template can recommend plays: ready-made automations that work on the app's records, such as nudges on stale items, a radar for items due in the next 14 days, and a weekly review written up in Space. The CRM, request tracker and incident register recommend them. A play is installed through the plays' own path, one of each per person, for a type the person can read, and shows under Automations. In this release the recommended plays are listed and installed through the Apps API.