> ## Documentation Index > Fetch the complete documentation index at: https://learn.actionist.ai/llms.txt > Use this file to discover all available pages before exploring further. # Files, memories and chat history > Three different stores, three separate permissions, and the care each one deserves when you are working inside somebody else's business.
HANDLE WITH CARE

You are inside somebody else's business. Treat what you find in it with the same care.

Files, memories and chat history look like one thing from the outside: a client's data. They are three separate stores, governed by three separate permissions, and one of them does not behave the way its name suggests. This page walks through what each store actually is, the trap most resellers fall into with agent memories, the three states of chat access, what a missing scope quietly takes away from the agent, and the precise, permanent line a two-stage confirmation draws before anything is deleted.

The confusion, up front

Three stores, three permissions.

Every one of these names sounds like it could mean the others. It doesn't. Read this section before the rest of the page, because the sections that follow assume you already know which store is which.

The static source assets somebody uploaded: documents, PDFs, datasets. They live in a real workspace filesystem, a shared `company/` area plus one folder per agent. Uploaded by the client's team. Governed by the `files` scope. SENSITIVE What an agent learned while working. Markdown files, written automatically by a background memory process, stored under that same workspace and mirrored into a search index. Governed by the `agent_memories` scope. Not marked sensitive in the client's panel. The transcript of conversations between the client's team and their agents. Written by nobody directly, it accumulates as those conversations happen. Governed by the `chat_history` scope. SENSITIVE | Store | What it holds | Written by | Scope | Sensitive | | ------------ | ----------------------------------------------------------------------------------------------- | ----------------------------------------------- | ---------------- | --------- | | Files | Static source assets: documents, PDFs, datasets uploaded by the client's team | The client's team, through uploads | `files` | Yes | | Memories | Markdown files recording what an agent learned while working, formed during client interactions | A background memory process | `agent_memories` | No | | Chat history | The full conversation transcript between the client's team and their agents | Generated automatically as conversations happen | `chat_history` | Yes | Notice what's actually different between rows. Files is content someone chose to add. Memories is content the agent produced on its own, as a side effect of doing its job. Chat history is neither, it's a record of what was said, not a document and not a fact the agent decided to keep. Three different origins, which is exactly why one blanket "data access" toggle would never have worked here. The client's permission panel marks Files, Chat history and Billing summary with a **SENSITIVE** chip. Agent memories does not carry that chip, even though it is the one most people assume is the most sensitive of the three. Sensitivity, in this panel, tracks what a human reseller can read directly, not how personal the underlying data feels. Keep that distinction in mind through the next section, it is the whole reason the memory scope surprises people.
Agency operator · first session with a new client
Sees "Files" and "Memories" both mentioned in the client's grant list and assumes they're the same permission covering everything the agent knows. Opens the panel, reads the description text under each toggle, and realises Files is what the client uploaded while Memories is what the agent has since learned on its own.
about 2 minutes to sort out, once
Agency operator · asked to "clean up what the agent knows"
The client means the agent's learned memories, not their uploaded documents. Confirms `agent_memories` and `files` are both granted before starting, since reviewing memory content actually happens through Files, not through the Memory nav item.
covered in full in the section below
Read this before you go looking for a memory editor

The memory trap.

Of everything on this page, this is the single most common source of confusion. It costs almost nothing to get right once you know it, and it wastes real time if you don't.

