Runnit Studio
Runnit Studio is the in-app place to build custom artifacts with the AI builder agent. It is one feature with one storage and runtime model: the type of artifact you build determines where it surfaces in the app.
New organisations start with Studio enabled, so an administrator can create and preview an artifact without a separate setup step. An organisation administrator can turn off user-built components from Studio settings. When Studio is off, component previews explain that the organisation setting must be enabled.
Restrict tools used by pages and widgets
Section titled “Restrict tools used by pages and widgets”An organisation administrator can open Studio settings, enter exact tool
names separated by commas in Disabled MCP tools, then select Save.
For example, add get_project to block that call from Studio pages and widgets.
The saved list applies to the next call, including calls from an already-open page, a public page, a preview or the builder’s data checks. You do not need to rebuild the page. A blocked call reports that the tool is disabled by the organisation’s Studio settings, even when the viewer can otherwise read the record. Remove the name and select Save to allow it again, subject to the normal access rules. Turning Studio off also stops calls from existing sessions.
You can block a named runtime AI or agent-conversation call in the same way. This setting controls calls made by Studio components. It does not change a person’s permissions elsewhere in Runnit or the tools Ru can use inside an allowed conversation.
Artifact types
Section titled “Artifact types”| Type | Status | What it is | Where it appears |
|---|---|---|---|
| Page | Shipped | A full-screen custom page that owns the content area. | Its own route, granted into the sidebar. |
| Widget | Shipped | A compact tile sized for a dashboard grid cell. | The configurable dashboard catalog. |
| Form | Shipped | A Studio-native intake form with an attached workflow. | The Studio artifacts list. |
| Automation | Shipped | A trigger and a set of actions that run on their own, on an event, a schedule, an inbound webhook, or on demand. | The Studio artifacts list. |
| Block | Planned | A small reusable UI/logic piece embedded in other artifacts. | Coming soon. |
Publishing a widget to a dashboard
Section titled “Publishing a widget to a dashboard”- Create a widget in Studio (New → Widget → template).
- Build it manually or with the AI builder agent. It produces compact, size-aware output.
- Publish it organisation-visible from the Sharing tab.
- The dashboard’s widget picker lists it, and your placement persists per user.
Sharing a page or widget
Section titled “Sharing a page or widget”The Sharing tab controls who can use a published page or widget:
- Just me: only you.
- Everyone: every member of your organisation.
- Specific people, groups & roles: pick individual people, user groups, or whole roles (for example, all managers).
Sharing with a group keeps access in step with the group’s membership: when someone joins the group, the page appears in their sidebar on their next page load, and when they leave it disappears the same way. An archived group grants nobody access and is labelled as such in the access list.
Sharing a page with people outside your workspace
Section titled “Sharing a page with people outside your workspace”A published page can be shared by link with people who have no Runnit account, such as a client waiting on a progress update. Open the page’s Sharing tab. Under Who can access this page?, below the member setting, is a row called Anyone with the link. Only pages have it. Public access adds to whoever in your workspace can see the page; it does not replace that setting.
Start the page as a public page
Section titled “Start the page as a public page”When you create a new page, the template picker asks Who will view this page? Choose People outside my workspace for a page you plan to share by link. The builder then keeps to the calls a public page may make, each fixed to one record, so the page passes the public check first time, and it tells you when something you ask for is not available on a public page. Choose People in my workspace for an internal page; the builder can then use every read tool.
You can change this later with the Built as a public page checkbox in the Anyone with the link row.
See what public pages can read
Section titled “See what public pages can read”In the same row, select Show what public pages can read for the full list of allowed calls, what each one is fixed to, and the rules.
Get the builder to fix a page
Section titled “Get the builder to fix a page”If a page fails the check, select Ask the builder to make it public-safe. Runnit writes a prompt that lists the allowed calls, the rules, and each call in the current build that breaks them, and sends it to the page’s builder chat. The builder reworks the page and builds it; then check the row again. Copy the prompt gives you the same text to edit or use elsewhere.
Before offering the link, Runnit checks what the page reads. Select Show what version N reads to see every data call in the current build, the record it is fixed to, and whether it is allowed on a public page. A page can be shared when every call:
- reads one fixed project, task or master project (its id or job number is written into the page, not chosen while someone views it);
- uses one of the allowed reads: a project, its tasks, task counts, milestones and members, a task, a master project, or a project looked up by job number; and
- does not use the workspace AI or an agent.
If a call is not allowed, the row says why. Change the page, build it again, and check back.
When the build passes, select Turn on. The link appears in the row with a Copy link button, and stays there whenever you open the Sharing tab. Each page has one link. Reset link replaces it with a new one and stops the old one working straight away.
Anyone with the link can view the page without signing in. The page shows only the records listed in the check, using your own access, and never includes contact details, budgets or rates. In-app links inside the page do nothing for public viewers.
The public page keeps showing the build that was live when you turned the link on. After you build again, the row tells you the public page is behind and offers Show the latest build publicly. If the new build does not pass the check, the public page stays on the earlier build until you fix it.
To stop sharing, select Turn off. The link stops working at once. Unpublishing the page also takes the public page offline, and publishing again brings it back.
Unpublishing a page or widget
Section titled “Unpublishing a page or widget”To take a published page or widget out of use, open its Sharing tab and select Unpublish. The artifact returns to a draft that only you can see. For everyone else this takes effect on their next page load: pages leave the sidebar and their link stops working, and widgets disappear from the widget picker and from any dashboard they were placed on.
Your access settings are kept, so selecting Publish again restores access exactly as it was.
Design system inside artifacts
Section titled “Design system inside artifacts”Studio artifacts render inside a secure sandbox that still looks native to Runnit. The EK Modena fonts are inlined, and theme-aware colour tokens are exposed as CSS variables so components match light and dark mode automatically. Authors style with these tokens rather than hard-coded colours.
When a user changes theme, published widgets receive the new tokens and recolour in place. The widget is not reloaded, so interactive state is preserved and there is no refresh flash.
Runtime AI in pages and widgets
Section titled “Runtime AI in pages and widgets”Published pages and widgets can use the workspace AI while people view them: generating summaries of the data they show, interpreting results, or embedding a chat with Ru directly in the page.
This is off by default. An organisation administrator turns it on from the Studio settings page with Enable runtime AI for pages and widgets, and can set a daily runtime AI call budget that caps how many AI calls published components can make per day across the organisation.
Every runtime AI call is recorded on the AI Usage page, attributed to the component and the viewing user. Credit organisations see the credit burn. Unmetered and own-key organisations see token and provider-cost details. Ru conversations started from a page run as the viewing user with their normal permissions.
See Component Builder for how the AI builder agent authors these artifacts, and Workflow Automations for building automations that run on a trigger.