AgenticX Multi-Agent Platform

Build and operate multi-agent workflows through one Python SDK, CLI, server, and local-first desktop workspace.

Stars
★ 706
Last updated
today
License
Apache-2.0
Primary language
Python

At a glance

How it runs
CLILibrary / SDKDesktop app
Works with
Universal · cross-platformClaude Code · OpenAI API · Claude API
Cost
Free software; you pay for model usage
Setup effort
Medium · a few setup steps
You'll need
Python 3.10+4GB+ RAM recommendedShell / CLINetwork accessLocal filesystemMCP Server
Typical use
A Python team building a service from specialist roles, functions, and conditional processes can combine the SDK, Workflow Engine, and FastAPI Studio Server.
Not a fit if
  • Teams needing one complete safety pipeline: Studio does not route every operation through SafetyLayer
  • Teams needing clustered or HA multi-replica runtime: cluster runtime is still planned
  • Teams expecting the Enterprise Go Gateway to be a full agent runtime
Source review
64/100 · Some gaps

What does this agent do, and when should you use it?

AgenticX is a developer-focused multi-agent stack comprising a Python SDK, the agx CLI, a FastAPI Studio Server, an Agent Runtime, Near Desktop, and a separate enterprise product line. Its execution layer includes graph workflows, the Flow system, a Meta-Agent CEO dispatcher, concurrent team management, and an embeddable asynchronous ReActAgent. Agents can invoke function, OpenAPI, remote, and MCP tools while using hierarchical memory, knowledge bases, GraphRAG, skills, hooks, sandboxes, and observability services. Near Desktop is an Electron and React local-first workspace that normally connects to a local agx serve process over REST and SSE; the Python SDK can also run independently of the desktop application. AgenticX Enterprise currently follows a separate Web Portal, Portal BFF, and Go AI Gateway path: the gateway handles authentication, policy, quotas, model relay, response governance, and auditing, but it is not the full Python Agent Runtime.

Developers define roles, tasks, callable functions, and models with Agent, Task, Tool, and AgentExecutor; the executor runs the task and returns its result. Function-calling applications can instead embed ReActAgent, which exposes ainvoke and astream, accepts multi-turn history, executes tools in parallel, and emits typed AgentEvent values. The workflow engine and Flow system build execution plans with conditional routing, parallel branches, output validation, and repair, while the Meta-Agent Runtime dispatches sub-agents, manages teams, and isolates sessions. The tool layer aggregates MCP servers, invokes OpenAPI and remote tools, and can execute controlled operations through Docker, Microsandbox, subprocess, or remote HTTP sandboxes. Its knowledge pipeline reads and chunks documents, constructs vector, BM25, or graph indexes, performs hybrid retrieval, and persists results through knowledge bases, hierarchical memory, session files, or optional storage backends. Runs can be inspected through callbacks, metrics, trajectories, span trees, WebSockets, Prometheus, and OpenTelemetry, with JSON, CSV, and Prometheus export formats.

  1. A Python team building a service from specialist roles, functions, and conditional processes can combine the SDK, Workflow Engine, and FastAPI Studio Server.
  2. A developer managing several local agent sessions can use Near Desktop for multi-pane chat, avatars, group conversations, an embedded terminal, workspaces, and per-pane model selection.
  3. A team searching internal documents and multiple repositories can mount isolated document and code brains, then combine vector, BM25, and GraphRAG retrieval.
  4. An engineering group running long-horizon coding work can ingest tasks from a manual queue, Cron, Linear, or project features and use isolated workspaces, stall recovery, and a disk-backed state machine.
  5. A platform team that must constrain generated code or tool calls can select Docker, Microsandbox, subprocess, or remote HTTP execution and combine it with approvals, path protection, and JSONL auditing.
  6. An organization needing a governed model entry point can evaluate the separate Enterprise Portal, Admin Console, and Go AI Gateway for authentication, policy, rate limits, response governance, and audit.

How do you install or deploy this agent?

Python 3.10 or later is required, and at least 4GB RAM is recommended. Install the lightweight core package from PyPI:

pip install agenticx

Optional feature groups can be installed individually; the complete extra introduces additional and potentially heavy dependencies:

pip install "agenticx[memory]"
pip install "agenticx[document]"
pip install "agenticx[graph]"
pip install "agenticx[llm]"
pip install "agenticx[monitoring]"
pip install "agenticx[mcp]"
pip install "agenticx[database]"
pip install "agenticx[data]"
pip install "agenticx[ocr]"
pip install "agenticx[volcengine]"
pip install "agenticx[all]"