Granting `agent_memories` does **not** open a memory editing screen. In a delegated session, it unlocks a Memory item in the navigation, and that item is a placeholder. It does not render a list of memories, a search box, or an edit form. It points you back to the workspace files instead. What `agent_memories` actually does is let the agent itself use its memory lookup tools, `memory_search` and `memory_get`, while you are working inside that delegated session. It is a permission for the agent's own behaviour during your session, not a permission for you to browse memory content as a human. Reading or editing the memory content that the background process has written happens through **Files**, because those Markdown files live in the ordinary workspace filesystem. That needs the `files` scope, not `agent_memories`. Changing what an agent is *allowed* to do with memory, which buckets it can read from or write to, happens in **Agent Studio**. That needs `prompts_and_instructions`, again not `agent_memories`. So three different questions route to three different scopes, and none of them is the one you'd guess:
"Can the agent use its memory right now?" That's `agent_memories`. It governs the agent's own tool calls during the session, nothing about what you personally can see.
"Can I read or edit what the agent remembered?" That's `files`. Memory content is Markdown, and Markdown lives in the workspace filesystem, which is where Files opens it.
"Can I change which buckets the agent is allowed to touch?" That's `prompts_and_instructions`, in Agent Studio, where agent configuration lives.
In practice this means a client can grant you `agent_memories` in good faith, expecting you to be able to review what an agent has learned, and you will land on a Memory nav item that goes nowhere useful. If that happens, don't assume the feature is broken. Check whether `files` is also granted, that is almost always the scope you actually needed. It's worth explaining this to a client the first time it comes up, rather than letting them assume you have less access than you actually do. A client who sees you land on an empty Memory page might conclude the grant didn't take effect, when really it's working exactly as intended, just not through the screen either of you expected. That's expected, not a bug. The Memory nav item is a placeholder regardless of what's granted. Ask the client for `files` if you need to actually see what the agent has stored, and open it through the Files view once you have it. That's not something `agent_memories` controls either. Bucket-level read and write permissions live in Agent Studio, alongside the rest of that agent's configuration, and need `prompts_and_instructions` to reach. See the bucket section further down this page for the exact permission values involved. It still does real work, it decides whether the agent can call `memory_search` and `memory_get` while you're delegated into the session. Without it, the agent effectively forgets it has a memory at all for the duration of your session, even though the underlying files are untouched.
Reading versus replying

Chat history and the three access states.

Chat history has a wrinkle that Files and Memories don't: seeing a conversation and taking part in it are gated by two different scopes, and the combination you hold decides which of three states you land in.

| State | Scopes held | What you see | | ----------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Blocked | No `chat_history` | The conversation list shows: "Ask the client to grant access to chat history so you can view this." | | Read-only | `chat_history`, without `prompts_and_instructions` | The full history is visible. The composer is disabled. The hint underneath it reads "View-only access", and hovering it shows the tooltip "Agent execution wasn't granted in this view-only session." | | Interactive | Both `chat_history` and `prompts_and_instructions` | The full history is visible and the composer works normally, same as any other agent conversation. | Read-only is the state that trips people up, because everything on screen looks normal except one disabled input. If you're staring at a transcript wondering why you can't reply, check whether `prompts_and_instructions` is granted alongside `chat_history`. Chat history alone only ever gets you to read-only, by design. Attempting to modify a conversation without both scopes hits a hard stop at the application level, not just a disabled button: "Conversation History and Agents permissions are required to modify conversations in View as Client mode." If you ever see that message, it means the composer being disabled wasn't a rendering quirk, the backend is enforcing the same boundary the UI already showed you. This pairing is deliberate, not an oversight. `chat_history` answers "can this reseller see what was said". `prompts_and_instructions` answers "can this reseller act as the agent". A client who is comfortable with the first is not automatically comfortable with the second, and the product keeps those two decisions separate rather than collapsing them into one toggle. Scope names shorten depending on where you're looking, and that's cosmetic, not a second permission. The session banner's permissions summary uses short labels, **Memories** rather than Agent Memories, **Tools** rather than Tools & Integrations. A lock overlay on a blocked page spells out the long form instead. Same underlying scope either way, so don't read a longer label as a stricter or different requirement.
Behind the scenes

What the agent can still do.

Every scope you don't hold quietly removes a matching set of tools from the agent, not just a nav item from your view. If an agent seems to ignore a request while you're in a delegated session, this table is usually why.

