Assets

Assets are private, reusable files — QR codes, brochures, menus, forms, and similar media — held in your workspace's asset library and granted to specific agents to discover and send in chat. Unlike a knowledge source, which is chunked and retrieved as text to ground an answer, an asset is delivered as-is — the agent sends the actual file, or a short-lived signed link, to the end user. For example: "send me the PayNow QR code."

Assets reach the library three ways: you upload them, an agent generates an image during a conversation, or a customer sends a file in chat and the agent keeps it. All three belong to your workspace and count toward your storage. What differs is who an agent may offer them to — see which conversations an asset appears in.

Managing assets

From Assets in the dashboard sidebar:

• Browse the library — see every asset with its category, file type, and status. The default Library view shows files you uploaded. Switch to Generated for images your agents produced, or All to see everything together. Generated images are kept out of the default view because they accumulate quickly and would otherwise bury your curated files.
• Upload a file — select Upload Asset, pick a file (images, QR codes, PDFs, and other supported types up to 1 MB), and set a name, description, category, and tags.
• Edit or archive — update an asset's metadata, archive it to hide it from active listings (reversible), or delete it permanently.
• Grant agent access — on an asset's Permissions tab, grant or revoke a specific agent's read and send access. Access is deny-by-default — an agent sees nothing until it is explicitly granted.

Which conversations an asset appears in

A grant says which agent may use a file. Separately, each asset records which conversations it may appear in — so a file that belongs to one customer is never offered to another.

Which of the two applies depends on how the customer reached you. On WhatsApp and Telegram the platform tells us who is writing, so the file stays with that customer and they can still ask for it in a later conversation. On the website widget anyone can type any email address, so we treat the file as belonging to that conversation rather than to the person — it is available for the rest of that chat, and not afterwards. That is deliberate: it is the only way to be sure one visitor cannot see another's files by guessing their email.

This is enforced on the server on every attempt. It is not affected by the grant: an agent with full access to an asset still only offers it in the conversations above.

To turn a generated image or a customer's file into a reusable workspace file, open it and select Share with all conversations. Owners and admins can do this; share only files that are genuinely reusable and contain nothing personal.

You can take a shared file back out of circulation at any time with Restrict to internal only — agents stop offering it in chat, while it stays in your library and still counts toward storage. What sharing cannot undo is the link to the customer it came from: once a file is shared it is no longer tied to anyone, so restricting it makes it internal rather than returning it to that customer.

If the customer an asset belongs to is deleted, the file stays in your library and keeps counting toward storage, but agents stop offering it in chat.

Agent permissions

Every grant is scoped to one agent and has two independent flags:

There is no implicit inheritance. An agent with read but not send access can tell a user the file exists but cannot send it; access checks happen server-side on every attempt, not only at grant time.

Uploading from chat

An asset does not have to come from the dashboard — an agent with the right tools can persist a file a user just sent in the conversation, such as a payment-proof screenshot, directly as a durable asset, without a separate upload step. The file is kept to that customer, so a document one person sends is never offered to another.

Generated images

When an agent generates an image, it is kept in the library so the agent can send it again later in the same conversation, and so the file is accounted for rather than expiring. Two things follow:

• Generated images count toward your workspace storage and stay until you delete them.
• The library name describes the picture, not the request. What the customer actually typed stays in the conversation, where access is restricted to owners and admins and every view is recorded — it is not copied onto the file where the whole team would see it.

Linking an asset to knowledge

An asset backed by a real file can also be indexed as a knowledge source — useful when the same uploaded document should be both sendable as a file and searchable as grounding content. Enable this from the asset's detail view; the two records share the underlying stored file.

Access logs

Every view, link generation, send, upload, and delete against an asset is logged with the acting agent (if any), channel, and timestamp, visible from the asset's detail view for auditing who accessed what and when.

Signed links for assets are short-lived by design. If a user needs a link again later, generate a fresh one rather than reusing an old link from earlier in the conversation.

Related pages

• Knowledge sources