Memory and context

This is what surprises people most when they first use Orbi, and it is a deliberate design decision.

#The lesson carries over, the history does not

An agent does not remember what it did on another task last week, or which report it wrote yesterday. Every run starts clean.

What does carry over are the short notes distilled from those runs, and every note in scope is brought back to the agent by itself at the start of each new run. Most of the time these notes write themselves, so you make a correction once and the system keeps it as a lesson (Workspace memory). What is remembered, then, is not the past itself but the lesson that came out of it.

Raw history stays behind for this reason. Putting the whole history into every run breaks two things at once. The context grows without limit, so cost and latency go up. The agent also starts mixing irrelevant old information into the current job, and it does that quietly. Orbi uses two separate channels instead, memory notes for lasting lessons and explicit references for what belongs to this one job.

#References: mentions

You point at something with a mention.

Look at the last 10 records in the @collection.content_ideas collection,
take the feedback on @task.142 into account, and match the tone of voice
in the @file.brand-guide file.

The full list: Mention syntax.

#A mention is a pointer, not a copy

The content of what you mention is not injected into the context automatically. The agent only learns "there is such a thing and this is its name", and when it needs the content it pulls it with its own tool.

The reason is token economy. If you mentioned a collection with 500 records and all of them were copied into the context, it would be expensive and the model would lose the actual job in the crowd. This way the agent picks the part it needs and reads that.

#What exactly does an agent see?

It sees these, in order.

flowchart TB
  W["Workspace context"] --> P["Project description"]
  P --> D["Today's date"]
  D --> T["Task: title · description<br/>priority · label · state"]
  T --> C["The collection list in the workspace"]
  C --> CL["Current checklist state"]
  CL --> S["Overall summary"]
  S --> CM["All comments (chronological)"]
  CM --> M["Memory notes in scope"]

Each of these layers does a job.

• Workspace context and project description answer "who is this work for, in what context". Leaving the project description empty is the biggest loss of quality here. Both have a length limit: the workspace context can be at most 4000 characters and a project description at most 2000 characters. The counter also counts bold, heading and mention markers, because that is the text the agent receives. A text over the limit is not saved, and the counter tells you how many characters to cut.
• Today's date is needed because models take their own training date for "today", and without this line phrases like "last quarter" are worked out wrongly. Dates and times are given in the workspace timezone: agents read comment and file timestamps in your clock and talk to you in it. The zone is taken from your browser when the workspace is first created, and can be changed under Settings → General.
• The collection list is there so the agent uses what already exists instead of opening a new collection for the same purpose.
• Checklist state shows where things were left, so a completed step is not repeated.
• Overall summary is the distilled form of the earlier cycles on long tasks.
• Comments carry human feedback and other agents' notes.
• Memory notes carry the lasting lessons learned across runs. The block comes last, so data arrives after instructions.

#Sub-agents see less

The sub-agents the Orchestrator calls get a narrowed brief, and the checklist, the comments and the memory block are left out of it. The reason is both token economy and focus, because an agent doing "pull out the third competitor's pricing" does not need the whole discussion history. If a sub-agent needs memory, it queries it with its own tool.

#Where does persistent knowledge go?

If you want a piece of knowledge to live across tasks, there are four right places.

Chat history itself is not one of them. What was said in a chat does not carry into the next task, and the only thing that carries is the memory note distilled from that chat.

#The same applies to flows

A scheduled job also carries the lessons it learned, but it does not remember the output of its own previous run. If you want it to "know what it wrote yesterday", the way goes through storage. The job writes its output to a collection, and the next run reads that collection. This also brings in the mechanism that prevents writing the same thing twice, described in semantic duplicate prevention.