Remember

Bring data in: files, folders, buckets, links, records and connected accounts. Each is read once and kept.

• Files

  For bytes you hold — on disk, in your own bucket, or as a whole codebase. Two ways in: hand over signed URLs and the relay fetches them, or content-address locally and upload only the chunks the server is missing. Either way bytes never pass through the relay as request bodies, which is what makes a 2 GB file and a one-line edit to it cost about the same on the wire, and the file id stays stable across every later edit.

• Working directory

  A folder on your machine becomes a project that stays current. The loop is three calls: ask what the key opens and what is never read, compare against what the project already holds, then push only the files whose content actually moved. Content addressing is what makes the second run cost nothing — an unchanged file is never re-read and never re-sent. Credentials are refused by shape rather than by folder, so a key that lands in a synced directory is left on disk instead of being indexed.

• Links and conversations

  For content you can point at rather than upload: a URL the relay pulls and ingests into the project's corpus on a detached task.

• Schemas

  For data that has a shape before it arrives. A record schema declares the typed records a project holds beside its files; a type's schema declares the fields every entity of that type is read into.

• Channels

  For data that lives in an outside account: Gmail and Microsoft 365 mailboxes and calendars, LinkedIn, Google Drive and OneDrive / SharePoint, and the social surfaces. Connecting one is a consent step that happens in the provider's own browser flow; after it, a sync pulls the history in and synced content becomes ordinary corpus. Scanning, reading and managing a connected channel are catalog actions on the Actions lane (`channel_scan`, `channel_read`, `channel_manage`). What a channel sends lives in the Act leg's Outbound lane, where the approval gate is the story.