For an editable source installation:

git clone https://github.com/DemonDamon/AgenticX.git
cd AgenticX
pip install uv
uv pip install -e .
uv pip install -e ".[memory,graph]"

Set credentials for the providers you intend to use; the Anthropic key is optional unless that provider is selected:

export OPENAI_API_KEY="your-api-key"
export ANTHROPIC_API_KEY="your-api-key"

How do you use this agent?

After installation, verify the CLI, create a project, or start the local Studio/API service:

agx --version
agx project create my-agent --template basic
agx serve --port 8000

This minimal SDK example creates an agent and task, executes them through OpenAIProvider, and prints the result:

from agenticx import Agent, Task, AgentExecutor
from agenticx.llms import OpenAIProvider

agent = Agent(
    id="data-analyst",
    name="Data Analyst",
    role="Data Analysis Expert",
    goal="Help users analyze and understand data",
    organization_id="my-org"
)

task = Task(
    id="analysis-task",
    description="Analyze sales data trends",
    expected_output="Detailed analysis report"
)

llm = OpenAIProvider(model="gpt-4")
executor = AgentExecutor(agent=agent, llm=llm)
result = executor.run(task)
print(result)

Expose a Python function as an agent tool with the decorator:

from agenticx.tools import tool

@tool
def calculate_sum(x: int, y: int) -> int:
    """Calculate the sum of two numbers"""
    return x + y

Document parsing is also available from the CLI:

agx mineru parse report.pdf --output ./parsed

What are this agent's strengths and limitations?

Pros
  • It provides several concrete entry points in one stack: an embeddable Python SDK, the agx CLI, a FastAPI REST/SSE service, and a local-first Electron workspace.
  • Model and tool portability is broad: the documented surface includes more than 15 model providers plus MCP, A2A, OpenAPI, AG-UI, and remote tools.
  • The runtime covers a substantial execution lifecycle, including graph orchestration, parallel tool calls, hierarchical memory, retrieval, skill lifecycle management, observability, evaluation, and multiple sandbox backends.
  • The architecture explicitly distinguishes the local Python Runtime, Near Desktop, and Enterprise Go Gateway, making important deployment boundaries visible.
Limitations
  • The scope and optional dependency matrix are large; document, graph, database, OCR, and data features require separate extras, and the OCR extra pulls in roughly 2GB of PyTorch.
  • Studio does not yet route every operation through one complete SafetyLayer; its current path combines hooks, permissions, and path protection, so adopters must validate security coverage.
  • Fine-grained tenant_id isolation and RBAC are not wired into the Core/Studio main path; Enterprise IAM belongs to a separate product line.
  • Near's implemented remote mode targets one agx serve backend, while clustered or highly available multi-replica runtime deployment remains planned.
  • Some third-party storage adapters are placeholders or are not connected to the Studio main path, so each intended backend needs verification.
  • The Enterprise Go Gateway is not a full agent runtime, and the Enterprise Edge Agent is a non-default MVP; teams expecting an integrated enterprise gateway and runtime may need additional engineering.

How does this agent compare with similar options?

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
AgenticX Multi-Agent Platform This agent 64 · Some gaps CLIFree + model costs ★ 706 today Python Claude Code · OpenAI API · Claude API
aiXplain SDK 29 · Major gaps Library / SDKFreemium ★ 59 17d ago Python —
AgentScope 2.0 70 · Some gaps Library / SDKFree + model costs ★ 34k today Python OpenAI API · Claude API
Agentlas OS 46 · Major gaps CLIFree + model costs ★ 1.6k 2d ago Python Codex · Claude Code

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Some gaps
64/ 100 5-point scale 3.2 / 5
This review covers the source as of Sep 11, 2026. The project has shipped 1 stable release(s) since, which have not been re-reviewed. The score and verdict describe the reviewed version only. Recent releases ↓
Trust 16/29
Reliability 9/14
Adaptability 12/18
Convention 14/18
Effectiveness 9/13
Verifiability 4/8
Why each dimension lost points
Trust16 / 29 · 2.8/5

The material shows optional dependency groups, local-first deployment, sandbox backends, path protection, permission and audit building blocks, and narrowly scoped GitHub Actions permissions. It also discloses default persistence under ~/.agenticx and outlines remote-model, MCP, messaging-gateway, and enterprise-gateway flows. Sensitive-data evidence includes API-key setup, leak detection, and a LiteLLM credential-exfiltration advisory, but not complete implementation evidence for secret storage, log redaction, retention, or connector-specific destinations. Approval and human intervention are asserted and linked to examples, but the supplied source does not demonstrate mandatory confirmation for consequential actions. Critically, the declared LiteLLM range still admits the disclosed malicious 1.82.7 and 1.82.8 releases, with no enforced exclusion or committed lock, limiting dependency security to 1. Tools, terminals, browsers, GUI automation, files, release clobbering, and messaging create broad external effects without a fully evidenced common authorization boundary. Snapshots, uninstall support, and state-machine concepts provide only partial rollback evidence. The license, package author, project links, and source authorship make attribution thorough.

