Uni system · one turn

A message's life

Aaron writes "@Uni" in a room. A few seconds to a few minutes later a reply appears. In between, the message crosses the chat server, wakes that room's Uni, and goes back and forth with Claude Opus and its tools until there is an answer.

A message's life, as a sequence Five lanes: Aaron and the app, Buzz, Hermes, Claude Opus, and tools including the Parachute vault. The message goes from the app through Buzz to Hermes, which picks the room's session, adds catch-up, and sends everything to Opus. Opus asks for tools; Hermes runs them and returns results; this repeats. Opus writes the reply, Hermes posts it through Buzz to the app, then logs the turn and acts on any [done] marker. Aaronin the Uni app Buzzchat relay Hermesthe room's Uni Claude Opusat Anthropic Toolsvault, shell, rooms 1 "@Uni …" or a voice note 2 delivers the chat event 3 from Aaron? addressed to Uni? → this room's session 4 digest plugin adds "since you last wrote" 5 rules + memory + history + the new message repeat until Opus has an answer 6 "call this tool" Hermes runs it 7 result result goes back 8 the reply 9 posts in the room Aaron reads it 10 relay plugin logs the turn; a "[done T-NN]" line closes the task task note, wakes
One turn, top to bottom. The amber box is the loop where the work happens. Swipe sideways to see all of it, or open the full-size picture.

Step by step

  1. Aaron writes in a room. He types "@Uni …" or records a voice note in the Uni app. In a room, Uni only answers when it is addressed (an @mention, or a reply to one of its messages). Direct messages always reach it.
    Technical detail
    • The app signs the message with Aaron's key and sends it to the relay as a Nostr chat event (kind 9), over a private network.
    • Voice notes become text on the laptop with faster-whisper.
  2. Buzz passes it on. The relay stores the message in the room's channel and delivers it to everyone listening, including Hermes.
    Technical detail
    • Hermes's Buzz adapter keeps a connection open to the relay and receives every event in the channels Uni belongs to.
  3. Hermes finds the right Uni. It checks the message is from Aaron and meant for Uni, then hands it to that room's session. Each room has exactly one session, so #techne's Uni remembers the #techne conversation and nothing else.
    Technical detail
    • Hermes is set to keep one session per channel. Sessions are rows in a local SQLite database.
  4. Catch-up is added. If other rooms or tasks linked to this room changed since Aaron last wrote here, a short "since your last message" block is attached to his message, so Uni starts the turn up to date.
    Technical detail
    • The digest plugin's pre_llm_call hook builds it from task-note changes in the room's node neighbourhood and finished turns in linked rooms. Messages injected by other rooms are skipped, so catch-up only rides on Aaron's own messages.
  5. Opus gets the whole picture. Hermes sends Claude Opus 5.5 the rules (its operating file and voice), its small memory, the room's conversation so far, the catch-up and the new message.
    Technical detail
    • Long conversations are compressed at 300k tokens; the context limit is set to 500k.
    • If Claude fails, Hermes falls back to OpenAI's GPT-6.1 sol.
  6. Opus asks for tools. Instead of answering straight away, Opus can ask Hermes to do things: search or write the vault, run a command, read a skill, wake another room, start a helper.
  7. Hermes runs them and reports back. Each result goes back to Opus, which may ask for more. This loop is where most of the time in a turn goes.
    Technical detail
    • About 50 tools in a #Uni session: a terminal, file tools, memory, session_search, skill_view, web_search, vision_analyze, delegate_task (Sonnet helpers), scheduled jobs, relay_wake, and about 20 Parachute vault tools.
    • Bigger jobs leave the turn entirely: the room starts a Claude Code worker and answers now (see How work moves).
  8. Opus writes the reply.
  9. The reply appears in the room. Hermes posts it to the channel through Buzz; the app shows it.
  10. After the turn, the bookkeeping. A note of the turn goes into a shared activity log. If the reply contains a line like [done T-NN], [blocked T-NN] or [decision T-NN], the task note is updated and the room that started the work, or #Uni, is woken.
    Technical detail
    • The relay plugin's post_llm_call hook, for every room except #Uni: a line in the shared activity log, then for each marker the task is set to done (with a check that no other room changed it first), the run note is closed, and whoever started or handed out the work is woken. [blocked] and [decision] always wake #Uni.
    • A timer every 10 minutes catches markers the hook missed.

What Uni sees on each turn

LayerWhat it isChanges
RulesHermes's operating file and a short voice fileWhen Aaron sets a standing preference
MemoryTwo small memory files, about 3.5 KB togetherRarely; only facts every session needs
Skills indexNames of about 140 written procedures; a skill's full text loads only when usedWhen a lesson is learned
This room's historyEverything said in the room, compressed when it grows past 300k tokensEvery turn
Catch-up"Since your last message" from linked rooms and tasksOnly on Aaron's messages
The vaultNot loaded up front. Uni searches Parachute with tools when a question needs itOn demand

The same loop, started by another room

Rooms talk to each other the same way. When #Uni hands work to #techne, it calls relay_wake, which places a message beginning [relay from #Uni] into #techne's session. #techne then runs the same steps 5 to 10, as if Aaron had written to it. The wake queue, which scripts use to wake a room, goes through the same door. Scheduled jobs are different: each runs as its own short session and posts its result into a room.

Worth noticing. Uni has no memory of a room it isn't in. What #techne knows comes from its own history, the vault, and catch-up. That is why rooms write their state to notes, and why the hooks project cares about results reaching the right room.