| Missing scope | What the agent loses | | ------------------------ | ------------------------------------------------------------------------ | | `files` | Every file tool, plus the terminal tools | | `agent_memories` | The `memory_search` and `memory_get` tools | | `skills` | The skill tools | | `tools_and_integrations` | The entire external tool list, emptied outright, plus the terminal tools | | `calendar_and_schedules` | Schedule management | Each of these fails the same way: the agent attempts the call, and the session returns "Permission denied: reseller delegated session does not include {'{scope}'} access." with the specific missing scope named in place of `{'{scope}'}`. It is not a silent no-op, the agent will surface that it was blocked and why. Terminal access is the one item that shows up under two different rows, and that's not a mistake. It needs **both** `files` and `tools_and_integrations` at once. Losing either scope alone is enough to take the terminal tools away, even if the other one is still fully granted. If a client wants you to be able to run terminal commands on their agent's behalf, both toggles need to be on, not just one of them. Everything external, yes. Its whole tool list for third-party apps and MCP servers is emptied outright, on top of losing the terminal tools and screen control. What survives is whatever doesn't depend on an external connection, chat itself, and anything covered by scopes you still hold, like memory lookups under `agent_memories` or file access under `files`. That's a different boundary entirely, not this scope. Connecting credentials or authorizing a new app is blocked for any active delegated session, regardless of which scopes you hold. See [Credentials and API keys](/resellers/credentials) for that limit, it's permanent and doesn't loosen with more scopes.
What's actually inside Memories

Memory buckets and permissions.

Once you're in Files looking at what an agent has learned, it helps to understand the shape of what you're looking at. Memory is organised into buckets, and each bucket carries its own permission, not one blanket setting for the whole store.

"Memory is bucketed by scope so an agent only sees what it needs. Read lets the agent recall facts; Read & write lets it save new ones." That's the product's own framing, and it is the right mental model to carry into any client workspace: a bucket is a scope boundary, not just a folder. Buckets are Markdown files and folders on disk, not rows in a database. A workspace starts with a default set: **business info**, **products**, **policies**, **operations** and **CRM**, and the client can create more on top of those defaults as their agents' needs grow. Each bucket carries exactly one of three permission values, written precisely: | Permission value | What it means for the agent | | ---------------- | ------------------------------------------------------------------------------------------------- | | Read/Write | The agent can recall facts already in this bucket, and save new ones back into it. | | Read | The agent can recall facts already in this bucket, but nothing it learns is written back into it. | | No access | The agent cannot see this bucket at all, in either direction. | This is what "only sees what it needs" means in practice. A finance agent might hold Read/Write on operations and Read on policies, while having No access to CRM entirely, and that's a normal, intentional configuration rather than an oversight to flag. | Default bucket | Typical contents | | -------------- | ------------------------------------------------------------------------------------------------- | | Business info | Company background, mission, org structure, the kind of context that rarely changes week to week. | | Products | What the client sells, feature details, pricing structure. | | Policies | Internal rules and external commitments the agent should respect when acting. | | Operations | Day-to-day process detail an agent picks up while doing recurring work. | | CRM | Facts about specific clients or contacts the agent has interacted with. | A client can add buckets beyond these five as their agents take on new kinds of work, there's nothing fixed about the default set beyond it being where every workspace starts.
Agency operator · agent oversharing CRM detail
A client flags that a support agent is referencing account details it shouldn't need. Opens Agent Studio, finds that agent still holds Read/Write on CRM from an earlier setup, and drops it to No access instead of touching the `agent_memories` toggle, which wouldn't have targeted the actual bucket at all.
about 5 minutes
Bucket-level permissions are set per agent in Agent Studio, the same place that owns the memory scope decision covered in the section above. If a client wants an agent to stop writing to a particular bucket without cutting off memory access entirely, dropping that one bucket from Read/Write to Read is the precise tool for it, not the `agent_memories` toggle. See [Memory](/Folders/memory) for the full reference on how buckets, retrieval and the background memory process work outside the reseller context.
The one that can't be undone

Working with files safely.

Files is the only one of the three stores where you can permanently destroy something that belongs to the client. The product puts real friction in front of that, and it's worth knowing exactly what that friction looks like before you're the one clicking through it.

