Fossil, the self-hosting distributed version control system created in 2007 to support SQLite development, has a new fork that turns it into a platform for AI agent workflows. The project, maintained on GitHub under BenSiv/fossil-scm, integrates chat backends, semantic search, and structured event tracking directly into the version control experience.
Built-in multi-provider agent support
The fork adds local agent integration through Fossil's existing settings system. Users configure a chat provider and model through standard Fossil commands, with no separate JSON configuration files required. Supported providers include Ollama, Claude, Codex, and Gemini, plus a custom option for anything else. A separate embedding backend can run on a different provider and model entirely.
Configuration can be local per repository, global per user, or versionable through .fossil-settings/ files that teams commit to their repositories. Fossil rejects obvious provider and model mismatches before launching the backend, using built-in metadata about each provider's capabilities. The /agent-config endpoint exposes the effective configuration as JSON, including capability flags for streaming support, model discovery, and provider locking.
For Ollama users, the default setup pairs the qwen3.5:0.8b chat model with mxbai-embed-large for embeddings. Codex users can wire embeddings through the OpenAI API. Claude and Gemini each have dedicated helper scripts with configurable prompt and model flags.
Semantic indexing and retrieval across the repository
Beyond chat, the fork includes commands for embedding repository content and building a semantic index. The fossil agent embed command processes files into vector representations, and the retrieve command searches that index by meaning rather than exact text matching. This makes it possible to ask questions like "find the code that handles authentication errors" and get results based on semantic similarity, not just keyword matching.
The embedding backend runs independently from the chat backend, so a repository can use a fast local model for embeddings while routing conversational queries to a more capable remote API. This separation matters for teams that want low-latency search without paying for premium inference on every index query.
Structured chat events and feedback loops
Chat sessions now persist with a structured event model. Each message row records a kind classification: prompt, reply, error, progress, or tool. The /agent-events endpoint exposes the ordered event stream for a session with optional incremental polling, and /agent-history returns the full conversation as JSON for browser-side rendering.
The /agentui interface stores the provider and model used for each session and restores that pair when reopening it. A status line above the chat log reflects the current backend state based on structured events. The session list includes a compact state label like running, ok, reply, or error beside each saved conversation.
A lightweight feedback mechanism in ai_chat_eval records whether a given reply was useful or not useful, giving the system a feedback signal that could eventually inform fine-tuning or routing decisions.
State export and provenance tracking
The fork adds fossil state export, which writes a deterministic file-tree projection of selected repository state to a directory. This makes it straightforward to capture a snapshot of the repository at a specific point for external tools to consume. Documentation for the exported domains lives in doc/STATE_PROJECTION.md.
Storage and provenance design for the AI layer is documented across three files: STORAGE_MODEL.md, PROVENANCE.md, and SCHEMA.md. A knowledge capture and curation policy describes how data flows through the system, organized into tiers defined in DATA_POOL.md and TIERS.md.
Test coverage built for agent workflows
The Tcl regression suite includes dedicated tests for the agent infrastructure. The core tests cover schema initialization, the agent note and agent embed commands, semantic indexing, retrieval, and eval reporting. A separate agent-config.test verifies settings migration from the old JSON configuration format. Agent regression tests are deterministic and do not require a live Ollama instance, network access, or any external API keys.
Some tests are intentionally feature-gated. They report as skipped rather than failed when prerequisites like JSON support, TH1 docs, or Tcllib packages are unavailable. A helper script checks whether the optional packages are installed and prints skip reasons in the test summary so developers can distinguish optional-environment skips from real regressions.
Why Fossil for agent workflows
The choice of Fossil as a base is not accidental. Fossil's self-hosting model, built-in wiki and ticket tracking, and single-file repository format make it easier to attach tooling without external dependencies. The settings system already supports versionable, per-repository configuration, which maps naturally to the problem of sharing AI provider settings across a team. And Fossil's TH1 scripting layer provides hooks for extending behavior without patching the core C code.
The fork is active, with documentation living under doc/ai/ and an implementation plan at doc/ai/IMPLEMENTATION_PLAN.md. Whether it gains traction beyond its current audience depends on whether teams find that integrating agents directly into version control solves a real workflow problem compared to running the same tools as standalone processes.