Technical Reference

How ThinkForge actually works. Architecture, data flow, execution models, and system internals.

This section is for users who want to understand the system, not just use it. If you are evaluating ThinkForge and want to know what is real versus what is marketing, start here.

Architecture

ThinkForge is a desktop application built with a modular architecture:

  • Core application (Fire) — The main desktop environment with project management, document editing, and tab-based workspace
  • Power Strip — A separate floating window that communicates with Fire but operates independently
  • Project Navigator — A floating project panel that provides workspace access without the full Fire window
  • Chrome Extension — A browser extension that communicates with Fire through a local bridge
  • VS Code Extension — A VS Code extension that connects to Fire via TCP/JSON-RPC

Local storage

All persistent data uses local file storage with standard formats:

  • Documents: Markdown files with YAML frontmatter
  • Semantic memory: SQLite database per workspace
  • Agent definitions: JSON files
  • Configuration: JSON settings files
  • Dashboards: SQLite-backed persistence

No proprietary binary formats. Everything is inspectable.

Browser-to-desktop bridge

The Chrome extension communicates with the desktop app through two protocols:

  • Local HTTP endpoint — An import endpoint running on localhost for extension-to-desktop content transfer
  • Chrome Native Messaging — The standard Chrome Native Messaging API for direct binary communication

Both protocols are local-only. No data leaves your machine through the bridge. The dual protocol approach provides redundancy — if one method fails, the other can handle the communication.

Agent execution model

ThinkForge agents are structured execution units, not conversational chatbots:

  • Each agent is defined as a JSON file with inputs, outputs, permissions, and execution steps
  • Agents are registered in a skill/function catalog
  • Execution is routed through the Agent Context Orchestrator, which handles prompt resolution, context injection, and AI provider communication
  • Agent outputs are written to configured output folders as files
  • All execution is logged for inspection and debugging

MCP integration

ThinkForge includes a local MCP (Model Context Protocol) server that exposes workspace tools to AI development environments like Cursor and Windsurf:

  • JSON-RPC style tool communication
  • Phase-based development commands
  • Workspace-aware context routing

Permissions model

Agent permissions are explicit:

  • File read/write access is scoped to specified folders
  • AI provider access requires user-configured API keys
  • Browser capture requires active user action (no passive scraping)
  • No agent can access files outside its configured scope
Inspectable by design. Agent definitions are JSON files you can read. Execution logs are files you can review. Memory databases are SQLite you can query. Nothing is hidden behind proprietary layers.

Related