Agentica: a multi-session agent CLI that keeps working while you are away

The problem is a single terminal that cannot hold two jobs at once

Most CLI coding agents give you one conversation per process. When a refactor takes twenty minutes, that terminal is occupied. You either wait or open a second one that knows nothing about the first. Agentica's answer, per the README, is that one terminal session is itself a cooperating agent: a process-level delegate starts an entire separate agent for an independent large task, an in-process task spawns a temporary subagent, and cross-terminal peer messages let two sessions talk to each other. The stated goal is that none of this needs extra deployment. The audience is a developer running agents on their own machine who wants several of them alive at once and wants to leave the desk without killing the run. The WeChat, WeCom, Feishu and Telegram gateway exists for that last part: you address a session by name with an @ mention, or you say something in plain language and a gateway agent decides which session on the machine should handle it.

Sessions, delegate and peer messages: what the architecture actually is

The mechanism visible in the material is process and message scoping rather than a scheduler. A CLI session is the unit of identity. Inside it, task creates a subagent in the same process, which keeps the cost low but means the subagent shares the parent's lifetime. delegate goes the other way and starts a whole new agent process, which is why the README describes it as suitable for independent large work. Peer messaging crosses terminal boundaries, so two sessions started separately can exchange messages without a broker. The gateway sits on top of this: agentica-gateway serves a local single-page app at http://127.0.0.1:8881/chat with chat, trace and settings views, and the IM channels connect to the same machine. Desktop, Web and CLI are described as sharing one set of history, working directory, model and configuration state, which is what makes the gateway able to route an inbound message to a session that a human started earlier at a prompt. The Python SDK is async-first with asyncio.gather() for parallel tool execution and a synchronous adapter, and DeepAgent is the preassembled configuration that bundles built-in tools, compression, long-term memory, skills and MCP.

Installation, the gateway token, and the first-run password

Both the CLI and the gateway install through uv tool into an isolated environment, so they do not bind to the system Python. The README gives these commands: uv tool install agentica for the CLI, and uv tool install "agentica[gateway]" for Web and Desktop backends. If the CLI is already installed and you later want Web, the documented form is uv tool install --force "agentica[gateway]". Upgrades use uv tool upgrade agentica, and if the command is not found, uv tool update-shell. Model credentials come from any one provider, with a documented precedence of shell environment variable over .env over config.yaml. The README shows OPENAI_BASE_URL and OPENAI_API_KEY, or ZAI_API_KEY for ZhipuAI, and notes that agentica setup generates ~/.agentica/config.yaml with /model available inside the CLI to switch. The TypeScript SDK is a separate matter: npm install @agentica-ai/sdk, and the package name must be written in full because agentica-sdk on the npm registry is a different thing. Its example authenticates with AGENTICA_GATEWAY_TOKEN, which the README locates at ~/.agentica/cache/gateway/runtime.json. That file is worth a permissions check on a shared host. On first gateway start the README says a default account is created and a random initial password is printed to the terminal.

The benchmark claim and why you should reproduce it yourself

The README states that on the same public coding and data analysis question sets, Agentica matches or beats OpenAI Codex on accuracy while using less wall-clock time and fewer input tokens, and it links a benchmark page with reproduction commands, per-item metrics and the raw predictions.jsonl. I have not run it. The claim as written is a comparison of one agent harness against another on a fixed question set, which is a narrower statement than it may read as. Two things are not established by the material: which model was held constant across both sides, and whether the question sets were chosen before or after the harness was tuned. The README does say the tool surface is deliberately narrowed and the interface kept low-level, with specific adaptation for open models such as DeepSeek. If the benchmark page publishes the commands and the raw predictions, the honest move is to rerun it on your own machine rather than take the summary line. Treat the accuracy, wall-clock and token figures as claims to verify, not as settled properties of the tool.

Self-evolving skills are a cache, and caches go stale

