Skip to main content

File System Agent — Feature Specification

Branch: feature/chat-agent-file-navigation Date: 2026-03-09 Status: Draft (v2 — post architecture review) Owner: GAIA Team

1. Executive Summary

Enhance the GAIA Chat/RAG agent with a production-grade file system agent capable of browsing, searching, indexing, and deeply understanding a user’s PC file system. The goal is to provide Claude Code-caliber file navigation combined with persistent semantic indexing — giving the agent a “mental map” of the user’s machine that improves over time. This spec draws on analysis of 11 leading AI file system agents (Claude Code, Cursor, Copilot, Aider, Open Interpreter, Everything, MCP Filesystem, Anthropic Cowork, Windsurf, Cline, Devin) and maps their best capabilities onto GAIA’s existing infrastructure.

2. Problem Statement

The current GAIA chat agent has solid foundational file tools (search_file, search_directory, read_file, search_file_content) and a mature RAG pipeline (FAISS + embeddings). However, it lacks:

3. Competitive Analysis Summary

3.1 Approaches Compared

3.2 Key Insight: Hybrid Agentic + Indexed

The emerging consensus (2026) is that agentic search and RAG indexing serve different needs:
  • Agentic search (like Claude Code): Best for precision, freshness, ad-hoc exploration
  • Persistent indexing (like Cursor/OpenAI): Best for repeated access, semantic queries, large collections
Our approach: Combine both. Build a persistent file system index for structure/metadata, use agentic search for content, and layer semantic RAG for document Q&A.

4. Architecture

4.1 Three-Layer Design

4.2 Component Diagram

4.3 Existing Tool Disposition

Critical decision: The existing FileSearchToolsMixin tools are replaced, not duplicated.
The FileSearchToolsMixin import is removed from ChatAgent and replaced with FileSystemToolsMixin. The old mixin remains available for other agents that don’t need the full file system feature set.

5. Feature Specification

5.1 Layer 1: File System Navigator

These tools give the agent the ability to browse and understand the file system interactively.
IMPORTANT — Tool Decorator Pattern: GAIA’s @tool decorator (src/gaia/agents/base/tools.py) extracts descriptions from docstrings, not from a description= parameter. All tool code examples below use the correct pattern.
IMPORTANT — Path Validation: Every tool that accepts a path parameter MUST validate it through PathValidator.is_path_allowed() before any filesystem access. This is enforced at the mixin level via a _validate_path() helper.

5.1.1 browse_directory(path, show_hidden, sort_by, filter_type)

Browse a directory with rich metadata display.
Output format:

5.1.2 tree(path, max_depth, show_sizes, include_pattern, exclude_pattern)

Generate a tree visualization of directory structure.
Output format:

5.1.3 file_info(path)

Get detailed information about a file or directory.
Returns:
  • Full path (resolved via pathlib.Path)
  • File type (detected by mimetypes stdlib, with optional python-magic enhancement)
  • Size (human-readable)
  • Created / Modified dates
  • MIME type
  • Encoding detection (for text files, via charset-normalizer)
  • Line count (for text files)
  • Image dimensions (for images, via PIL if available)
  • PDF page count (for PDFs)
  • For directories: item count, total size, file type breakdown

5.1.4 read_file(path, lines, encoding) (ENHANCED existing tool)

Read file contents with smart formatting. Replaces the existing read_file() from FileSearchToolsMixin.

5.1.5 bookmark(action, path, label)

Manage file/directory bookmarks for quick access.

5.1.6 find_files(query, ...) (REPLACES search_file + search_directory)

Unified intelligent file search — the primary search entry point.
Search strategy (when search_type="auto"):
  1. Check persistent index first (instant, if available)
  2. If query looks like a glob pattern -> use glob matching
  3. If query looks like a file name -> use name search
  4. If query contains content-like terms -> use content search
  5. Apply metadata filters (size, date, type) on results
“Smart” scope logic:
  1. Current working directory (deepest)
  2. Home directory common locations
  3. All indexed directories
  4. Full drive search (only if scope="everywhere" explicitly)

5.2 Deferred Tools (Phase 4+)

The following tools are deferred to reduce initial tool count and LLM confusion. They will be added after core tools are stable:

5.3 Layer 3: Persistent Knowledge Base (File System Index)

A SQLite-backed persistent index that gives the agent a lasting understanding of the user’s file system.

5.3.1 Index Schema

