What's the difference?

Short answers to Ronja’s most commonly confused pairs. Each section links to the full page.

Admin vs Super Admin

An Admin runs the day-to-day: inviting members, assigning roles (below their own level), managing access groups, reviewing shared content, and restoring things from the trash. The Super Admin is the org owner — assigned automatically to whoever created the organization. Only the Super Admin can promote members to Admin or Super Admin, buy credits, register a login domain for auto-join, or delete the organization. Every organization needs at least one Super Admin, and you cannot demote yourself if you are the last one. Full details in the roles capability matrix.

Access Group vs Feature

An access group is a container for people: members are added to access groups, and an access group decides which features its members can reach. A feature is a container for work: a named bundle of tables, workflows, notes, apps, and other resources that together deliver one outcome. Data always lives in features; access always flows through access groups. Promoting a feature to Organization scope does not automatically show it to everyone — an admin still attaches it to access groups. See Access Groups and Features.

Space vs Access Group

A Space decides which people are in one body of work: an admin puts you on a Space’s member list, and everything you list — open Features and you see that Space’s features — follows the Space you are in. An access group decides who reaches what, inside its Space: add somebody to one and they reach the features it has. A Space contains access groups, not the other way round, and the two combine — an access group only ever reaches the people who are in its Space, so nothing shared with an access group in another Space reaches you. What still crosses Spaces is anything handed to you by name: a chat or project shared with you, a feature you maintain. Your own work opens from any Space; your private features are listed in the Space you made them in, and each Space has its own My Private Feature. Most organizations have exactly one Space and never meet the idea. See Spaces and Access Groups.

Project vs Feature

A project is a container for conversations: a name, a member list, and one folder, so the chats about one piece of work have a home. A feature is a container for resources: the tables, workflows, notes, apps and Saved Agents that together deliver an outcome. A project owns no data — file a chat into one and you have grouped the conversation, not the tables it built. Access differs too: project membership cascades onto every chat in the project, while a feature is reached through the access groups it is attached to. Use a project for “this piece of work”, a feature for “this thing we built”. See Projects and Features.

Note vs Knowledge

A note is a document attached to one feature, written through chat. Notes come in two kinds: Skills teach Ronja a procedure (“how we build the weekly report”), and Knowledge notes record reference facts about that feature’s data. Separately, the Knowledge page holds organization-wide knowledge — terminology, business rules, KPI definitions — which Ronja reads in every conversation. It is frozen: an admin can correct an entry, but nothing new is added to it. Rule of thumb: tied to one feature’s data → note; a rule that should hold in every conversation → a policy, which is where org-wide rules are written now. See How Ronja learns.

Workflow vs Automation

A workflow is a reusable job — a named, parameterized Python program Ronja writes for you, which you can run manually or reuse anywhere. An automation is a trigger paired with an action: it fires a workflow or a Saved Agent on a schedule, on an inbound email or webhook, when a watched table rebuilds, when a custom event is emitted, or when new mail arrives in a connected mailbox. The workflow is the work; the automation is the “when”. See Workflows and automations and the automation triggers reference.

App vs inline app

An App is published: Ronja builds it in Build mode, it lives in a feature, it has its own page you can open full-screen and send to a colleague, and everyone who opens it sees it through the same one set of powers. An inline app is an answer: a small interactive app Ronja writes into one conversation in place of her written reply, marked Interactive in the answer column. It has no feature, no page and no link, it needs no Build mode to ask for, and it is deleted with the chat. It also reads as whoever is looking at it, so two colleagues can open the same one and see different things — a table one of them cannot reach comes back refused for them and works for the other, in the same app. Ask for an inline app when the point is “let me poke at this”; keep it as an App — Make it an App, in the frame’s header — when other people need the same thing tomorrow. See Ask for an inline app and Build an app.

Exploration vs Saved Agent

An exploration is a conversation: you and Ronja working through a question interactively, one session at a time. A Saved Agent is a packaged, reusable agent — a saved prompt plus model tier, reasoning effort and tool grants — that can be invoked from any chat, tried out in the Chat with Agent panel on its own page, or run headlessly by an automation. If you find yourself giving Ronja the same instructions repeatedly, ask her to save them as a Saved Agent. See Explorations and Create a saved agent.

Connection vs MCP server vs Bridge

A connection imports data: a configured connector instance (PostgreSQL, HubSpot, …) that syncs an external system’s data into Ronja tables on a schedule. An MCP server adds tools: an external service Ronja connects to as a client, whose tools join the agent’s toolbox (it brings capabilities, not tables). A bridge adds a chat surface: it connects Ronja to a Slack or Microsoft Teams channel so your team can talk to her where they already work. See Connect a data source, Connect MCP servers, and Use Ronja in Slack and Teams.

Connected mailbox vs Email notifications vs Email-trigger address

Three surfaces involve email, and they answer three different questions.

A connected mailbox is an inbox Ronja reads and answers: your own address (support@yourcompany.com), connected on the Mailboxes page, that Ronja reads incoming mail from and replies to in-thread as that address. The person on the other end sees your address, not Ronja’s. Mail flows in, and answers flow back out to outsiders. Mailboxes are Admin-only to connect and to use in a chat; to have one worked unattended, an Admin attaches it to an Automation on the Mailbox trigger, which fires a Saved Agent each time new mail arrives — minutes after it lands, not on a schedule. A workflow can send mail as the mailbox too — sending only, so when the mail is the job (reading, replying, triage) it stays with a Saved Agent. Mail sent as a connected mailbox draws on that mailbox’s own daily send limit, not on the organization-wide cap that governs Ronja’s own address.

Email notifications are Ronja telling your team something: the Email delivery channel on the Notification routing page, where you list the recipients who get notified when Ronja needs an approval, a review, or flags a problem. Mail flows out, to your own people. Nothing arrives back.

The email-trigger address is a way to start an automation: the routable ingest address set at Governance → Organization rules. Mail sent to it fires an Automation on the Email trigger — the message is the automation’s input. It’s a doorbell, not a mailbox: nothing is stored to browse, and any reply comes from Ronja’s own address rather than yours.

Pick by what you want to happen: Ronja answers customers as us → connected mailbox. Ronja tells us when something needs attention → email notifications. An email should kick off a job → email-trigger address. See Connect a mailbox and Schedule an automation.

Weekly AI budget vs Allocation

Both cap how many credits one person can spend, and both apply at the same time: a prompt is refused as soon as either is used up. Neither ever switches anyone to a different model.

	Weekly AI budget	Allocation
Resets	Every Monday at 00:00 UTC	With the billing period
Counts	The person’s chats with Ronja	What the person runs: chats, Slack or Teams conversations, API and CLI calls, older automations
Stops	Their chats, Admins included	Their chats; a Limited allocation never stops an Admin, while Blocked stops everyone
Set per	Default for each person, access group, person	Default for each person, role, person
Who sets it	Any Admin	Admins with billing access

Both are set on the Control Center’s Rules tab, and its People tab shows each person’s. See Which rule applies and Set weekly AI budgets.

The Usage page vs the Billing page

Two different sidebar entries under Billing & Control. Usage (page heading “Usage & billing”) is the breakdown: what drove your credit consumption this cycle — by source, user, model, and mode. It’s visible to admins whose organization has billing access enabled — ask Ronja to enable it. Billing is the wallet: the Super-Admin-only page showing total available credits, the Buy credits form, and the purchase history (Credit extensions, or Receipts in an organization that pays by card). Check where credits went on Usage; top credits up on Billing. See Credits and AI spend.