The README describes experience from a completed run being compiled automatically into a reusable SKILL.md that persists across sessions, so that a later task of the same kind starts from the agent's own previous conclusion instead of from nothing. That is a real mechanism with a real failure mode, and the README does not address the failure mode. A skill file written from a run that succeeded for incidental reasons will be replayed on the next task of that shape. Nothing in the supplied material describes a validation step, a confidence signal, or a way to mark a skill as superseded when the underlying toolchain changes. The practical consequence is that the longer you use it, the more you are trusting artifacts you did not review. There is a skills document linked from the README, and that is where to look for whether skills can be edited, versioned or deleted. If they cannot be inspected and pruned, self-evolution is a liability on projects where the environment moves, not an advantage.

The desktop build is unsigned and the SDK documentation is thin

Three platform notes in the README are really one constraint: the desktop builds are not signed. On macOS the app may be reported as damaged, and the documented fix is sudo xattr -rd com.apple.quarantine /Applications/Agentica.app. On Windows, SmartScreen shows a warning and the documented path is More info then Run anyway. On Linux, a browser-downloaded AppImage lacks the execute bit and needs chmod +x. These are normal for an unsigned build and the README is upfront about them, but they are friction you will hit on every machine you deploy to, and they are the kind of step that a managed corporate endpoint will block outright. Separately, the Python SDK section of the README is the thinnest part. It shows an Agent constructed with a model and three built-in tools, then run_sync, and it shows DeepAgent() with no arguments. The collaboration features are named, Agent.as_tool() among them, but the README text is truncated mid-sentence in the feature list, so the calling convention is not established by the material I have. Plan on reading the source under the package rather than the README if you intend to build on the SDK.

Compared with LangGraph, the difference is where state lives

LangGraph is the obvious alternative for someone building multi-agent Python systems, and the difference is not features but the unit of composition. LangGraph models a workflow as a graph of nodes and edges with an explicit state object threaded through it. You write the topology. Agentica models a workflow as sessions on a machine, where the topology is created at runtime by the agent itself through task, delegate and peer messages. That means Agentica gives you less control over the execution path and more latitude for the agent to decide its own decomposition, and it means debugging is a matter of reading traces rather than inspecting a graph you authored. LangGraph has no opinion about WeChat or a local web UI. Agentica ships both. If your requirement is a reproducible pipeline with a fixed shape, LangGraph's approach fits better. If your requirement is a developer with several terminals and a phone, Agentica is aimed squarely at you.

Maintenance, licence and what a version bump costs you

Agentica is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirement to preserve notices and state changes. That is a permissive licence and I am not going to give legal advice about your situation; read LICENSE in the repository if you are redistributing or embedding it. On maintenance, the release cadence visible in the material is roughly weekly across v1.4.13, v1.4.14 and v1.4.15 in August and September, and the last push to main is dated 2026-09-10. Frequent patch releases on a 1.x line mean you should pin the version in your environment rather than track latest, because a weekly cadence is also a weekly opportunity for a behavioural change in tool defaults or prompt construction. Upgrading is a single command, uv tool upgrade agentica, and the state that matters lives in ~/.agentica, which is not touched by the installer. That separation is the good part of the design: reinstalling the tool does not cost you history, skills or configuration. The bad part is that skills compiled by an older version keep loading under a newer one, and nothing in the material says otherwise.

Editorial conclusion

Adopt Agentica if you already work in a terminal and want several long-running agent sessions on one machine, addressable from WeChat, WeCom, Feishu or Telegram. Do not adopt it if you need a signed desktop installer, a stable documented Python SDK surface, or a framework with years of third-party integrations. Before committing, verify three things yourself: the benchmark reproduction page at shibing624.github.io/agentica/guides/benchmark, the exact API surface of Agent.as_tool() and DeepAgent in the release you install, and whether the gateway token file at ~/.agentica/cache/gateway/runtime.json is readable by anyone else on the host.

Official sources

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