The corpus an internal assistant already has

Technology

Notion is where a lot of companies keep the writing that never becomes a product: specs, runbooks, decisions, onboarding. That makes it the first place an internal assistant gets pointed at, and the API decides whether that works, because it returns blocks rather than documents.

We run our own projects in it, so we know both what a workspace holds and what it costs to get out. The writing is the easy part. Retrieval, permissions, and when the sync runs are the actual build.

Monogram logo

Knowledge

What a workspace is worth to a model

  1. A page is a tree of blocks, not a file

    Retrieving content means walking the block children endpoint, paginating, and recursing wherever a block has children, before you hold anything worth chunking. The API allows roughly three requests a second on average, so pulling a workspace into a retrieval index is a background job, never something you do inside a request.

  2. The token sees the workspace, not the reader

    An integration is granted access page by page and queries as itself, so every lookup has the same reach no matter who asked. Point an assistant at one token and you have flattened the permission model the workspace was relying on. Carrying per user access through is the design problem, and it comes before the model.

  3. It is our workspace, not a deliverable

    Specs, decision logs, the running note on why an approach changed midstream: that is what our own Notion holds, and none of it ships as code or a design file. Notion has not appeared in a client build we have shipped, and we are not going to dress it up as more.