NagaAgent: An Anime-Styled Desktop Assistant Built Around MCP, Live2D and a Graph Memory
A simple yet powerful agent framework for personal assistants, designed to enable intelligent interaction, multi-agent collaboration, and seamless tool integration.
At a glance
- What is it?
- NagaAgent is a Python and Electron personal assistant that bundles streaming tool calls, a Neo4j-backed memory graph, Live2D avatars and an embedded OpenClaw agent runtime. The interesting part is the packaging, not the model plumbing, and the licence split is the first thing to read.
- Who is it for?
- Adopt NagaAgent if you want a self-hosted desktop assistant with a Live2D front end, MCP tool calling and a graph-backed memory, and you are comfortable with AGPL-3.0 or willing to request the separate written closed-source licence from contact@nagaagent.com. Do not adopt it if you need a headless library to embed in a proprietary service, or if you cannot run Python 3.11 exactly and a Neo4j instance alongside it.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 36 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
The problem NagaAgent picks, and who it is aimed at
Most agent frameworks ship as a library and leave the desktop shell to you. NagaAgent goes the other way. The README describes it as a personal assistant with a Live2D avatar, voice interaction, a knowledge graph memory and a community network called NagaNet, and the repository is organised as a full application rather than an importable SDK. The stated goal in the README is a client-side assistant that a single person runs on their own machine.
The audience is therefore narrow and specific. It is someone who wants a character-driven assistant with mouse interaction, streaming replies and a persistent memory, and who is willing to run an Electron front end plus a Python backend to get it. The README lists six headline capabilities: one-click login that auto-configures API keys, an embedded OpenClaw runtime for autonomous exploration, automatic construction of a three-dimensional memory cloud from conversation history, a forum and exploration layer, a game-guide component that can read the screen and optionally drive the game through plugins such as MAA, and assorted components including self-configuration, browser control and a music player.
That is a consumer product scope, not a developer tool scope. If you are looking for a minimal loop that calls tools and returns text, this project carries a large amount of surface area you will never use.
How the pieces fit: MCP tools, an OpenClaw runtime and a graph memory
The architecture visible in the changelog is a Python backend plus an Electron front end, with an agent loop in the middle. The project migrated to native Function Calling in the 2026-03-04 release, and the same entry notes a refactor of the prompt injection architecture. Tool integration runs through MCP: the topics list includes mcp and mcp-client, and the 2026-06-20 entries mention adding `tool_calls` and `tool_results` to SSE and folding full tool results in the front end. So the data flow is roughly: the front end sends a message over SSE, the backend runs a tool loop, tool invocations and their results are streamed back as structured events, and the UI renders them collapsed by default.
Memory is a separate subsystem. The README describes a three-dimensional memory cloud built automatically from conversation history and injected into later conversations. The changelog names Neo4j as the local store, with a cloud alternative called NagaMemory, and one entry states that when cloud memory is preferred the system no longer falls back to local Neo4j. There is also a five-tuple extractor mentioned in the 2026-04-14 entry, which implies the graph is populated by an LLM extraction step rather than by raw transcript storage. Context compression is a third layer, described as a three-level scheme using a `<compress>` tag with cross-session inheritance.
OpenClaw is embedded rather than external. The changelog records it being packaged from vendor source, renamed to AgentServer at one point, and given automatic gateway and hooks configuration. Exploration tasks can be created per character with time and credit limits and an initial browser policy, and browser visibility can be toggled while a task runs. That is a meaningfully different design from a framework that expects you to supply your own sandbox.
Getting it running: the commands and config keys the README gives
The environment requirement is strict: Python 3.11, specified as `>=3.11, <3.12`. uv is optional but recommended for dependency installation, and Neo4j is optional if you want local graph memory. The README gives this sequence:
git clone https://github.com/Xxiii8322766509/NagaAgent.git cd NagaAgent cd frontend && npm install && cd .. uv sync
The manual path is a virtual environment plus `pip install -r requirements.txt`. Minimum configuration starts by copying `config.json.example`, and the README truncates at that point, so I cannot tell you what keys the example file contains. What the changelog does tell you is that since 5.1.3 the runtime reads `config.json` from the project root first and falls back to the user data directory only if it is absent, and that the settings page save target was moved to match. Earlier releases describe persistent storage being unified under `~/.naga`.
Several config keys appear by name in the release notes. `api_format` selects between OpenAI-style and Anthropic-style APIs. `provider` and `use_gateway` control model routing. `content_clean` is referenced in the TTS fix as the cleaned message body that is preserved for speech. There is no port list in the material I have, only a table of contents entry pointing at one, so I will not guess at ports. If you are starting from scratch, treat the 5.1.3 config priority change as the first thing to confirm, because a stale file in the user data directory will silently lose to a root-level file.
Where it breaks: cloud dependency, platform quirks and a moving target
The clearest limitation is that parts of the system assume a NagaBusiness account. Search runs through a NagaBusiness proxy when logged in and falls back to Brave or OpenClaw when not. There is a credit and affinity system with sign-in rewards, a recharge page, and a 2026-05-10 fix specifically to stop requests from incorrectly routing through NagaBusiness and deducting credits when the user is logged out or the gateway is off. That fix tells you the failure mode existed and was considered a bug. If you want a fully offline assistant, you are working against the grain of the design, though the changelog does show direct-to-user-API paths being maintained.
Platform behaviour is another rough edge. The 5.1.5 release is entirely a fix for a Windows transparent frameless window that disappears when maximised and then restored, worked around by avoiding Electron's native transparent window maximise state. That is a shell-level defect, not an agent-level one, and it suggests the desktop packaging has been the main source of instability. The changelog is dense with fixes of this kind: tray icons, single-instance wakeup, off-screen window recovery, macOS DMG signing, console encoding on Windows.
Finally, the release cadence is high. Five point releases between 5.1.0 in late February and 5.1.5 in mid July, plus dozens of untagged changes, means the surface you integrate against moves. Anything you build on undocumented internals will need attention.
Alternatives and the actual difference in approach
The most direct comparison is with a plain MCP client library plus your own UI. A library such as the reference MCP client gives you the protocol and nothing else: you write the loop, you choose the memory strategy, and you own the interface. NagaAgent hands you all three already assembled, at the cost of accepting its choices. Its memory is a Neo4j graph populated by an extraction step, not a vector store, which means recall depends on how well the five-tuple extractor captures relations from your conversation. A vector-store assistant will retrieve differently on the same history, and neither is universally better; the graph approach is more structured and harder to populate correctly.
A second comparison is with desktop assistant shells that run a model locally. NagaAgent is not that. It is a client for hosted APIs by default, with a gateway layer in front, and its offline story is partial. If your requirement is that no conversation leaves the machine, the architecture here is the wrong shape, regardless of how the memory is stored.
A third comparison is with agent runtimes that treat the browser as the execution environment. NagaAgent embeds OpenClaw and gives it a browser policy, credit limits and a visibility toggle, which is closer to a managed exploration sandbox than to a scripting API. If you want to write your own browsing logic, that embedded runtime is an obstacle rather than a feature.
Licence, upgrades and what maintenance actually costs
NagaAgent is dual-licensed. The README states that open source use is under AGPL-3.0 and closed-source use requires a separate proprietary licence with written authorisation, contactable at contact@nagaagent.com. The badge in the README reads AGPL 3.0 or Proprietary. I am not a lawyer and this is not legal advice, but the practical consequence of AGPL-3.0 is that if you modify the code and expose the modified version to users over a network, the source obligations attach. For a personal desktop assistant that a single person runs, that is unlikely to matter. For anything you intend to ship as a closed product, the proprietary track is the one to pursue, and you should read both `LICENSE` and `LICENSE-CLOSED-SOURCE` before writing code against it.
Upgrade cost is driven by the cadence. The project ships an Electron auto-update mechanism, having replaced an older patch system with GitHub Actions builds, and version checking now uses GitHub Releases as the source of truth, with an explicit failure state when the official version cannot be confirmed. That is a sensible design, but it means you are on a release train rather than a pinned dependency. Node.js and uv runtimes are distributed with the package, so a packaged install does not require a toolchain on the target machine, while a source install does.
There is no migration guide in the material. If you store memory in local Neo4j and later switch to cloud memory, the changelog says the fallback to local stops, but it does not say what happens to existing graph data. That is worth testing on a throwaway profile before you commit a real conversation history to it.
Editorial conclusion
Adopt NagaAgent if you want a self-hosted desktop assistant with a Live2D front end, MCP tool calling and a graph-backed memory, and you are comfortable with AGPL-3.0 or willing to request the separate written closed-source licence from contact@nagaagent.com. Do not adopt it if you need a headless library to embed in a proprietary service, or if you cannot run Python 3.11 exactly and a Neo4j instance alongside it. Verify first that `config.json` is being read from the project root rather than the user data directory, since the 5.1.3 release note changed that priority order, and confirm which API keys your build actually needs before you log in.
Community notes