Memory and Storage

Agents get better over time because they keep two kinds of state: memory (what they’ve learned) and storage (the files they work with). Both are inspectable on the agent’s page.

This is what separates the tenth run of a job from the first. Without persistent state, every run starts from a blank slate and you re-brief the agent on the same quirks — the fiscal calendar, the report format you actually want, which alerts are noise. With it, corrections stick, working files carry forward, and the agent you have in month three is measurably more useful than the one you created. The two kinds of state divide cleanly: memory holds facts and lessons, the things an agent should know; storage holds files, the things an agent is working on.

Memory

The Memory card holds the notes the agent keeps for itself as it works. Each entry shows when it was created and updated and how often it has been used, and expands to show its full value. Every entry keeps revision history — open View history to see how a memory evolved and restore an earlier version if an update went wrong.

In practice, entries read like the notes a careful new hire keeps. After a few weeks of running a Monday pipeline report, an agent’s memory might contain:

• “The team’s fiscal year starts in February; quarterly summaries should break at February, May, August, and November — not calendar quarters.”
• “Dana wants the pipeline report as a single table with week-over-week deltas, no executive-summary paragraph.”
• “Deals whose champion has left almost never close; flag them separately rather than counting them in the weighted total.”

Each of those was earned once — from a correction, an answered question, a pattern the agent noticed — and applies to every run after.

You don’t write memories by hand; the agent stores them as it learns from conversations. Correct it in conversation (“actually, our fiscal year starts in February”) and the correction becomes memory.

Correct in conversation, not in the output

When an agent gets something wrong, the instinct is to fix the deliverable and move on. Say it to the agent instead — “we report in fiscal quarters, starting February” — and the fix becomes memory, so you never make the same correction twice. This is also the remedy for a wrong memory: state the correction plainly, or restore an earlier version from the entry’s history.

Dreams

Once a day, while idle, the agent consolidates what it has learned and logs it in the Dreams tab. Each dream is an audit of the consolidation — which memories were merged, promoted, updated, or forgotten, and any skill or personality it refined along the way, with the text before and after — so even the agent’s housekeeping is transparent. Whether an agent may improve its skills and personality while dreaming is its own self-improvement guardrail. An agent dreams after work for someone who can edit it, and waits when the person it was working for cannot.

Consolidation is what keeps a busy agent’s memory from silting up, and the Dreams tab means it never happens invisibly. If an entry you cared about changed overnight, the dream that changed it says so, and the entry’s revision history lets you put it back.

Reflections

A dream tidies what the agent already wrote down. Once a week the agent also does what a good colleague does at the end of a week: it reads how its work was received and where it struggled, decides what to change, and changes it. That review is the agent’s weekly reflection, and it is the part of self-improvement driven by what actually happened to its work.

The platform gathers the week’s record; the agent doesn’t write it and can’t edit it. It holds:

• The sessions it worked in, which it reads for itself: where people corrected, redirected, or stopped it, and where it struggled with errors, retries, dead ends, or work it abandoned. It can search across the week and read the lead-up to any moment.
• Thumbs-down ratings, with the category and comment people left.
• How its channel posts landed. For each thread the agent started, did anyone reply within a day, only react, or say nothing?
• Outcomes — failed runs, and document suggestions people rejected.
• What it said last week it would change, so each reflection checks whether the last one’s changes worked.

Reviewing your own work invites a charitable reading, so before it decides, the agent is told to get a blunt, third-party review of the moments that matter from a separate model. Then it decides what, if anything, to change, using the same tools it always has. A fact someone had to supply becomes memory; a correction that keeps recurring becomes a skill; a lesson the whole team would benefit from goes into knowledge or a skill it nominates for the workspace; and when a change is one its team would notice, it tells them. Changing nothing is a valid outcome of a good week, and a week with nothing worth reflecting on is skipped without starting a session.

Read them in the Reflections tab, beside Dreams. Each week leads with what the agent said it changed — or why the reflection didn’t run — and opens into the session where it happened, so you can see exactly what it read and every change it made. The tab is also where you choose when the agent reflects: Friday, Saturday, Sunday, or Monday, at the time you pick in your own timezone. A new agent reflects on Friday afternoon UTC until you pick a time. To stop its reflections, turn off Reflect weekly in its guardrails.

