BUILD NOTES / 002
Why I built Fathom
I wanted an AI agent I could run, understand, and shape around the way I work.
That meant having a choice of models, a way to work from the terminal or browser, and tools that could do useful work. It also meant thinking about the less exciting parts: permissions, credentials, persistent state, and what happens when something fails.
That combination became Fathom.
My background is in networks, security, and operating systems and platforms. When I look at an agent that can edit files or execute commands, I start asking familiar questions. What can it access? Where are the secrets stored? What survives a restart? Can I inspect what happened afterward?
Those questions influence how I’m building it.
Fathom is a self-hosted agent written in Go. It supports terminal and browser chat, local tools, scheduled tasks, and connections to local or hosted models. The idea is to have a working environment I can adapt as the models and my needs change.
Self-hosting gives me control over the runtime, but the model choice still matters. Using a hosted provider means sending requests to that provider. Running a local model offers a different arrangement. I wanted that choice to be explicit.
I also wanted useful work to extend beyond an open chat window. Fathom can store scheduled jobs and routines, with the gateway running to execute them. Threads and other state persist locally, so restarting the process doesn’t have to mean losing the conversation.
Recall fits into this as an optional memory layer. It handles shared context across coding agents; Fathom provides a place to interact with models and tools. They can work together, but basic Fathom chat doesn’t require Recall.
Another area I’m exploring is how agents collaborate on a task. Fathom has a board where a builder can work on a change, a reviewer can inspect it, and a person approves completion. File diffs, recorded test results, and activity history give that handoff something concrete to review.
That interests me from an engineering leadership perspective. If several agents contribute to a piece of work, I want to understand their responsibilities, inspect the result, and retain a clear point of human judgment.
The security work follows the same thinking. Fathom includes tool policies, encrypted secret storage, and persistent audit events. Different execution paths have different boundaries, though, and those distinctions matter. Self-hosting alone doesn’t make an agent safe, and a list of security features doesn’t settle every question about how it should be deployed.
This is still an evolving project. Team and enterprise features are experimental, and the README documents current limitations alongside what works. I’d rather make those boundaries visible while improving the implementation.
All Fathom modes are available under the MIT license. There’s no separate paid edition, although model providers and infrastructure can carry their own costs.
Part of building Fathom is practical: I want this tool to exist in a form I can use and control. Part of it is curiosity about how far I can take it and what I’ll learn by building the system around the model.