---
title: "Assets"
url: "/knowledge/assets"
description: "Private, reusable files an agent can find and send in chat, distinct from knowledge sources used for grounding answers."
productArea: knowledge
audience: ["business-user"]
tags: ["assets"]
lastReviewed: 2026-08-27
---

# Assets (/knowledge/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](/knowledge), 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](#which-conversations-an-asset-appears-in).

## Managing assets [#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 [#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.

| Where it came from                      | Who the agent can offer it to                      |
| --------------------------------------- | -------------------------------------------------- |
| You uploaded it to the library          | Anyone the agent talks to                          |
| An agent generated it in a conversation | The customer it was made for, or that conversation |
| A customer sent it in chat              | That customer, or the conversation they sent it in |

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 [#agent-permissions]

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

| Flag | Meaning                                                                                          |
| ---- | ------------------------------------------------------------------------------------------------ |
| Read | The agent can see the asset's metadata — name, description, category — in listings and searches. |
| Send | The agent can deliver the file to a user through the current channel.                            |

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 [#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 [#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 [#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 [#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 [#related-pages]

* [Knowledge sources](/knowledge)