AGNT: a local-first agent OS that stores its state in SQLite on your own machine
The local-first operating system for building, running, and improving AI agents, workflows, and autonomous goals.
At a glance
- What is it?
- AGNT bundles agents, workflows, goals, plugins and evals into an Electron desktop app with an Express backend on port 3333. The design keeps execution data local, which is the main reason to pick it and also the main thing to check before you commit.
- Who is it for?
- Adopt AGNT if you want agent execution data to stay on a machine you control and you are willing to treat a 0.6.x release as something you read the source of. Do not adopt it if you need a hosted control plane with an SLA, or if a permissively licensed dependency chain matters to your legal review.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, 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
The problem AGNT targets: agent work that disappears after the run
Most agent tooling is optimised for a single session. You give a model a prompt, it calls a few tools, the transcript scrolls away, and the next run starts from nothing. AGNT's premise is that the interesting part of agent work is the part that survives: the trace, the memory entry, the workflow definition, the evaluation result. The README frames the product as making AI work "durable, inspectable, repeatable, and improvable", and the feature list backs that framing with concrete storage and inspection surfaces rather than a chat window alone.
The intended user is someone running agents on their own hardware. The README lists desktop, Docker, headless server, VPS, homelab and Raspberry Pi as deployment targets, and the storage layer is SQLite plus filesystem data. That combination points at a specific audience: developers and small teams who want agent orchestration without shipping their prompts, tool outputs and internal documents to a vendor. If your agents only ever touch public data, the local-first constraint buys you less.
Runtime model: Electron shell, Express backend on 3333, SQLite underneath
The architecture visible in the README is a three-part stack. An Electron desktop shell hosts a Vue frontend. A local Express backend serves the API on port 3333 and covers agents, workflows, goals, tools, files, plugins, MCP, skills, insights and executions. SQLite holds the structured data, with additional filesystem storage alongside it. Real-time updates reach the UI through SSE streams and Socket.IO.
What matters about this layout is that the backend is a normal HTTP service, not something welded to the Electron process. The README explicitly lists a headless server and a VPS as targets, which only makes sense if the API can run without the desktop window. That gives you two consumption modes from one codebase: point the desktop app at its own bundled backend, or run the backend somewhere else and drive it over HTTP on 3333.
The runtime concepts are layered rather than parallel. Agents carry memory, tools, skills and provider configuration. Workflows are the repeatable path, built from 60 or more node types with triggers, branches, checkpoints and nesting. Goals sit above workflows: the README describes a loop of plan, execute, evaluate, re-plan, with pause, resume and revert. Subagents handle delegation across agents, workflows, async tools, MCP servers, plugins, APIs and parallel branches. SkillForge closes the loop by turning execution traces into reusable skills. Whether that loop works well in practice is not something the README demonstrates, and I have not run it.
Getting it running: three install paths and what each one assumes
The quickest route is a prebuilt desktop app for Windows, macOS or Linux from the downloads page. No build step is required, per the README.
Building from source uses npm. The README gives this sequence:
git clone https://github.com/agnt-gg/agnt.git cd agnt npm install cd frontend && npm install && cd .. npm start
Node 18.0.0 or later is required. The backend then listens on http://localhost:3333. For UI development there is a two-terminal split: run npm run dev inside frontend for the Vite dev server with hot reload, and npm start in the repository root for the Electron and backend side.
The README's install-path table adds a third option for self-hosting on a VPS, homelab or Raspberry Pi: Docker. It also mentions a fourth path for plugin authors, cloning the repository and working in backend/plugins/dev, though the supplied README is truncated at that row so the full plugin workflow is not visible here. If you plan to write plugins, read the plugin development section in the repository rather than relying on the install table alone.
Plugins as .agnt packages, and the marketplace question
Plugins are distributed as .agnt packages and can contribute tools, triggers and widgets. The README mentions hot reload and marketplace distribution, and the badge row claims 25 or more plugin templates. A plugin is therefore not just a tool function: it can register UI widgets and event triggers, which means the plugin boundary crosses backend and frontend.
That is a real design commitment and it has a cost. A plugin that ships a widget is coupled to the host's frontend, so plugin authors inherit some upgrade risk every time AGNT changes its UI layer. The README does not describe a stability contract for plugin APIs, and the project is at 0.6.6, so I would treat the plugin surface as moving. The marketplace also raises a distribution question the README does not answer in the supplied text: whether packages are reviewed before listing. For a local-first tool that can execute tools and touch files, that is worth checking in the repository before you install third-party packages.
Where AGNT is the wrong tool
The obvious failure mode is scale. SQLite plus local filesystem storage is a good fit for one machine and one operator. It is a poor fit for a team of twenty running concurrent long-lived goals against shared state, because there is no coordination layer in the described architecture. The README does not mention multi-user accounts, role separation or a remote database backend. If you need those, this is the wrong project and no amount of Docker will fix it.
Second, the release cadence is fast and the version is low. v0.6.4 landed in early July 2026, v0.6.5 in late July, v0.6.6 in early August, with repository activity continuing into September. Three releases in roughly a month at the 0.6 line means breaking changes are plausible. Anyone pinning AGNT for production needs a rollback story for the SQLite schema, and the README does not document migrations in the material available here.
Third, the licence metadata on the repository is NOASSERTION, which means GitHub could not map the licence file to a known identifier. That is not the same as "no licence", but it does mean you cannot assume MIT or Apache-2.0. If your organisation has a dependency review process, resolve this before you build anything on top of the plugin API. I am not giving legal advice here, only flagging that the metadata is ambiguous and the README does not clarify it.
How AGNT differs from LangGraph and n8n
The closest comparison in approach is LangGraph. Both model agent work as a graph with state, and both let you express branching and loops. The difference is where the graph lives. LangGraph is a library you embed in your own Python or JavaScript service, and you supply the persistence layer, the API surface and the UI. AGNT ships all three: the graph editor, the SQLite store, the HTTP API on 3333 and the desktop shell. You give up control over the runtime in exchange for not building it.
Against n8n, the split is the other way. n8n is a general workflow automation tool with a large integration catalogue and a hosted option; its unit of work is the integration step. AGNT's unit of work is the agent, with memory, skills, subagents and an evaluation loop layered on top. If your task is "when a form is submitted, update three SaaS systems", n8n is the better-shaped tool. If your task is "run this research goal until it converges, keep the trace, and turn the trace into a reusable skill", AGNT is aimed at you and n8n is not. Neither comparison is settled by feature counts; it is settled by whether you want to own the runtime.
Maintenance cost and what to verify before adopting
Running AGNT means maintaining two Node dependency trees (root and frontend), an Electron version, and a SQLite database whose schema you do not control. Upgrades arrive roughly monthly at the current cadence. The practical cost is not installation, which the README makes easy, but the upgrade path: you need to know what happens to existing agents, workflows and execution traces when the schema changes. Nothing in the supplied material describes a migration tool or a downgrade procedure.
There is also a provider surface to maintain. The README lists OpenAI, Anthropic, Gemini, Grok, Groq, Cerebras, DeepSeek, OpenRouter, Together, Kimi, MiniMax, Z.AI, local CLI auth and custom endpoints. Each is an external API that can change or deprecate independently of AGNT. Fifteen-plus integrations is breadth, and breadth is maintenance.
On licensing, the NOASSERTION status is the first thing to resolve, followed by the licences of the bundled plugin templates if you intend to redistribute anything built on them. The README does not state a licence for the plugin templates. Check the repository's licence file directly rather than the badge row, which says nothing about licensing at all.
Editorial conclusion
Adopt AGNT if you want agent execution data to stay on a machine you control and you are willing to treat a 0.6.x release as something you read the source of. Do not adopt it if you need a hosted control plane with an SLA, or if a permissively licensed dependency chain matters to your legal review. Before installing, check three things in the repository: which licence the NOASSERTION metadata actually resolves to, whether the Docker path is maintained alongside the desktop build, and whether the SQLite schema has migrations for the version you are upgrading from.
Community notes