A confirmation dialog appears immediately. Title: Delete "{'{{name}}'}"? Body: "This permanently removes the file from disk and revokes future agent access. This cannot be undone." A second stage asks you to retype the exact filename before anything happens: "Type the filename below to permanently delete this file." The action button reads "Delete permanently", and it stays inert until what you typed matches. Success shows as: "{'{{name}}'}" has been permanently deleted." Deleting a file also deletes its extracted AI sidecar in the same action, so the file disappears from agent retrieval at the same moment it disappears from disk. There is no separate step and no separate undo for the sidecar. There is no recovery path once both stages are confirmed. The confirmation copy says "This cannot be undone" and means it literally, there is no trash, no version history, and no support-side restore implied anywhere in this flow. Typing the filename is not a formality, it is the only thing standing between a single misclick and a client permanently losing a source document. Two other things worth knowing before you touch a client's Files tab: * **Memory-managed files render read-only.** Any file the background memory process owns shows the message "This file is managed by the Memory Agent and can't be edited here." when you try to open it for editing. That's expected, it's the same store the memory process writes to, not a permissions bug on your session. * **Two size limits govern different things, and they're easy to mix up.** Upload is capped at **25 MB per file**, that's the ceiling on what can be added to the workspace at all. Separately, any file over roughly **10 MB will not open as text inside the app**, regardless of whether it was uploaded successfully, and has to be downloaded to be read. A file can be well within the upload limit and still need downloading to actually view. Check its size before assuming something is broken. Files over roughly 10 MB don't render as text inside the app at all, even though they uploaded successfully under the 25 MB ceiling. Download it to read it, that's expected behaviour for larger files, not a failed upload. Look for the message "This file is managed by the Memory Agent and can't be edited here." That means the background memory process owns this file, and it's read-only by design. If it genuinely needs a correction, that's a change to make through the memory process's own inputs, not by hand-editing its output. Ask first. There is no undo once both confirmation stages are complete, and the sidecar goes with it, so the agent's retrieval loses that source at the same moment. A quick check with the client costs a minute, a wrongly deleted source document costs the client real work to reproduce. See [Files](/Folders/files) for the full reference on the workspace filesystem, folder structure, and how agents retrieve from it.
The honest part

Leaving a clear trail.

There is no client-facing "what did my reseller change" view today. A client sees the resulting state of their workspace after you've worked in it, the same way they'd see any other change, with nothing that specifically calls out that a reseller was the one who made it.

Every action taken inside a delegated session is recorded server side. That record exists, but it isn't surfaced to either party inside the app yet, not to you as a summary of what you did, and not to the client as a log of what a reseller touched. So the honest version of this section is simple: **the product will not tell the client what you changed. You have to.** Two habits cover almost every case: agree with the client in advance on what you're going to touch during a session, and send a short summary afterward of what actually changed. Neither takes long, and both matter more here than in most parts of the product, because Files, Memories and Chat history are exactly the stores where "I assumed you knew" causes the most friction with a client later. A summary doesn't need to be long to do its job. Something as short as this, sent right after you exit a session, covers the essentials:
email · session summary
Quick note on today's session in your workspace:
Removed two outdated PDFs from Files (2024 pricing sheets, superseded by the ones you sent last week).
Adjusted the support agent's memory permissions so it no longer writes to the CRM bucket.
Nothing else touched. Let me know if anything looks off.
This isn't a compliance lecture, it's the practical fallback for a gap that genuinely exists today. Until a built-in activity view ships, a two-line message after a session, what you edited, added, or deleted, is the only record the client will actually see with your name attached to it.
Handle with care

Know which store you're in.

Files, memories and chat history each carry their own scope and their own risk. A minute spent checking which one you need saves an afternoon of confusion later.

Agent memories unlocks agent behaviour, not a browsing screen. Files and chat history both carry the SENSITIVE chip for a reason.
Deletion is permanent the moment the second confirmation matches, and no activity view watches it for you yet.

Keep going

Next steps.

The workspace filesystem in full: folder structure, uploads, and how agents retrieve from it. Buckets, retrieval, and how the background memory process actually works outside a delegated session. All eight toggles in one place, including the two, files and chat history, that carry the SENSITIVE chip. Where the habit of agreeing scope up front and summarising changes afterward fits into a full engagement.