The brief is the packet handed to a session before its first prompt. It is the half of Runi that matters most, because it carries what an agent would never think to ask for: a teammate holding this file right now, an approach that already failed, a decision that settles the question it is about to re-open.
What goes in it#
A ranked selection of structured records. Never transcripts, and never a recency dump.
- Open tasks in this repository, with their intent.
- Confirmed memory: decisions and their reasons, discoveries, conventions, known issues.
- Open blockers and failed approaches, the highest-value lines in the packet.
- Live teammate activity: who is working, and which files they hold.
- Shared work and handoffs aimed at this repository or this person.
- Notes a teammate approved for delivery to you.
Every line carries its author and how firmly it is established. An unsourced line is how a model launders a guess into a fact, so there are none.
The budget, and why there is one#
The packet gets 4,000 tokens by default, out of roughly two
hundred candidate records. Set it with contextBudget in
~/.relay/config.json, which accepts 1,000 to 12,000.
A budget exists because context is not free, in money or in the agent's attention. A briefing that fills the window with everything the team has ever known is a briefing the agent skims.
Note
Nothing below the line is lost, only unpushed. Whatever the budget cut is still there and still reachable, by asking. That is what the MCP tools are for: push carries what you would never think to ask for, pull carries the archive.
Within the budget, if the session is linked to a task, that task's own records take up to half the packet ahead of ranking: its card, the shared work on it, its open blockers. The work in front of you outranks the workspace's general wisdom.
What is left out#
- Session bookkeeping. "A session started" is not context.
- Your own prompts. You do not need briefing on what you just said.
- Unconfirmed memory. A proposed entry rides no briefing until its author signs it.
- Records below the confidence floor, records under an approval hold, and anything outside this repository's scope.
The delivery receipt#
A briefing is handed over inside a terminal nobody is watching, so every hand-over files a receipt: who was briefed, in which session, through which surface, and the ids of the records and source sessions the packet carried. The manifest comes from the same call that produced the text, so a receipt cannot describe a different packet from the one that shipped.
In the app it reads back on your session as one line:
Reached Ravi's Codex session 2h ago, read by the agent.
Or it says why not: nothing was published, nobody has started a session here since, or teammates were briefed and this session's records did not rank into their packets.
Emitted is not the same as read#
Emission is what a hook can prove. Ingestion, meaning the model reading it, is marked separately and on evidence. The packet asks for one attribution line at the top of the first reply, and Runi checks for it once. The receipt keeps which of three answers came back.
| Word | Means |
|---|---|
| relevant | The agent said it was drawing on specific team items. The briefing did its job. |
| none | "N team items loaded, none relevant." Delivered, read, and judged not to bear on the work. A healthy result, not a failure. |
| absent | The first reply carried no line at all. Nothing suggests the packet was read. This is the one worth chasing. |
That word is the only number in the product that says whether briefings are useful, not merely delivered. Settings → Members counts it per week.
Your own verdict#
After a session, its brief line in the app offers useful / not. Your answer lands on the receipt, and records that rode a briefing you called useful get a one-point tiebreak in future ranking.
It is a nudge, not a lever. It is never enough to lift a memory entry over an open blocker, so ranking cannot be gamed into burying the thing that is currently on fire.
See exactly what a session will receive#
The app has a packet inspector, and it runs the same module the daemon does, so what it shows is what a session receives. Use it when you want to know why something did or did not make the cut.
You can also print it, from the repository, on the machine in question:
$ node ~/.relay/daemon/relay-cli.js briefMaking briefs better#
-
Confirm memory at the end of a session#
Unconfirmed entries ride nothing. Ten seconds of signing is the biggest lever you have on what your team receives tomorrow.
-
Give a decision its reason#
A decision without a why is a rule nobody can safely revisit. Runi refuses to record one through
runi_rememberfor that reason. -
Correct a wrong line once#
The correction is what every later session receives. Being wrong should cost the team one fix, not one fix per person.
-
Answer useful / not#
One click, and the only signal the ranker gets about outcomes.
-
Raise the budget only if you have measured a reason to#
contextBudgetin~/.relay/config.json. The tail of the ranking is tail for a reason.
When a briefing was partial#
If a collection was unreachable when the packet was built, the packet says so inside itself. The agent is told its briefing is incomplete instead of being handed a confident subset. The same fact appears for you in the doctor:
warn context last briefing was partial — handoffs unreachable
(12 min ago); the packet said so tooIf briefs are not arriving at all, that is a different problem: My sessions start without a brief.