Schema changes from v1 review:
  • Added schema_version table for migrations
  • Added PRAGMA journal_mode=WAL for concurrent read/write
  • Removed accessed_at column (privacy-invasive, often inaccurate)
  • Made content_hash DEFAULT NULL (opt-in, not computed during quick scan)
  • Removed last_accessed from bookmarks (unnecessary)
  • Added ON DELETE CASCADE to foreign keys
  • Added conditional index on content_hash (only indexes non-null values)

5.3.2 Schema Migration Strategy

5.3.3 FileSystemIndexService Class

5.3.4 File System Map (LLM Context)

A condensed representation of the file system designed to fit in LLM context. Inspired by Aider’s repo map concept.
Example context string:

5.3.5 Incremental Updates via Existing FileWatcher

Decision: Reuse the existing FileWatcher and FileChangeHandler from src/gaia/utils/file_watcher.py instead of creating a parallel watcher.

5.3.6 Initial Scan Strategy

The initial full scan needs to handle large file systems efficiently:

5.4 Enhanced Document Indexing (RAG Upgrades)

5.4.1 New File Type Support

Extend RAGSDK.index_document() to support:

5.4.2 Smarter Chunking

Current chunking is line/character-based. Upgrade to content-aware chunking:
Chunking parameters (following OpenAI defaults + our tuning):
  • Max chunk size: 800 tokens
  • Overlap: 200 tokens (25%)
  • Preserve semantic boundaries (paragraph, function, section)
  • Include parent context (file name, section header) in each chunk

5.4.3 Incremental Indexing with Metadata Change Detection


5.5 Layer 4: Data Scratchpad (SQLite Working Memory)

The critical missing piece for multi-document analysis. Gives the agent a structured working memory where it can accumulate, transform, and query extracted data using SQL.
Key insight: LLMs are bad at math but great at extracting structured data from unstructured text. SQLite is perfect at math but can’t read PDFs. Combining them creates an agent that can process 12 months of credit card statements, extract every transaction, and produce perfect aggregations — something neither can do alone.

5.5.1 Why a Scratchpad?

5.5.2 Architecture

The scratchpad lives in the same ~/.gaia/file_index.db database (separate tables from the file system index) or optionally in a per-session temp database.

5.5.3 Scratchpad Tools

5.5.4 Scratchpad Service

5.5.5 Multi-Document Processing Pipeline

The scratchpad enables a document processing pipeline pattern:
Max Steps Consideration: The current ChatAgent max_steps=10 may be insufficient for processing 12 documents. The config should be increased for data analysis tasks, or the pipeline should batch multiple document extractions per step. Recommended approach:
  • Batch extraction: process 3-4 documents per LLM call (reduce step count)
  • Or add a max_steps override for analysis mode: max_steps=30
  • Or implement a process_batch() tool that handles the loop internally

5.5.6 Security Constraints


6. Demo Scenarios

6.1 Demo: Personal Finance Analyzer

“Find my credit card statements, analyze a year of spending, and tell me where my money is going.”
Pipeline:
Why this is a wow demo:
  • Processes 12 real PDFs from the user’s actual PC
  • Extracts ~600 transactions without hitting context limits
  • SQL gives perfect math (no LLM hallucinated numbers)
  • Finds hidden subscriptions automatically
  • Actionable recommendations personalized to the user
What’s needed beyond the spec:
  • PDF table extraction (pdfplumber extract_tables()) — add to extractors
  • max_steps increase to 15-20 for analysis mode
  • Optionally: chart rendering in Electron UI (Recharts)

6.2 Demo: Tax Preparation Assistant

“Find all my tax-relevant documents and help me prepare for filing.”

6.3 Demo: Research Paper Literature Review

“I have a bunch of research papers on transformer architectures. Summarize them and find connections.”

6.4 Demo: Contract & Deadline Tracker

“Find all my contracts and leases, extract key dates and obligations.”

6.5 Demo: “Clean Up My PC”

“My PC is getting slow. Find what’s eating space and help me clean up.”

6.6 Demo: “Smart Project Onboarding”

“I just cloned a new project. Help me understand the codebase.”

6.7 What’s Needed for These Demos

6.8 Priority Demo Implementation Order

6.9 Agent Dashboard UI

The Electron/Web UI must provide full visibility into the agent’s state, the file system index, and the scratchpad database. This transforms the chat from a black box into a transparent, inspectable system.

6.9.1 Dashboard Layout

6.9.2 Dashboard Tab (Agent State Overview)

A dedicated Dashboard tab showing the overall agent configuration and state:

6.9.3 Scratchpad Tab (Data Explorer)

