Skip to content

Teach Ronja your business

The first answer Ronja gives you is the worst one you’ll ever get.

Not because it’s wrong — but because on day one she knows your data without knowing your business. She can see a revenue column; she can’t yet know that your fiscal year starts in April, that “active revenue” excludes one-time fees, or that the old orders table is kept only for auditors. Every company runs on knowledge like this, and most of it lives in people’s heads.

What separates Ronja from a generic AI tool is that this knowledge has a home. Corrections don’t evaporate at the end of a chat — they land in named, readable, governed places, and they apply to every future conversation, for everyone. Teach her once; she stays taught.

Ronja learns through a few surfaces, each with a distinct job (the full model is in How Ronja learns):

  1. Policies are the standing rules — one document for you, one for the organization, both read at the start of every conversation. Short by design, and edited directly. See Policies.
  2. Notes live inside a feature, next to the data they describe. They come in two kinds: skills teach Ronja a procedure, knowledge notes record facts about that feature’s data.
  3. The data dictionary — the column and table descriptions on your tables — sharpens how Ronja reads the data itself. See Maintain the data dictionary.

The rule of thumb runs through all three: a policy says how to work and where to look; the note, the dictionary and the codex hold what your business actually knows. Here’s how each one compounds.

You’ve just spent twenty minutes walking Ronja through how your team builds the weekly revenue report: which tables, which exclusions, which format. Don’t let that walk-through die with the session. Say:

“Save how we build the weekly revenue report as a skill.”

Ronja writes it up as a note of kind skill, attached to the feature, and opens it in a side panel so you can read exactly what she recorded. Two details make skills quietly powerful:

  • Each note carries a description written as a retrieval hint — “when should a future Ronja load this?” So the next time anyone works with this feature and asks for the weekly report, she finds the skill and reads it before starting work.
  • You refine a note the way you refine anything with Ronja: highlight a sentence in the panel, click Add to chat, and tell her what to change — except in a styled (HTML) note, which renders in its own frame, so there you just describe the change instead.

Skills and knowledge notes are listed in their feature’s hub, in their own Skills and Knowledge lanes — visible, browsable, and owned by the team, not buried in a model.

Pin down your definitions — knowledge notes

Section titled “Pin down your definitions — knowledge notes”

“Active revenue is net of refunds and excludes one-time fees — it comes from the subscriptions table, not orders.”

That sentence, spoken once in a chat, becomes a knowledge note: the metric’s real calculation, which tables and columns it uses, and the caveats, recorded beside the data it describes. From then on, “show me active revenue” means your active revenue — the same definition for the analyst who wrote it and the account manager who never will.

Set the rules of the house — the organization policy

Section titled “Set the rules of the house — the organization policy”

Some rules are bigger than any one feature: your fiscal calendar, which accounts are internal, which table settles an argument about revenue. Those belong in the organization policy — a short document your admins write under Data & Knowledge → Organization policy, which Ronja is given at the start of every conversation, and every automation, in the organization.

“The fiscal year runs January to December.” “Exclude test accounts from every customer count.”

That is the compounding step, and it is one line long. Write the fiscal year down once, and every conversation anyone has from that moment on groups quarters correctly — and the next workflow Ronja writes inherits the same rule. Only admins can edit it; everyone’s answers follow it.

Keep it to rules. The organization policy is capped at 20,000 characters on purpose: it is read in full, every time, by everyone, and a document nobody can read in one sitting stops being a set of rules and becomes a filing cabinet. When a rule needs a paragraph of background behind it, write the paragraph as a knowledge note and let the policy line point at it — “For revenue questions, read the revenue definitions note first.”

This layer has an older half: Knowledge, an organization-wide base Ronja largely built up herself as she worked. It is still there and she still reads it — but she has stopped adding to it. Nothing accumulates in the background any more: from here on, what your organization tells Ronja about itself is something a person wrote down, in a policy or a note, and can point at.

That is the change worth understanding, not the page. It also gives the old page a job worth an hour of an admin’s time: read what is in there, because Ronja is following it today, and correct anything that stopped being true. Rules move into the organization policy; facts move into a note.

See Curate Knowledge for how to work through what’s there.

Your own preferences get their own document: Your policy, from your account menu — up to 10,000 characters, edited directly. Your role, how you like results presented, which shape of answer you want first. It personalizes your answers without touching anyone else’s, and nobody else reads it.

Tell Ronja “always report in SEK” in a conversation and she can write the line herself. You see exactly what she added, with an Undo beside it.

The fact Where it goes
“Always exclude internal test accounts” The organization policy — applies everywhere, for everyone
“Active revenue = net of refunds, excluding one-time fees” A knowledge note in the feature that owns the data
“How we build the weekly revenue report” A skill note — a procedure Ronja can follow
“I prefer tables over charts” Your policy — yours alone

For notes, don’t overthink the routing — say it in chat and Ronja files it in the feature. The organization policy is written by admins; your own policy you edit yourself from the account menu. The table is for checking her work.

All of this is governed like everything else in Ronja — shared notes go through drafts and admin review, versions are kept, and every entry is readable by the people it affects. Which means the knowledge is trustworthy, not just present.

Spend an hour in week one correcting Ronja, and week two starts from a smarter baseline. Definitions stop being re-litigated. New teammates inherit the company’s context on day one, because the agent they ask already knows it. That’s the quiet difference between a tool that answers questions and a coworker who’s been paying attention.