Data and files
Workspace memory
How agents learn from one run to the next. Lasting notes distilled on their own, where a note applies, pinning and management.
Agents do not normally carry what they learned in one task into the next, because every run starts clean (Memory and context). Workspace memory is the deliberate exception. Lasting, short notes distilled from runs (500 characters at most) are stored, and all of them are recalled automatically at the start of every new run. You correct "emails are written in a formal tone" once, the system learns it and never asks again.
How does it learn?
There are two ways, and neither asks anything extra of you.
- In the natural flow. As a run ends, the agent distils a lasting lesson if there is one. The system also weighs strong signals in the background, such as revision feedback, phrases like "from now on…" and operations that failed repeatedly and were finally solved. This evaluation does not spend your LLM keys, because it runs on the local model on the server.
- By hand. You can add a note yourself from Settings → Memory (Admin) or from the Memory tab on your profile.
It works in chat too, in two ways. The moment you give an explicit instruction such as "from now on write reports as bullet points", the note is saved pinned (📌). And even when you do not say "remember this", a lasting fact you share in passing ("I live in Zonguldak") is picked up a few minutes after the conversation settles, by a background pass, and kept as a normal note. Language makes no difference either, because detection works on intent rather than on set phrases, and it behaves the same way if you write in Japanese or French. Passing states ("I'm tired today") and sensitive subjects such as health or belief are not saved unless you ask for it.
Your comments on a task card go through the same filter. If an agent replied after your comment, the card came back from review, or a failed checklist item was completed afterwards, your comments are evaluated in the background once the card goes quiet. This also works when the job was done by an agent that connects from outside, such as Claude Code, because Orbi looks at the correction you left on the card, not at the agent's conversation. The note's source shows the card and the comment. A comment nobody responded to, and a comment that approves and closes the work, are not evaluated.
Work you ask for is not memory either. Requests such as "list the projects", "describe the image" or "write a post about this" say what you want done right now and nothing lasting about you, so they never become notes. The details you give while an agent sets up a flow, a collection or a calendar event for you (the time, the place, the budget, the food you like) do not become notes either, because the thing that was set up already holds them. Nor can an agent write notes on its own during a chat. Inside a run it saves only what you explicitly told it to remember, and the background review filters the rest. If a note that does not belong still shows up, delete it from Settings → Memory, and the deleted note goes to the archive where it can be restored.
Three scopes
| Scope | Who it affects | Who can see it |
|---|---|---|
| Workspace | Everyone's runs | All members |
| Project | Only runs in that project | All members |
| Personal | Only runs you start | Only you, and nobody else, Admins included |
Personal preferences such as "give me a short summary" are kept in the personal scope. The agent reflects them in how it behaves but does not write them into shared output. When the system cannot be sure, it picks the personal scope, because applying one person's preference to everyone is more uncomfortable than leaving a shared rule personal.
Management and pinning
- Settings → Memory. Everyone can see workspace and project notes. Adding, editing, archiving and deleting permanently belong to Admins.
- Profile → Memory. You manage your own personal notes with full rights.
- Learn from my Claude Code chats. The switch at the top of Profile → Memory starts off. If
you turn it on, your own messages in Claude Code are sent to Orbi at the end of a session, and
lasting preferences and rules are extracted from them. A message yields a note only when the
rule is said with words that make it last, such as "from now on", "always" or "we never"; an
instruction for one job, an approval or a discussion does not. The model's answers, the summary
Claude Code writes when it compacts the context, and files are not sent. The switch belongs to you, not to a token: turning it off turns it off on all your
computers, and it stays off when you renew a token. It needs the full tier of the memory
protocol installed on your computer (
orbi-node memory install --tier full). The hook connects to Orbi with a personal token; you create it under Profile → Tool access and put it into the.orbi/hooks/envfile the setup creates. The installer asks for this consent separately from writing the files. If the hook cannot read a single message in three sessions in a row, you see a warning in the same place; the client may have changed its transcript format. - Canvas. On desktop, memory is drawn as a tree. Topics and their note counts sit on the left; clicking a topic shows its notes on the canvas. A note's type reads from its shape: a rule has a heavy left edge, a lesson a dashed border, a decision cut corners. A conflicting note is yellow, a stale one faded. The key to the shapes is at the bottom left of the canvas. Clicking a note opens a drawer on the right with its source, the quoted words, how many runs it entered, its links and its history (who archived it, who moved it to another topic, who unpinned it). Editing, pinning, archiving and changing the topic live there too.
- Settling a conflict. The drawer of a conflicting note shows both notes side by side. "Keep this one" asks for confirmation and states the outcome first. Keeping the pinned note archives the new one. Keeping the new note marks the old one as replaced and pins the new one.
- Topics. Admins add, rename, delete or merge topics. Merging moves the notes to the target topic; their identity and links stay the same. Notes under a deleted topic are not deleted, they move to the inbox. A topic opened by an agent is marked in the list.
- New agent notes. The box under the topics shows how many notes agents wrote in the last seven days. No approval is needed. "Show only these" lets you glance over all of them at once.
- Measurement. The strip above the canvas shows four numbers: the share of archived notes, notes from outside clients, notes that entered a run in the last thirty days, and the size of the skeleton every run reads at its start. You can hide the strip; the choice is remembered.
- List view. The archive, permanent deletion, the type filter and search are in the list view. There is no canvas on a phone; memory opens as the list only.
- Pinning (📌). A note you add or edit by hand is pinned automatically. A note the agent saves after an explicit instruction in chat, such as "never forget this", is born pinned too, because the words are yours and the agent is only the scribe. Agents and the automatic distiller can never touch a pinned note, and even when memory grows large it stays in the run context in full. What a person says always outranks.
- Conflict flag (⚠). When an agent sees a new lesson that conflicts with a pinned note, it does not change the note. It raises a flag and leaves the decision to you. Workspace admins get a notification, and clicking it opens the memory screen on the conflicting note. If the note is personal, only its owner is notified. The conflicting note stays out of every run until you decide. A new rule that resembles a pinned one is first born with the "Being checked" label and stays out of runs. Orbi checks in the background whether the two rules conflict, which takes a few minutes. If they are compatible the note becomes active on its own and you get no notification; if they conflict, the flag is raised then.
- Deleting means archiving. A note an agent deletes actually moves to the archive and can be brought back. Deleting permanently happens only from the interface.
- Type and topic. Every note is stored with a type: rule, fact, lesson, decision, constraint or reference. A decision also carries its rationale. Notes are grouped under topics (Working rules, Writing, Code, Environment, Product decisions, People, Customer rules, Inbox); a note written without a topic enters the Inbox first and moves to a fitting topic within a few minutes; a note that fits no topic stays in the Inbox. Admins shape the topics, and an agent may open a new one when needed.
- Stale notes. An agent note that no run has recalled for a long time is marked "stale" and stays out of runs; it becomes active again when you confirm it.
Limits and safety
- A note holds 500 characters at most, because memory works like a store of distilled lessons rather than a notebook.
- A workspace holds 1,000 active notes at most. That is not a pricing limit but a technical safety ceiling that protects the run context; once it is full, new lessons update existing notes instead of adding more.
- All notes are recalled at the start of a run. If memory grows past a certain size, pinned notes and rules stay in full and take priority, while the rest drops to a one-line index the agent can open when it needs to. If memory does not answer, the run continues without it rather than waiting.
- Secrets such as API keys and passwords cannot be written to memory, and the system rejects them.
- An agent applies the preferences and rules it is reminded of, but the task's current instructions always win, and a memory note can never grant an agent new permissions.
Clients that connect from outside (Claude Code, Codex or Cursor, for example) join the same
memory, so every agent on the team shares one pool of lessons. A connecting client calls whoami
first; its output ends with the pinned rules and the topic skeleton of memory, and when a tool
touches a collection or a card, the rules bound to it appear at the end of the result. The server
enforces this: results returned before whoami carry a warning. When the client works inside a
repository, Orbi suggests the memory protocol setup once: a section in the instruction file
and, optionally, a hook that pulls memory at the start of every session. Files are written only
when you approve; say "do not ask again" and the suggestion stops. The setup asks which space the
repository works for: each session starts with the memory of that space and Genel, and opening a
card of another space brings that space's rules with the card.