A dedicated Scratchpad tab with a full data explorer for inspecting tables:
Key features:
  • Table list — shows all scratchpad tables with row counts
  • Data grid — paginated table view with sortable columns
  • SQL query bar — run ad-hoc SELECT queries against scratchpad
  • Quick stats — auto-computed SUM/AVG/COUNT for numeric columns
  • Export — download table data as CSV or JSON
  • Schema view — show column names, types, and sample data

6.9.4 File Index Tab

A dedicated File Index tab for browsing the indexed file system:

6.9.5 Inline Scratchpad Preview in Chat

When the agent uses scratchpad tools during a conversation, the chat area shows inline previews of the data — not just text descriptions:
Implementation approach:
  1. Agent tool results include a structured marker (e.g., [TABLE:transactions:5 rows])
  2. The SSE handler passes structured data alongside the text response
  3. MessageBubble.tsx detects the marker and renders an interactive DataTable component
  4. The DataTable component uses the same rendering as the Scratchpad tab

6.9.6 Frontend Dependencies for Dashboard

These are added to the Electron app’s package.json, not the Python backend.

6.9.7 API Endpoints for Dashboard

The dashboard needs dedicated API endpoints (added to src/gaia/api/):

7. Tool Registration Plan

7.1 New Mixin: FileSystemToolsMixin

Location: src/gaia/agents/tools/filesystem_tools.py (shared tools directory) This mixin provides all Layer 1 and Layer 2 tools. Any agent can include it.

7.2 New Mixin: ScratchpadToolsMixin

Location: src/gaia/agents/tools/scratchpad_tools.py (shared tools directory)

7.3 ChatAgent Integration

MRO Note: Neither FileSystemToolsMixin nor ScratchpadToolsMixin define __init__. They are initialized via register_*_tools() called from the agent’s _register_tools() method, following the same pattern as register_file_search_tools().

7.4 New Backend Services

Location: src/gaia/filesystem/ and src/gaia/scratchpad/
Removed from original spec:
  • watcher.py — reuse existing FileWatcher from gaia.utils.file_watcher
  • extractors/media.py — deferred (audio/video metadata is niche)
  • extractors/archive.py — deferred (ZIP listing is niche)
  • chunkers/code_chunker.py — replaced with python_chunker.py (no tree-sitter)

8. Configuration

8.1 ChatAgentConfig Additions

8.2 Feature Flags

The file system features can be fully disabled:
  • --no-filesystem-index CLI flag disables the index entirely
  • Without the index, tools still work but use direct filesystem access (slower)
  • This is useful for privacy-sensitive environments

9. CLI Commands

9.1 gaia fs Subcommand

9.2 CLI Implementation

Add to src/gaia/cli.py following existing patterns (argparse subcommands):

10. Security & Privacy

10.1 Access Control

10.2 Sensitive File Handling

10.3 Default Exclusions (Platform-Conditional)

10.4 Index Security

The SQLite database at ~/.gaia/file_index.db stores file paths, sizes, and modification dates. While no file content is stored, this metadata reveals the user’s file system structure. Mitigations:
  • Set restrictive file permissions (0600) on database file
  • Document the risk in user-facing documentation
  • Provide gaia fs reset command to delete the index
  • Future consideration: SQLCipher encryption (deferred, adds native dependency)

11. Performance Targets

Memory targets:

12. Implementation Phases

Phase 1: Core Navigator (Week 1-2)

Goal: 6 core tools operational, no index dependency.
  • Create src/gaia/filesystem/ package structure
  • Implement FileSystemToolsMixin with register_filesystem_tools():
    • browse_directory() — directory listing with metadata
    • tree() — tree visualization
    • file_info() — detailed file/directory info
    • find_files() — unified search (glob-based, no index yet)
    • read_file() — enhanced file reading (text, code, CSV, JSON)
    • bookmark() — in-memory bookmarks (persisted in Phase 2)
  • Add _validate_path() with PathValidator integration
  • Remove FileSearchToolsMixin from ChatAgent, replace with FileSystemToolsMixin
  • Keep FileSearchToolsMixin available for other agents
  • Add ChatAgentConfig filesystem fields
  • Add unit tests for all 6 tools (mock filesystem)
  • Add integration tests with real filesystem
  • Manual testing of navigation flow

Phase 2: Persistent Index + Data Scratchpad (Week 2-3)

Goal: SQLite-backed file system memory AND structured data analysis. File System Index:
  • Implement FileSystemIndexService inheriting from DatabaseMixin
  • Implement SQLite schema with WAL mode and FTS5
  • Implement schema migration system (schema_version table)
  • Implement scan_directory() — Phase 1 quick scan (metadata only)
  • Implement FTS5 name/path search via query_files()
  • Connect find_files() to index for fast lookup (< 100ms)
  • Implement bookmark() persistence via index service
  • Implement auto_categorize() by extension
  • Add integrity check on startup with auto-rebuild
  • Add gaia fs CLI commands: scan, status, search, bookmarks, reset
  • Unit + integration tests for index service
  • Test concurrent read/write (WAL mode)
