AgenticX is one Python agent runtime behind a CLI, a desktop app and a gateway

One capability core, two product forms

The architecture is described as one shared capability core and two product forms, and the doc is clear that they are not the same thing.

AgenticX Core and Runtime is the Python SDK, the Studio Server and the Agent Runtime, covering orchestration, tools, MCP, memory, knowledge bases, Skills, Hooks, model adapters, secure sandboxes, observability and evaluation.

Near Desktop is an Electron and React local-first workspace. Its default path connects to a local agx serve or agx-server, and it has multi-pane chat, avatars and group chat, workspaces, a terminal, automation, Voice Focus, and an optional remote single-server backend.

AgenticX Enterprise is the web portal, admin console and Go AI Gateway, with employee chat passing through a Portal BFF before the gateway. The gateway handles authentication, policy, quota, model relay, response governance, audit and usage, and the documentation is explicit that it is not a full Agent Runtime.

That last distinction is the one to hold on to. Near and Enterprise share AgenticX abstractions and capabilities, but their deployment paths are currently independent, Near defaults to the local Python runtime, and Enterprise uses the Go gateway for its online path. Enterprise Edge Agent is an MVP outside the default path, and Cluster Agent Runtime remains planned.

The agent loop, and the pieces around it

The core framework is an agent execution engine based on the 12-Factor Agents methodology, with a Meta-Agent CEO dispatcher, agent team management, a think-act loop, event-driven architecture, self-repair and overflow recovery.

The embeddable primitive is a ReActAgent with an async function-calling loop exposing ainvoke and astream, a typed AgentEvent stream, multi-turn history in and out, parallel tool execution, and optional injection of a loop-detector, a compactor or an offloader. It is described as having zero Studio or CLI coupling, and a legacy text-JSON TextReActAgent facade is kept for compatibility.

The offload mechanism is worth understanding because it addresses a real limit. The Offloader protocol and a filesystem-backed FileOffloader keep large tool results and compressed context out of the live history, leaving inline reference placeholders that are retrieved on demand, and there is also an in-workspace MCP gateway that runs MCP servers inside the sandbox.

Around that sits an orchestration engine, which is a graph-based workflow engine plus a Flow system with decorators, execution plans, conditional routing and parallel execution, and a tool system with a unified interface, function decorators, an MCP Hub for multi-server aggregation, remote tools v2, an OpenAPI toolset, sandbox tools, skill bundles and document routers.

Task validation is Pydantic-based, with output parsing, auto-repair and guiderails.

Memory in three layers, and retrieval in several flavours

The memory system is hierarchical, with core, episodic and semantic layers, plus Mem0 deep integration, workspace memory, short-term memory, memory decay, hybrid search, compaction flush, MCP memory and a memory intelligence engine. That is a lot of subsystems under one name, and the practical question is which of them you actually configure.

Retrieval is split into a stack of retrievers, which is a more useful decomposition. There is a vector retriever, a BM25 retriever, a graph retriever, a hybrid retriever, an auto-retriever and a reranker. The code semantic index uses hybrid vector and BM25 retrieval across multiple codebases, and it is wired into the code brain.

The knowledge base sits above that, with a document processing pipeline of chunkers, readers, extractors and graph builders for GraphRAG. On top of it is the multi-brain knowledge model, an isolatable and per-avatar or per-session mountable architecture of a doc brain and a code brain with cross-brain aggregated search.

Embeddings are provided for OpenAI, Bailian, SiliconFlow and LiteLLM, with smart routing. The point of the multi-brain arrangement is that a session can be given only the doc brain, only the code brain, or both, which is a way of scoping what an agent can see.

Skills that rewrite themselves, and a scan gate on the way in

The skill system is the part of the framework with an unusual lifecycle. It handles registration and full lifecycle management, with a dangerous-pattern security scan gate, a five-strategy fuzzy patch, changelog versioning, source tagging, and per-skill enable and disable.

Then there is the self-evolution part. The skill system captures tool-call observations at runtime and auto-distills new skills through a background LLM session review, with a quality gate, usage statistics and deprecation forming the lifecycle loop.

Read that carefully, because it is the design decision with the most consequences. The framework watches what your agents do and writes new skills from those observations, which means the prompt library evolves without a human editing it. The dangerous-pattern scan gate is the counterweight, and so are the quality gate and the deprecation mechanism. A team deploying this should decide what it is willing to let the loop change.

The extension ecosystem, called AGX Bundle, carries bundle definitions covering skills, MCP servers and avatars, so the distribution unit is a bundle rather than a single file.

Fifteen providers, and a set of protocols around them

The model layer lists 15 or more providers: OpenAI, Anthropic, Ollama, Gemini, Kimi and Moonshot, MiniMax, Ark and VolcEngine, Zhipu, Qianfan, and Bailian with Dashscope, with response caching, a transcript sanitizer and failover routing.

