Local-first browser-and-file agent for repo triage and research runs

What they did

They installed Atomic Agent, a local-first agent that keeps its control loop and state on the machine, and pointed it at a llama.cpp backend so small quantized models could handle long multi-step sessions without blowing up memory. Using the agent's browser control, file editing, approved shell commands, and cross-session memory, they set it up to do a recurring research-and-triage pass on a repo: open docs and issue pages in the browser, read and summarize relevant files, draft notes into a scratch directory, and remember prior context so follow-up runs did not restart from zero. They also experimented with Fusion mode, where one model plans and a pool of workers executes, to split browsing from editing. External tools were wired in over MCP, and the whole thing ran from the terminal with state persisted on disk.

How it went

The setup worked as a local-first workflow: browsing, file edits, and approved commands ran on the machine, and session memory carried context between runs. Fusion mode helped separate planning from execution. Quality depended heavily on the local model chosen; small quantized models handled short steps well but needed tighter prompts for longer chains. No cloud keys were required for the local path.

Worth knowing

Requires Node >= 25.7 and a working llama.cpp build; TurboQuant is the project's own fork, so upstream llama.cpp behavior may differ. Local model quality varies, and long sessions can still degrade. Shell commands need explicit approval, and browser automation can be brittle on dynamic pages. MCP tool setup is not fully spelled out in the README excerpt, and Fusion mode adds configuration overhead.

Wiring

Install Atomic Agent via the quick-install path (Node >= 25.7). Point the model config at a local llama.cpp server or the bundled TurboQuant build, choosing a quantized model that fits available RAM. Enable the browser, file, and shell tools in the agent config, and require approval for shell commands. Add MCP servers for any external tools. Optionally enable Fusion mode with a planner model and a worker pool. State persists on disk, so subsequent runs resume context; the agent can also be embedded over HTTP or as a Tauri sidecar if you want it inside another app.

Try it yourself

Set up Atomic Agent in this repo with a local llama.cpp backend. Configure a small quantized model, enable browser control, file editing, and approved shell commands, and turn on cross-session memory. Then run a triage pass: browse the project's docs and open issues, summarize the top themes, and write a dated notes file under .agent-notes/ with findings and follow-ups. Keep all state local and show me the commands you plan to run before executing them.