Tell an agent "track competitors' price changes" and the first run is useful. So is the second. On the third you ask, what did it find last month?
The answer depends on where the output was written. If it went into a chat, it stayed in that window. If it landed under a card as a comment, it dropped out of the stream when the card closed. If it was written into a collection, it is both still there and something you can work with.
A collection is the layer where agent output accumulates and can be worked with. It looks like a table, and it filters, sorts and exports.
Start without a schema, then structure it
Every collection starts with at least a title and a content field. An agent can begin writing without any schema being defined.
Add columns and the collection turns into a full table. Filtering, sorting, paging and export come in at that point.
That order is deliberate. Designing the schema correctly up front is hard, because you only see which fields you need once data has started to accumulate. Opening ten columns on an empty table ends with three in use and seven left blank.
The field type decides how the data is read
There are separate types for short text, long text, rich text, address, email and phone. On the number side there are plain number, currency, percentage and star rating. Date, yes-or-no checkbox, single choice from a closed list and free tags each have their own type.
The difference between a closed list and tags comes down to "how many values". A record has one status, but it can have several topics. When you type a tag, the ones you have used before are suggested, so you do not save the same thing under two spellings.
File and image are uploaded to the same place but read differently. A file answers "which document", an image answers "what does it look like". An image sits in the table as a thumbnail.
If you mark a field required, no record can be written with that field empty. That rule applies to agents too, because the schema goes to them as well.
Write what each field is for
You can add a purpose note to every field. The agent reads that note when deciding what to write into the field.
Write "a one- or two-sentence summary of the record, not the full content" on the summary field and the agent stops copying the whole article into it. One sentence permanently fixes a mistake that repeats on every run.
The other way to tell the agent is to repeat the same instruction on every card, and that gets tiring. A field note is written once and travels with the schema into every run.
Let an agent fill a column
Some fields get their value from an agent rather than from you. When adding the field you write which agent runs and what it should produce. "Look at the company name and sector, score fit out of a hundred, write only the number", say.
The agent sees the other fields on the row, so it is not scoring in a vacuum.
Filling is started by hand. You can fill a single cell or the rows visible on screen. It not being automatic is deliberate, because sending a whole table to the model without realising is the most expensive thing you can do. You can correct the generated value by hand afterwards.
Do not let the same record be written twice
This is the most annoying problem of a job that runs on a schedule. Every run, the agent re-records the same news item in slightly different words, and within a few weeks the collection is unreadable.
A classic unique-field rule is not enough here. The same development can be written in two different sentences, and text comparison cannot catch that.
Orbi looks at similarity of meaning instead. When an agent wants to write a new record, its meaning is compared against the existing records, and if the similarity threshold is crossed the write is blocked. The agent takes that not as an error but as "this already exists".
You switch this on in the collection settings and say which field identifies a record. The title usually does the job.
Linking records to each other
You can link a record to a record in another collection. Which company a person belongs to, or which customer a deal is tied to, is kept this way. Once the link is in place you can filter by that field.
Agents make the link by naming the record. The system resolves what was named to the right record, so the agent has nothing new to learn.
Accumulated data can become a screen
Once a collection starts earning its keep, an admin can put it in the left menu as a permanent screen. From then on the team goes straight there without passing through the "collections" page, and the collection starts to look less like a table and more like an app screen the team uses.
You can also duplicate a working collection. When setting up the same schema for a second client or a second topic, you do not redefine the fields one by one.
Where to start
Open a collection and add no column beyond title and content. Have the agent write its output there and wait for a few runs to accumulate.
Then look at the records and you will see which information you want to filter by. Open the columns at that point, write a purpose note on each, and if a scheduled job is involved, switch on duplicate prevention.
Field types, the agent column and duplicate prevention are covered in Collections in the help center. Turning accumulated data into a screen is possible too, and that part is described in Screens.
If you want to try it, you can open a free account and set up your first collection.