The record only quotes conversations its readers can already see. A shared agent’s reflection is visible to the whole workspace, so it draws only on shared conversations; a private conversation someone had with that agent never appears in it. A private agent’s reflection belongs to its owner and may also draw on the owner’s own private sessions.

A reflection is a short session, billed like any other. It runs under the agent’s ordinary guardrails and gains no permission it didn’t already have; turn off Reflect weekly in its self-improvement guardrails to stop it entirely.

Library

The Code library tab of the agent’s Abilities holds Python code the agent has saved to reuse: a walk through a paginated API, the column quirks of a report it parses every week, a retry wrapper it would otherwise rewrite. An agent saves the code worth keeping during a session, and every later session can import it.

Each module shows its name, its one-line description, and the functions it offers, which is what the agent itself is shown when deciding whether to reuse it. It also shows when it last changed and how (in a session, in a dream, or by a person), and how often sessions have imported it. A module that is never imported is a sign the agent saved something it doesn’t reach for. Open one to read its source.

While idle, an agent may refine a module it has saved, for instance to handle a case its memory shows it keeps tripping over. It only edits modules that already exist, and a refinement that removes or reshapes a function, class, or constant the module offers is refused. It cannot run the code while dreaming, so a refinement is not tested until a session uses it. Recent versions are kept: open View history to compare them and restore an earlier one. The agent picks a restored version up at its next session.

You can restore or delete a module if you can edit the agent; you can’t edit its code here, since the Library is the agent’s own. Deleting a module removes its history too. To stop an agent saving code, turn off Write custom code libraries in its guardrails. Its saved modules are kept but no longer loaded into its sessions, and they return when you turn it back on.

The Library is private to the agent. Agents don’t share code with each other.

Storage

The Storage card shows the files the agent keeps between sessions: its home directory. Each session leaves a new version behind, and the next session starts from the latest one. The card shows the total size across versions, when the home was last captured, a Version history with each version’s size and age, and a Previously stored list of versions that were deleted or aged out.

Storage is where an agent’s work-in-progress survives between sessions — the draft it was iterating on, a dataset it assembled over several runs, the scratch notes an assignment builds up week over week. Anything the agent writes outside its home directory is gone when the session ends.

Version history doubles as an undo. If a run leaves the files in a bad state — a draft overwritten, a dataset mangled — deleting the current version rolls the home back to the one before it; deleting an older version just drops that point from the history. Delete storage removes every version, and the agent’s next session starts from an empty home while its abilities, memory, and assignments stay as they were. Deleting requires owner-level access to the agent, and neither kind of delete can run while a session is working from the home.

Treat storage as a working cache. A home is a disk of fixed size (the value is on the Limits page), and everything on it is saved, caches like node_modules and .cache included. When the disk is full, writes fail inside the session just as they would on a full laptop drive, so keep large downloads and build output out of the home directory. A session’s workspace is removed once it has been idle for 30 days. A version’s size is the size of its saved disk, which includes the disk’s own bookkeeping, so even an empty home shows some space in use.

In the rare case a stored home cannot be restored, the agent starts from an empty one rather than failing, so anything that must last belongs in a document, a data table, or knowledge, and code the agent means to reuse belongs in its Library. Because memory and storage are independent, tending one never requires touching the other.

Keeping an agent’s state healthy

• Teach through conversation — corrections said to the agent become memory; corrections made silently to its output do not.
• Skim the Memory card periodically — especially for a shared agent your team relies on, the entries are a fast read on what it believes.
• Read the dream after an intense week — a burst of sessions means a burst of learning, and the consolidation log shows what stuck.
• Read the weekly reflection — it is the shortest honest account of how the agent’s week went: what people had to correct, and what it changed because of it.
• Prefer restore to re-teaching — when a memory update or a storage version went wrong, rolling back is faster than explaining everything again.

Whether an agent may form memories at all is one of the self-improvement guardrails, so an agent’s capacity to learn is itself something you control.