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.
Files
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. SENSITIVEMemories
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.Chat history
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. SENSITIVENotice 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, onceAgency operator · asked to “clean up what the agent knows”
The client means the agent’s learned memories, not their uploaded documents. Confirms
covered in full in the section belowagent_memories and files are both granted before starting, since reviewing memory content actually happens through Files, not through the Memory nav item.Read this before you go looking for a memory editor
So three different questions route to three different scopes, and none of them is the one you’d guess: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.
“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.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.I have agent_memories granted and the Memory page is still empty
I have agent_memories granted and the Memory page is still empty
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.The client wants me to stop an agent from writing to a specific memory bucket
The client wants me to stop an agent from writing to a specific memory bucket
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.Why does agent_memories exist at all if it doesn't open an editor
Why does agent_memories exist at all if it doesn't open an editor
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.
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.
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.
Each of these fails the same way: the agent attempts the call, and the session returns “Permission denied: reseller delegated session does not include 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.Without tools_and_integrations, does the agent lose everything?
Without tools_and_integrations, does the agent lose everything?
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.I have tools_and_integrations, why can't the agent connect a new app?
I have tools_and_integrations, why can't the agent connect a new app?
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 for that limit, it’s permanent and doesn’t loosen with more scopes.
What’s actually inside Memories
“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: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.
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.
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
about 5 minutesagent_memories toggle, which wouldn’t have targeted the actual bucket at all.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.
1
Open the delete action on a file
A confirmation dialog appears immediately. Title: Delete ""? Body: “This permanently removes the file from disk and revokes future agent access. This cannot be undone.”
2
Confirm you understand, then confirm again by typing the filename
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.
3
The file, and its sidecar, are gone
Success shows as: "" 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.
- 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.
A file uploaded fine but won't open when I click it
A file uploaded fine but won't open when I click it
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.
I tried to edit a file and the editor won't let me type
I tried to edit a file and the editor won't let me type
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.
Should I delete a file if I'm not sure the client still needs it
Should I delete a file if I'm not sure the client still needs it
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.
The honest part
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.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: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.
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.
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.
Files
The workspace filesystem in full: folder structure, uploads, and how agents retrieve from it.
Memory
Buckets, retrieval, and how the background memory process actually works outside a delegated session.
Client permissions
All eight toggles in one place, including the two, files and chat history, that carry the SENSITIVE chip.
Client success best practices
Where the habit of agreeing scope up front and summarising changes afterward fits into a full engagement.