Runi is quiet at the start by design, and quiet is easy to read as broken. Here is what should appear, and in what order, so you can tell the two apart without opening the doctor.
Your first session#
Open your agent in a tracked repository and give it one ordinary prompt. Within a few seconds, in the app:
- A session appears under Sessions, live, with your agent named.
- A task card is created from the first real ask, titled from what you typed. Not every prompt makes one. A machine turn, a one-word reply, or a paste with no sentence in it are all treated as not-a-task.
- Files appear as your agent edits them, by path, as a live rail on the session.
- Test runs appear with their pass and fail counts when your agent runs them.
What you will not get is a useful brief, and that is correct. The workspace is empty. Your team has learned nothing yet, so there is nothing to hand you.
Note
The first moment teams think it is broken. "My session started and there was no context." On day one there is none to give. A brief is made of other sessions, and the first one has none behind it.
The end of your first session#
Two things happen when the session finishes.
The task card gets sharper#
The card was written the instant you prompted, from your words alone. Once your agent has read the codebase and said what it intends to do, that sentence replaces the guessed intent, and at the end a line about what actually changed is added. You will see a card improve two or three times without touching it. See Task cards.
Memory is proposed, not published#
If the session settled something (a decision with a reason, a discovery, an approach that failed) Runi drafts it as a proposed memory entry in your name. It rides nobody's brief until you confirm it. Open Memory, read the two or three lines it drafted, correct anything wrong, and confirm the ones worth keeping.
Tip
This is the ten seconds that make the product work. Confirming two entries at the end of a session is what a teammate's next session starts from. Skip it for a week and Runi is a very good activity feed and nothing more.
Your second session, and the first real brief#
Start a new session in the same repository. The packet now has something in it: the open task, the entries you confirmed, the files that are still warm, and, if a colleague is working, who is holding what.
Ask the agent what it received. Every adapter delivers the packet as real context, so it can tell you. If it says it received nothing, go to My sessions start without a brief.
The first day with a second person#
Runi's value scales with how many sessions the team runs, so a single-seat first day predicts nothing about the second week. Once a colleague connects, watch for these.
| Signal | Where | What it means |
|---|---|---|
| Live teammate sessions | Sessions, Team | Someone else's agent is running, and you can see which files it is holding. |
| An overlap warning | Injected at prompt time; also in the app | A teammate's live session is holding a file yours is holding. This is the one that pays for itself at merge time. |
| A delivery receipt on a session | The session's brief line | Reached Ravi's Codex session 2h ago, read by the agent. Proof your work travelled, not a promise that it did. |
| "Useful / not" on a brief | The session's brief line | Your verdict. It nudges the ranker: records that rode a useful briefing get a small tiebreak next time. |
The second moment teams think it is broken#
A receipt reading "N team items loaded, none relevant" looks like a failure and is not one. The packet was delivered, the agent read it, and the agent judged that nothing in it bore on the work at hand. That is a working system reporting a real result, and far more useful than one claiming every brief was valuable.
A receipt that says the line was absent is different. The packet was emitted but nothing suggests the model read it. That one is worth chasing, in Briefs not landing.
A reasonable first week#
-
Day one: connect and work#
One agent, one repository, no change to how you work. Confirm memory entries at the end of each session.
-
Day two: add the second person#
The product barely exists at one seat. Invite the colleague who works nearest your code, not the whole team.
-
Day three: set your sharing switches#
Read The two sharing switches once, as a team, and decide. A default winning by inertia is the failure mode here.
-
End of week one: check the receipts#
Settings → Members counts how many briefings were read each week and how many were called useful. If that number is zero while sessions are running, something is wrong and the doctor will say what.