Knowledge Collections

Knowledge lives in Collections — named, reusable bundles of
everything an agent needs to know about a topic. A collection holds
written notes, FAQs, uploaded files, crawled web pages, Notion docs,
YouTube transcripts, and live data sources (Google Sheets, Airtable,
REST endpoints), all in one place. Agents don't own knowledge directly
anymore — they connect to one or more collections, and inherit
everything inside.

The shape of it

• Collections live at the workspace level. Open the Knowledge
• Items inside a collection are mixed-type. A single collection
• Agents subscribe. Each agent's Knowledge sub-page is a

Building a collection

1. Go to Knowledge in the left nav and click + New collection.
2. Give it a name, an icon, and an accent colour. (e.g. "Refunds &
3. Open the collection. You'll see three tabs:

### Items tab
The "things the agent should read" — static knowledge pulled into the
system prompt. Six ways to add an item:

• Write — a manual entry. Title + body.
• Q&A — paste in question/answer pairs; each becomes its own item
• Crawl URL — paste a web URL; we fetch the page, strip
• Upload file — PDF, TXT, or Markdown (max 5 MB). Long files chunk
• Notion / YouTube — coming back into the collection editor; for

### Data sources tab
The "things the agent can look up live" — credentials and config for
Google Sheets, Airtable, or REST GET endpoints. Each data source
becomes a tool the agent can call mid-conversation:

• Google Sheet — pulls rows by query.
• Airtable — queries records with formula filters.
• REST GET — hits any HTTP endpoint and returns the JSON.

Give it a slug name (lowercase, e.g. inventory); the agent calls
it by that name. Paste the credentials — they're stored encrypted.

### Connected agents tab
Multi-select checklist of every agent in the workspace. Tick the ones
that should use this collection. Save replaces the full set — anything
you uncheck gets disconnected.

Connecting from the agent side

You can also wire collections from an agent's perspective. On any
agent, the Knowledge sub-page is now a picker — every workspace
collection appears with a checkbox. Tick the ones you want, hit Save.
Same effect, different angle. Use whichever feels natural for the
moment.

Why this exists

Before Collections, knowledge and data sources lived in two unrelated
places — and knowledge entries were locked to a single agent. Sharing
the same FAQ across three agents meant duplicating it three times,
then editing three copies whenever something changed.

Collections fix all three:

• One bundle, many agents. A "Brand voice" collection on every
• Mixed types in one place. The "Product specs" collection holds
• Build once, reuse anywhere. When you spin up a new agent, you

Migration

Everything from before — knowledge entries you'd written and data
sources you'd configured — was automatically dropped into a default
General collection in each workspace. Every agent that previously
used those items was connected to General. Day-one prompt context is
identical to what it was before.

To reorganise, just create new collections and move items by
recreating them in the right place (each item belongs to exactly one
collection). Or rename General and split items into topic-specific
collections as you go.

A clean pattern

For workspaces with multiple agents on the same business, a
collection-per-topic layout works well:

• Brand voice (one shared collection) → on every agent.
• Refunds & returns → on support + voice agents.
• Product specs (with the inventory Sheet inside) → on sales +
• Sales playbook → on sales agent only.

Each agent inherits exactly what it needs by checking 2–4 collections,
and any change you make to a collection ripples to every agent on it.

Things to know

• Delete a collection to remove it everywhere. Every connected
• Delete an item inside a collection to remove just that item.
• Disconnect an agent by un-ticking the collection in the agent's
• Data sources only surface as tools when an agent connects to the