Two protocols sit alongside that. There is an A2A inter-agent protocol with a client, a server, an AgentCard and a skill-as-tool pattern, and there is the MCP resource access protocol, with the MCP Hub providing multi-server aggregation for tools.

The avatar and team layer sits on top of that. There is an avatar registry with create, read, update and delete operations, group chat with several routing strategies including user-directed, meta-routed and round-robin, a Meta-Agent runtime with a CEO dispatcher, dynamic sub-agent orchestration, team management with concurrency limits, archived snapshots and session isolation, and collaboration patterns covering delegation, role-playing, conversation management, task locks and collaboration metrics.

The IM gateway for Feishu and WeChat is what connects the system to chat platforms, and the repository topics name the desktop app, Electron, FastAPI, RAG, GraphRAG and tool use, which matches the code layout.

Installation, and the LiteLLM warning in the readme

The package is on PyPI as agenticx, and the manifest requires Python 3.10 or newer with the classifiers naming 3.10 through 3.13. The development status is 4, Beta, and the licence is Apache-2.0 with the LICENSE file listed in the manifest.

The dependency list is large and carefully commented, and the comments are in Chinese, which tells you something about where the project is developed. The core list covers pydantic, loguru, rich and click, then httpx, requests, aiohttp, aiofiles and websockets, then fastapi and uvicorn, then the LLM layer with the openai client, litellm, tiktoken, tokenizers and huggingface-hub, and then a general tools group with docstring-parser, ujson, tqdm, joblib, chardet, psutil, structlog and watchdog. The comment on the core block says it is light, without torch, and installs in seconds.

There is a separate requirements.txt that mirrors the manifest dependencies and marks the manifest as the source of truth, to edit first and refresh afterwards. The install commands it lists are:

#   pip install -e .
#   pip install -e ".[desktop-runtime]"   # Near Desktop / agx serve bundle
#   pip install -e ".[dev]"               # pytest, formatters, etc.

The setup.py in the repository is deliberately minimal, a docstring saying all metadata and dependencies come from pyproject.toml, and a single call to setup.

And then there is the security advisory at the top of the readme, which is unusual to see in a project readme and worth repeating. Malicious LiteLLM releases 1.82.7 and 1.82.8 were removed from PyPI after reports that they could exfiltrate API keys. If you installed either, uninstall them, rotate any credentials that may have been exposed, and upgrade to a release the upstream project and PyPI list as safe, for example 1.82.9 or later. The readme tells you to check your environment with pip show litellm.

Since AgenticX depends on litellm directly, that check is not optional for anyone installing this project.

A repository with a lot of directories, and a fast release line

The repository layout is a good map of the ambitions. At the top level there is the agenticx package directory, a desktop directory for Near, an enterprise directory, a connector-runtime directory, a deploy directory, a mobile directory, a packaging directory, a scripts directory, a tests directory, a docs directory with an mkdocs configuration, a paper directory, a research directory, a plans directory, a results directory and a conclusions directory, plus a harness-lab directory and a diagrams directory.

The examples directory shows what the framework is meant to be used for. There are agenticx-for-agentkit, agenticx-for-deepresearch, agenticx-for-delivery, agenticx-for-docparser, agenticx-for-finance, agenticx-for-graphrag, agenticx-for-guiagent, agenticx-for-intent-recognition and agenticx-for-sandbox, along with demonstrations for multi-agent setups, embeddings, retrieval, observability, collaboration and human in the loop, and per-provider chat scripts for Bailian and Kimi.

There is also an install.sh at the root, an INSTALL.md, a SECURITY.md, an AGENTS.md, and both English and Chinese contributing guides, matching the bilingual readme.

The releases are frequent: v0.6.5 on 2026-09-30, which also brought Near Desktop to v0.6.0, v0.6.0 on 2026-08-31, and v0.5.0 on 2026-08-08. The last push was on 2026-10-20, and the project is not archived. The homepage is agxbuilder.com, and the version numbers sitting below 1.0 with a beta classifier are the honest signal about the maturity of the whole stack.

Editorial conclusion

Adopt AgenticX if you are building an agent application in Python and want the runtime, the tool layer, the memory system and the retrieval stack in one dependency rather than assembling them yourself, and you are prepared to handle a framework of this size. Do not adopt it if you need a small library you can read in an afternoon, and treat the enterprise gateway claims as a separate product from the runtime. Before you install, check three things: the LiteLLM version in your environment, because the project warns that versions 1.82.7 and 1.82.8 could exfiltrate API keys, the Python version, since the package requires 3.10 or newer, and which of the two product forms you actually need, since Near defaults to the local runtime while Enterprise uses the Go gateway on a separate path.

Frequently asked questions

Official sources

1. DemonDamon/AgenticX on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases