Skip to main content
Rowboat’s knowledge system transforms raw content (emails, meetings, notes) into a structured knowledge graph using AI-powered entity extraction and note creation.

System Overview

Architecture Components

1. Content Source Syncing

Background services continuously fetch content from external sources:
Purpose: Fetch and index emails from Gmail APIProcess:
  1. OAuth 2.0 authentication with Google
  2. Incremental sync using history API
  3. Store raw emails as markdown in ~/.rowboat/gmail_sync/
  4. Track sync state to avoid reprocessing
File Format:
Location: core/src/knowledge/sync_gmail.ts
Purpose: Fetch calendar events from Google Calendar APIProcess:
  1. OAuth 2.0 authentication with Google
  2. Fetch events from primary calendar
  3. Store as markdown in ~/.rowboat/calendar_sync/
  4. Track processed events by ID
File Format:
Location: core/src/knowledge/sync_calendar.ts
Purpose: Fetch meeting transcripts from Fireflies.aiProcess:
  1. OAuth 2.0 authentication with Fireflies
  2. GraphQL API to fetch transcripts
  3. Store as markdown in ~/.rowboat/fireflies_transcripts/
  4. Include speaker labels and timestamps
File Format:
Location: core/src/knowledge/sync_fireflies.ts
Purpose: User-created voice notes transcribed with WhisperProcess:
  1. User records audio in UI
  2. Audio transcribed locally using Whisper
  3. Stored directly in ~/.rowboat/knowledge/Voice Memos/<date>/
  4. Ready for entity extraction
File Format:
Location: Created by UI, processed by graph builder

2. Graph Builder - Entity Extraction Pipeline

The Graph Builder (build_graph.ts) is the core processing engine:
The graph builder runs every 30 seconds, checking all source folders for new/changed content. It uses mtime + content hash to detect changes efficiently.

Processing Pipeline

Step-by-Step Flow:
  1. Change Detection
    • Scan source folders: gmail_sync/, fireflies_transcripts/, granola_notes/, knowledge/Voice Memos/
    • Load state from knowledge_graph_state.json
    • Check mtime + hash to identify changed files
  2. Batch Processing
    • Group files into batches of 10
    • Build knowledge index for each batch
    • Create agent run for entity extraction
  3. Agent Execution
    • Send batch + index to note_creation agent
    • Agent extracts entities (people, orgs, projects, topics)
    • Agent creates/updates notes in ~/.rowboat/knowledge/
  4. State Management
    • Mark processed files in state
    • Commit changes to version history
    • Save state after each batch

State Tracking

Purpose: Track which files have been processed to avoid reprocessingState Schema:
Change Detection Logic:
Location: core/src/knowledge/graph_state.ts

Batch Processing Logic

3. Knowledge Index - Entity Resolution

The Knowledge Index (knowledge_index.ts) provides entity resolution:
Agents must NOT use grep/search to find existing notes. The index is the source of truth for entity resolution.

Index Structure

Index Building

Process:
  1. Recursively scan ~/.rowboat/knowledge/
  2. Parse each markdown file
  3. Extract metadata based on folder:
    • People/ → Parse as person note
    • Organizations/ → Parse as org note
    • Projects/ → Parse as project note
    • Topics/ → Parse as topic note
    • Other folders → Parse as generic note
Metadata Extraction:

Index Formatting for Agents

Prompt Format:
Usage in Agent Prompt:

4. Note Creation - AI Agent Workflow

The note creation agent receives batches of content and:
  1. Entity Extraction
    • Identify people, organizations, projects, topics
    • Resolve entities using the index
    • Merge information if entity already exists
  2. Note Creation/Updates
    • Use workspace-writeFile for new notes
    • Use workspace-edit for existing notes
    • Follow folder structure: knowledge/People/, knowledge/Organizations/, etc.
  3. Note Templates
    • People: Name, Email, Organization, Role, Aliases
    • Organizations: Name, Domain, Aliases
    • Projects: Name, Status, Aliases
    • Topics: Name, Keywords, Aliases
Example Person Note:

Data Flow Diagram

File System Layout

Performance Optimizations

  • State tracking: Only process new/changed files
  • Hash-based detection: mtime + SHA-256 hash avoids false positives
  • Batch processing: Process 10 files per agent run (faster than 25)
  • Partial saves: State saved after each batch (no full reprocessing on error)
  • Fresh index per batch: Includes notes from previous batches
  • Fast scanning: Recursive directory traversal
  • Metadata extraction: Parse only frontmatter fields, not full content
  • Async processing: All services run independently
  • 30-second polling: Balance between responsiveness and CPU usage
  • Error recovery: Failed batches don’t block subsequent batches
  • Service logging: Structured logs for debugging

Key Design Decisions

Why batch processing? Processing files in batches (10 at a time) allows the agent to see patterns across multiple sources and merge information about the same entity.
Why index-based resolution? Providing a pre-built index prevents agents from making expensive grep/search calls and ensures consistent entity resolution.
Why mtime + hash? Checking mtime first is fast (no file read). Hash verification only happens when mtime changes, catching false positives (e.g., touch commands).

Code References

  • Graph Builder: core/src/knowledge/build_graph.ts
  • Knowledge Index: core/src/knowledge/knowledge_index.ts
  • State Management: core/src/knowledge/graph_state.ts
  • Gmail Sync: core/src/knowledge/sync_gmail.ts
  • Calendar Sync: core/src/knowledge/sync_calendar.ts
  • Fireflies Sync: core/src/knowledge/sync_fireflies.ts