Row-Bot: a local-first AI assistant that keeps memory, tools and models on your machine
Row-Bot - Personal AI Sovereignty. A local-first AI assistant with integrated tools, a personal knowledge graph, voice, vision, shell, browser automation, scheduled tasks, health tracking, and messaging channels. Run locally via Ollama or add opt-in cloud models. Your data stays on your machine.
At a glance
- What is it?
- Row-Bot (formerly Thoth) is an Apache-2.0 Python desktop assistant built around a LangGraph ReAct agent, durable memory, agent orchestration and opt-in cloud models. The interesting part is the orchestration and context budget design; the trade-off is a heavyweight stack and a README that documents far less about uninstall and rollback than it does about features.
- Who is it for?
- Row-Bot suits engineers and small teams who want a desktop assistant whose durable data stays local and who are willing to run a Python 3.12 to 3.13 stack with Ollama or their own endpoint. It is the wrong pick if you need a hosted multi-tenant service, if you cannot accept the Cua Driver telemetry that Computer Use requires, or if you want a tool that uninstalls as cleanly as it installs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Row-Bot is for, and who should care
Row-Bot is a desktop AI assistant that runs the model, the memory and the tools on your own machine by default. The name is stated as an operating model: Reason through messy context, Orchestrate tools and model providers, Work inside the files, repos, workflows and channels you choose. That framing tells you where the project draws its boundary. It is not a chat wrapper around a single API. It is an agent runtime with a user interface, a knowledge graph, voice, vision, shell access, browser automation, scheduled tasks, health tracking and messaging channels, all wired to a model you select.
The intended user is someone who already runs local models and wants the surrounding scaffolding: a memory that survives restarts, a way to point different tasks at different providers, and a shell and browser the agent can drive. The README states that Row-Bot has no account system, no Row-Bot-hosted inference server and no first-party telemetry pipeline. Provider keys, OAuth tokens and subscription tokens are stored in the OS credential store when one is available, and official Docker deployments use a separate persistent encryption-key volume with encrypted credential records instead. If data locality is your reason for looking at this project, those are the sentences that matter, and they are also the ones worth checking against the code rather than the tagline.
The scope is broad enough that it is worth asking what you actually want from it. A user who only wants a chat window with a local model will find most of the surface area unused. A user who wants an assistant that can hold a goal across a restart, delegate research to a child agent, and write into a specific folder is closer to the target.
The ReAct agent, Goal Mode and parent-led child orchestration
The core is described as a LangGraph ReAct agent. Around it sit Goal Mode, Agent Profiles and automatic parent-led child-agent orchestration. The mechanism, as the README describes it, is that the original parent keeps responsibility for joining required results and answering, while scoped child agents handle research, review, implementation or follow-up work. Durable checkpoints preserve approvals, steering, retries, stops and recovery. That is the part of the design that separates Row-Bot from a single-loop agent: the parent is not replaced by its children, and the run state is written down rather than held in memory.
Bounding is handled explicitly. The README mentions checkpoint-safe work budgets and application-wide delegation limits, plus configurable nesting, concurrency and active-time limits and repeated-action protection. Parallel writers can be assigned to distinct existing local folders as separate Developer workspaces, and folder-scoped locks let those children work concurrently while preserving one writer at a time inside any shared folder. This is a concrete answer to a real problem: two agents editing the same directory is a data-loss bug, and the project chooses folder-level locking rather than a global mutex, which keeps unrelated work parallel.
Recovery after a restart is spelled out. If a restart interrupts delegation or owned shell work, Row-Bot closes unanswered tool calls without replaying them and resumes the saved parent when its required child results are ready. Not replaying is the safer default for shell commands, since a replayed write is worse than a dropped one, but it also means a partially completed action may need manual cleanup. The README does not describe a general rollback for those cases, only orphan-only checkpoint repair.
Context metering, compaction and the fixed prompt envelope
Long conversations get a specific treatment. The desktop composer meters the complete next model input, and Row-Bot can compact complete older turns into durable untrusted reference context while preserving the newest turn and atomic tool-call and result groups. Two details stand out. First, compaction operates on whole turns and on tool-call/result pairs together, so the agent does not end up with a result whose call was dropped. Second, the rebuilt prompt is validated before saving, and the run fails with an exact capacity message when the fixed prompt and tool schemas cannot fit the selected window.
That failure mode is worth taking seriously. A fixed envelope means the system prompt and the tool schemas are not negotiable, so a model with a small context window can be rejected outright before any conversation happens. The README presents this as a preflight rather than a surprise mid-run, which is the right place for it, but it also means switching to a smaller local model is not always possible for a given tool configuration. If you plan to run a modest Ollama model, check the capacity message behaviour early rather than after building a workflow.
Capability loading follows the same budget logic. Recommended Auto capability loading keeps permitted core tools directly available and searches enabled MCP, plugin, Custom Tool and channel capabilities only when a request needs them. That reduces the number of tool schemas competing for the window, at the cost of a discovery step whose results you cannot fully predict from the configuration alone.
Installing Row-Bot and running a first goal
The README points to GitHub Releases for the latest installer. Windows and macOS get one-click installers, and Linux has a one-line user installer. The repository also ships Start Row-Bot.command and launcher.py, and pyproject.toml requires Python >=3.12,<3.14, so a source install needs a 3.12 or 3.13 interpreter. The README does not document uninstall steps or a rollback path for an upgrade, which is a real gap if you plan to try it on a work machine.
For a source checkout, the project is a Python package named row-bot, and pyproject.toml declares setuptools as the build backend. The repository's own requirements.txt carries a header comment giving the regeneration command for the lock file:
python scripts/export_locked_requirements.pyThat script is the supported way to refresh dependencies, and requirements.txt states it is generated from pyproject.toml and uv.lock and should not be edited by hand. For running the application from a checkout, the repository root contains launcher.py and Start Row-Bot.command, which are the entry files the project ships rather than a documented console script.
What you should see is the desktop interface opening. Before that is useful, a local model has to be reachable through Ollama, which the README lists as the local path; it does not print a specific model pull command, so use a model you have already made available through Ollama on the same machine.
The first real use worth trying is a goal that touches a folder, because that exercises the parts that distinguish Row-Bot: profile selection, tool permissions and the folder-scoped writer lock. Point the task at an existing directory rather than creating one, since the README describes parallel writers being assigned to distinct existing local folders. If the run stops with a capacity message, that is the fixed-envelope preflight rejecting the model and tool combination, not a crash.
Where Row-Bot is the wrong tool
The clearest limitation is the optional Computer Use beta. The README states that it depends on Cua Driver, whose separately disclosed upstream telemetry must be accepted before Row-Bot installs or invokes it. A project whose pitch is local-first data ownership is asking you to accept third-party telemetry for one feature. You can decline and keep the rest, but if desktop control is why you came, the privacy story is no longer uniform.
The second limitation is operational. This is a Python 3.12 to 3.13 application with a large dependency set, including LangChain 1.x, LangGraph 1.x, NiceGUI, FastAPI, tiktoken, keyring and platform-specific packages such as pyobjc on macOS. The lock file is generated from pyproject.toml and uv.lock through scripts/export_locked_requirements.py, and requirements.txt warns against editing it by hand. That is a sane policy, but it also means a source install is a real environment-management job, not a single pip command you can forget about.
The third is fit. Row-Bot is a desktop assistant. It is not a server framework for multiple users, it has no account system, and it has no hosted inference. If you need a shared service with tenancy, audit logs and an admin console, this is the wrong shape. Similarly, if you want a small library you can embed in your own application, the React frontend, the NiceGUI layer and the installer scripts are weight you would be carrying for nothing.
How Row-Bot compares with a hand-rolled LangGraph agent
The honest alternative for many readers is assembling the same pieces yourself: a LangGraph ReAct agent, an Ollama endpoint, a SQLite checkpointer through langgraph-checkpoint-sqlite, and a separate chat UI. Row-Bot is essentially that assembly with decisions already made. The difference in approach is that Row-Bot treats parent-child delegation, folder-scoped writer locks, checkpoint-safe budgets and context compaction as first-class features with configuration and recovery behaviour, whereas a hand-rolled LangGraph agent leaves all of that to you. If your agent runs are short and single-threaded, the hand-rolled version is less code and fewer dependencies.
A second comparison is a local chat front end. The distinction is that a chat front end gives you conversation and model selection, while Row-Bot's README is mostly about tool execution, memory and orchestration. If your need is conversational, the front end is the smaller tool. If your need is an agent that writes files, browses and runs scheduled work, the orchestration layer is the point, and it is also the part you would otherwise have to build and test yourself.
The provider story is the third axis. Row-Bot supports local models through Ollama; provider keys for OpenAI, Anthropic, Google AI, xAI, MiniMax, OpenRouter, Atlas Cloud, Requesty, Ollama Cloud, OpenCode Zen and OpenCode Go; subscription or OAuth sign-in for ChatGPT / Codex, Claude Subscription and xAI Grok; and custom OpenAI-compatible endpoints such as oMLX, LM Studio, vLLM, llama.cpp, LocalAI, LiteLLM and SGLang. That breadth is wider than most single-provider tools, and it is also why provider identity, capability labels, reasoning choices, context limits and chat-only fallbacks are kept explicit: mixing local, hosted, subscription and self-hosted models in one interface creates exactly those mismatches.
Maintenance, licence and what an upgrade costs
The repository is not archived, and the last push was on 2026-09-10. Recent releases include v4.9.1 on 2026-08-28, v4.9.0 the same day, and v4.8.0 on 2026-08-21, so the release cadence around that period is frequent. Frequent releases are good for fixes and bad for stability expectations: v4.9.1 is titled Optional Computer Use Verification & Calculator Reliability, and v4.9.0 is titled Native Computer Use, Desktop Buddy & Safe Conversation Cleanup. Two releases in one day suggests the second was a correction to the first.
The licence is Apache-2.0, with a NOTICE file in the repository root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, but it also requires that you preserve the licence and NOTICE when you redistribute. If you fork Row-Bot into an internal product, that obligation travels with the code. This is a description of the licence text, not legal advice; read LICENSE and NOTICE yourself.
Upgrade cost is the practical question. Because durable app data stays local and checkpoints are written to SQLite, an upgrade has state to migrate, and the README does not document a migration or rollback procedure. The safest posture is to treat the data directory as something you back up before pulling a new release, and to check RELEASE_NOTES.md for the version you are moving to. The README does not state whether downgrades are supported.
Editorial conclusion
Row-Bot suits engineers and small teams who want a desktop assistant whose durable data stays local and who are willing to run a Python 3.12 to 3.13 stack with Ollama or their own endpoint. It is the wrong pick if you need a hosted multi-tenant service, if you cannot accept the Cua Driver telemetry that Computer Use requires, or if you want a tool that uninstalls as cleanly as it installs. Verify first that your Python version is inside the 3.12 to 3.13 range in pyproject.toml, that your chosen model fits the context window the composer meters, and that you are comfortable with what Start Row-Bot.command and the Linux one-line installer actually place on disk.
Frequently asked questions
Does Row-Bot send my data to a cloud service?
The README states that Row-Bot has no account system, no Row-Bot-hosted inference server and no first-party telemetry pipeline, and that durable app data stays local by default. Provider calls go to the provider or endpoint you choose. The optional Computer Use beta is an exception in spirit: it depends on Cua Driver, whose separately disclosed upstream telemetry must be accepted before Row-Bot installs or invokes it.
Which Python version does Row-Bot need?
pyproject.toml sets requires-python to >=3.12,<3.14, so a source install needs Python 3.12 or 3.13. The README points Windows and macOS users at one-click installers and Linux users at a one-line user installer, which avoid managing the interpreter yourself.
Can Row-Bot run entirely on a local model?
Yes. The README lists local models through Ollama as one of the supported paths, alongside provider keys, subscription or OAuth sign-in, and custom OpenAI-compatible endpoints. The constraint to watch is context size: the composer meters the complete next model input and Row-Bot fails with an exact capacity message when the fixed prompt and tool schemas cannot fit the selected window.
What happens to a running task if I restart Row-Bot?
The README states that if a restart interrupts delegation or owned shell work, Row-Bot closes unanswered tool calls without replaying them and resumes the saved parent when its required child results are ready. Durable checkpoints preserve approvals, steering, retries, stops and recovery. The README does not document a general rollback for partially completed actions.
Community notes