Reliability9 / 14 · 3.2/5

The README, pyproject, requirements file, build workflows, and tests are broadly consistent about Python support, entry points, optional dependencies, and desktop build paths. The README usefully distinguishes implemented paths, MVPs, planned work, and adapters outside the main path. The very broad product surface is not equally substantiated, however, and the candidate description says Machi while the repository material says Near. Dependency grouping, system-package notes, platform matrices, and package-content checks are detailed, but there is no supplied lockfile and broad ranges plus many optional components create drift risk. The tests demonstrate fail-closed cases, structured blocker codes, nonzero exits, and preservation of state on failure. Those tests concern a module-summary utility, so they do not establish consistent failure handling across the runtime, Studio, desktop, and gateways.

Adaptability12 / 18 · 3.3/5

Developer, local-desktop, enterprise-governance, retrieval, GUI-automation, research, finance, and document scenarios are covered extensively, with SDK, CLI, server, and desktop entry points. Boundaries between the local Runtime, enterprise Gateway, Edge MVP, planned Cluster Runtime, and placeholder or unwired adapters are stated clearly, though feature-specific prerequisites and safety boundaries remain incomplete. Automatic tool selection, Meta-Agent dispatch, skill evolution, and background distillation are described without enough evidence for precise matching, suppression, conflict resolution, or safe default triggers. Python 3.10–3.13, macOS architectures, Windows, Docker/subprocess isolation, and several optional backends are addressed, but Linux desktop support, a complete system-compatibility matrix, and provider-specific environment requirements are not.

Convention14 / 18 · 3.9/5

The README provides architecture, capabilities, installation, quick-start, and example navigation, while pyproject organizes metadata and extras clearly. Its very long capability inventory and the truncated technical-architecture section reduce reviewability. Installation guidance is unusually concrete across PyPI, source, uv, pip, feature extras, credentials, and external packages. The agx and agenticx commands map explicitly to one entry point, but Machi versus Near naming and separate desktop-v versus unified v release tags add naming and version complexity. Examples are extensive, although no real FAQ or general troubleshooting section is supplied. Limitations such as planned components, MVP status, non-default paths, placeholder adapters, and incomplete SafetyLayer integration are candidly disclosed, but not consolidated comprehensively. Apache-2.0 metadata matches the complete license, justifying full marks. Package and desktop version paths exist and skill changelogs are mentioned, but no full changelog or release history is shown. An author, email, issue tracker, and discussions provide a maintenance route; the unverified publisher remains merely unknown, while team governance, support commitments, and maintenance policy are absent.

Effectiveness9 / 13 · 3.5/5

The SDK example returns a directly consumable result, and the CLI, REST/SSE service, typed events, export formats, and desktop workspace offer useful output channels. Representative production outputs and end-to-end quality evidence are not supplied. Combining orchestration, memory, MCP, desktop workflows, and an enterprise gateway could add substantial value over a narrow agent SDK, but many benefits are supported only by the same README and some components are outside the default path. A lightweight core plus optional extras and disclosure of the roughly 2 GB OCR cost show cost awareness. Conversely, 27 core dependencies, multilingual build stacks, many services, and multiple model providers imply substantial deployment, API, storage, and operational costs that are not systematically quantified against benefits.

Verifiability4 / 8 · 2.5/5

Some claims trace directly to package entry points, versions, dependencies, and platform metadata, while workflows corroborate desktop builds and artifact checks. The supplied tests concretely support fail-closed planning, token binding, path-escape defenses, and state preservation. Major claims such as production readiness, 15+ providers, complete monitoring, 9x acceleration, self-repair, and numerous enterprise capabilities remain README assertions without corresponding implementation files, benchmarks, or tests in the evidence, so traceability is thin. Installation, versioning, CLI, and build details receive cross-file corroboration, but security and broad product claims receive much less. The README commendably labels planned, MVP, default-path, and incompletely integrated components, although promotional qualifiers are not consistently separated from verified facts.

