---
title: Assistant and Knowledge Basics
tag: assistant-knowledge-basics
summary: 'Use the built-in assistant with documents, tables, workflows, and memory.'
---

# Assistant and Knowledge Basics

The Canopy assistant is built into the workspace. It can read documents, query tables, search memory, use tools, and work with workflows when its agent has access.

Use it like a teammate with access to the workspace, not like a blank chat box.

## Ask for one concrete task

Good prompts name the source and the desired output:

> Summarize the onboarding notes into five bullets.

> Find the highest-priority rows in the leads table and draft follow-up actions.

> Create a short report from the latest research documents.

> Remember that project briefs should use direct bullet points.

Broad prompts work better after the relevant documents, tables, or memory already exist.

## Use the right storage for the job

Canopy has several places for knowledge:

- **Documents** — long-form notes, drafts, summaries, PDFs, reports
- **Tables** — structured records with typed columns: leads, tasks, entities, repeated data
- **Memory** — durable facts and semantic recall for agents and workflows
- **Workflows** — repeatable processes the assistant can inspect or run when allowed

The assistant works best when each kind of data lives in the right place.

## Documents for prose

Put narrative material in documents: meeting notes, research summaries, plans, drafts, PDFs, and reports.

Then ask:

> Using this document, extract decisions and action items.

> Rewrite this draft in a sharper style.

> Turn these notes into a client-ready summary.

## Tables for structured data

Put repeated records in tables: customers, vendors, tasks, bugs, companies, articles, opportunities.

Then ask:

> Which rows are blocked?

> Group these companies by status and priority.

> Add a next-step column for the rows that need follow-up.

Tables can store nested JSON as well as typed columns, so they work for clean records and messy API-shaped data.

## Declaring what a row is

A table's columns carry kinds, not just names: a fixed set of options, a calendar day, an instant, a number, a linked document, rich text, a list, a nested shape. Choosing the narrowest kind that fits is what makes a row a thing you can name and act on rather than a set of loose strings.

> Give my `media-watchlist` table a status column with a fixed set of queued, watched, and archived.

> What columns does the reading list table declare?

The assistant adds and updates rows against that declaration, and an agent workflow can be given tools scoped to one table. See [Tables and Agent Tools](/guides/tables).

## Memory for durable facts

Memory is semantic. It is searched by meaning, not just exact words.

Use memory for facts that should survive a single conversation:

> Remember that Acme is the pilot customer.

> Remember that weekly updates should be short and direct.

If memory becomes stale, open **Memory** and remove it.

## Practical pattern

1. Put source material in documents.
2. Put repeated records in tables, with a declared kind on every column.
3. Let workflows collect or update both.
4. Ask the assistant for a specific output.
5. Save durable facts to memory only when they should affect future work.