Data Scratchpad:
  • Create src/gaia/scratchpad/ package
  • Implement ScratchpadService inheriting from DatabaseMixin
  • Implement ScratchpadToolsMixin with register_scratchpad_tools():
    • create_table() — create analysis workspace tables
    • insert_data() — bulk insert extracted data (JSON array input)
    • query_data() — run SELECT queries for analysis
    • list_tables() — show scratchpad contents
    • drop_table() — cleanup after analysis
  • Add table name sanitization and SQL injection prevention
  • Add size limits (100 tables, 1M rows/table, 100MB total)
  • Register ScratchpadToolsMixin in ChatAgent
  • Add gaia fs scratchpad clear CLI command
  • Unit tests for all 5 scratchpad tools
  • Integration test: multi-document extraction pipeline
  • Increase max_steps default to 20 for analysis workflows
Demo validation:
  • End-to-end test: Personal Finance Analyzer demo with sample PDFs
  • End-to-end test: Tax Preparation demo with sample documents

Phase 3: Knowledge Base (Week 3-4)

Goal: Smart context, background maintenance, and additional tools.
  • Implement FileSystemMap dataclass with to_context_string()
  • Implement on-demand map injection (via tool, not always-on)
  • Integrate FileWatcher from gaia.utils.file_watcher for real-time updates
  • Limit watching to bookmarked/scanned directories only
  • Implement disk_usage() tool (uses index data when available)
  • Add first-run experience flow (quick scan on first tool use)
  • Implement cleanup_stale() for removing deleted file entries
  • Implement periodic re-scan (configurable interval, default: weekly)
  • Performance benchmarking against targets
  • Add gaia fs cleanup and gaia fs tree CLI commands

Phase 4: Enhanced Extraction (Week 4-5)

Goal: Rich document support, smart chunking, and remaining tools.
  • Implement content extractors:
    • Office formats (DOCX, PPTX, XLSX) — optional dependencies
    • Enhanced PDF (wrapping existing rag/pdf_utils)
    • Image metadata (PIL/Pillow if available)
    • HTML content extraction (beautifulsoup4)
  • Implement smart chunkers:
    • Markdown chunker (header/section boundaries)
    • Prose chunker (paragraph boundaries)
    • Python chunker (stdlib ast module)
    • Table chunker (header-preserving)
  • Integrate extractors with RAG pipeline
  • Implement incremental indexing with metadata change detection
  • Add compare_files() and find_duplicates() tools
  • Opt-in content hashing for duplicate detection
  • End-to-end testing with diverse file types

Phase 5: Polish & Testing (Week 5-6)

Goal: Production-ready quality.
  • Performance benchmarking against all targets (time + memory)
  • Large file system stress testing (100K+ files)
  • Windows/Linux/macOS compatibility testing
  • Security audit (path traversal, symlink attacks, sensitive file handling)
  • Documentation: user guide (docs/guides/filesystem.mdx)
  • Documentation: SDK reference (docs/sdk/sdks/filesystem.mdx)
  • Update docs/docs.json navigation
  • Update docs/reference/cli.mdx with gaia fs commands
  • Error handling and recovery for corrupted index
  • MCP exposure consideration (expose tools via MCP for external agents)

13. Dependencies

New Dependencies

Removed from original spec:
  • python-magic — Replaced by mimetypes (stdlib). python-magic requires libmagic DLL on Windows which is unreliable. Extension-based detection via mimetypes is the DEFAULT.
  • chardet — Replaced by charset-normalizer (MIT license, faster, used by requests)

Existing Dependencies (already in GAIA)

Extras Group


14. Testing Strategy

14.1 Test Matrix

14.2 Test File Locations

14.3 Performance Benchmarks


15. Success Metrics


16. Decisions Log

Decisions made during architecture review (2026-03-09):

17. References


Appendix A: Deferred Feature Details

A.1 disk_usage(path, depth, top_n) — Phase 3

A.2 compare_files(path1, path2) — Phase 4

A.3 find_duplicates(directory, method) — Phase 4

A.4 MCP Exposure — Phase 5

Consider exposing file system tools via MCP for external agent access:
  • Read-only tools (browse_directory, tree, file_info, find_files, read_file) can be exposed
  • Write tools and bookmark management should require explicit opt-in
  • Use MCP tool annotations to mark read-only vs. write operations