Risks and how to mitigate them
  • The litellm>=1.50.0,<2 constraint in pyproject.toml and requirements.txt still admits 1.82.7 and 1.82.8, which the README identifies as API-key-exfiltrating releases. Explicitly exclude them, use a trusted lockfile, and rotate potentially exposed credentials before deployment.
  • Do not treat README labels such as production-ready, complete, secure sandbox, or 9x as independently verified; this assessment did not execute code, tests, benchmarks, or installers.
  • Tools, terminals, browser and GUI automation, MCP, skill self-evolution, and messaging gateways can cause high-impact external actions. Use isolation and least privilege until common approval defaults, audit coverage, and recovery behavior are confirmed.
  • Default ~/.agenticx persistence, remote model calls, Redis/databases, knowledge bases, and messaging gateways may process sensitive information. The supplied material does not establish complete retention, deletion, encryption, or third-party transfer policies.
  • Near Desktop, the Python Runtime, Enterprise Gateway, Edge MVP, and planned Cluster Runtime have distinct maturity and deployment paths; do not assume every advertised capability is available in one installation.
Evidence confidence: Low Reviewed Sep 11, 2026 Reviewed revision 900da057f5f0 New commits since this review; the score may not cover them
See the full review method →

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

  1. v0.6.5 AgenticX v0.6.5 / Near Desktop v0.6.0
    Release notes excerpt
    AgenticX Joint Release — 2026-09-30 This release ships three tracks together: - AgenticX (Python core) v0.6.0 → v0.6.5 - Near Desktop v0.5.0 → v0.6.0 - AgenticX Enterprise v0.3.0 → v0.3.5 Installation / Upgrade ```bash pip install -U agenticx==0.6.5 ``` - Near Desktop: download the Apple silicon disk image or the Windows installer attached to this release. - AgenticX Enterprise: follow enterprise/README.md for upgrade steps. --- AgenticX v0.6.5 (Python core) Highlights - Core / Runtime …
    View on GitHub ↗
  2. v0.6.0 AgenticX v0.6.0 + Near Desktop v0.5.0
    Release notes excerpt
    AgenticX Joint Release — 2026-08-31 This release ships three tracks together: - AgenticX (Python core) v0.5.0 → v0.6.0 - Near Desktop v0.2.5 → v0.5.0 - AgenticX Enterprise v0.2.2 → v0.3.0 Downloads Installers are the Assets at the bottom of this GitHub Release page (public, no login). Do not use Actions artifact names such as near-arm64 — those links expire and require a GitHub login. - Near-0.5.0-arm64.dmg — macOS Apple Silicon - Near-0.5.0-win-x64.exe — Windows x64 …
    View on GitHub ↗
  3. v0.5.0 AgenticX v0.5.0
    Release notes excerpt
    Published Python package: agenticx==0.5.0 Installation ```bash pip install -U agenticx==0.5.0 ``` PyPI - https://pypi.org/project/agenticx/0.5.0/ Highlights - Core / Runtime - ToolSearch projects only the tools needed each round (with MCP catalog adapter and adaptive threshold/hysteresis), cutting tool-schema bloat on large MCP setups. - Stronger turn reliability: stuck-prevention self-healing, futile-resume circuit breaker, empty-tool-turn fallback, truncated-reply auto-retry, and SSE drop / auto-resume continuation. …
    View on GitHub ↗

FAQ

Is AgenticX tied to one model vendor?
No. The documented adapters cover more than 15 providers, including OpenAI, Anthropic, Ollama, Gemini, Kimi/Moonshot, MiniMax, Ark/VolcEngine, Zhipu, Qianfan, and Bailian/Dashscope, with caching and failover routing. Each provider still requires its own credentials and configuration.
Can I use only the SDK without the desktop application?
Yes. Agent, Task, Tool, and AgentExecutor are embeddable Python primitives, while the independent ReActAgent path explicitly has no Studio or CLI coupling.
Is production multi-tenancy already available everywhere?
Not across every product path. The Enterprise line has separate IAM, policy, quota, and auditing capabilities, but fine-grained Core/Studio multi-tenancy and RBAC remain the planned M18 module.
Where is local data stored by default?
Studio stores configuration, sessions, and workspaces under ~/.agenticx; SQLite handles session metadata and full-text search. Redis is an optional Studio session backend, and Chroma is the default desktop knowledge-base vector store.
What protects untrusted code and tool execution?
The project documents Docker, Microsandbox, subprocess, and remote HTTP sandbox backends plus leak detection, injection detection, approvals, and auditing. It also states that Studio does not yet pass every operation through the complete unified SafetyLayer, so deployments must verify and configure their own protection boundary.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents