Sage: A Multi-Agent Platform That Ships as a Desktop App, Web UI, CLI and Chrome Extension
Multi-Agent System Framework For Complex Tasks
At a glance
- What is it?
- Sage is a Python agent platform built around planning, execution and self-check agents, distributed as installers, a Vite web app and a CLI. The interesting question is not what it does but whether its breadth is worth the setup cost.
- Who is it for?
- Adopt Sage if you need agent runs that end in delivered messages or files across WeChat, WeCom, Feishu or DingTalk, and you are willing to run the backend yourself. Skip it if you want a single-purpose library to embed in an existing Python service, because the multi-surface product layer is the bulk of what you would be pulling in.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day 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 Gap Sage Targets: Agent Runs That Have to End Somewhere
Most agent frameworks stop at the point where the model produces text. Sage's README frames the problem differently, describing itself as a platform for "task execution, automation, browser workflows, IM delivery, and enterprise deployment." The delivery half is the distinguishing part. A run can terminate in a WeChat Personal (iLink), WeCom, Feishu or DingTalk message, with file attachments, rather than in a console transcript. That matters for teams whose operational output is a notification to a human, not a returned string. The audience implied by the feature list is operations and internal-tooling engineers: people who already have a recurring job, a questionnaire flow or a browser task that a human currently performs by hand. It is not aimed at researchers benchmarking agent reasoning, and the README makes no accuracy claims of that kind. The second audience is teams that need a UI their non-engineers can open. The Visual Workbench renders files, tool output, code, charts, Mermaid and Draw.io diagrams, audio, video and remote previews in one workspace. That is a product decision, not a framework decision, and it shapes everything else about the repository.
AgentFlow and the Named Agent Roles
The architecture diagram shows a layered split. Client surfaces (desktop app, web app, CLI, Chrome extension, IM channels) all feed an App Service Layer, which owns chat and sessions, agent management, tasks and automations, the browser bridge and the workbench. Below that sits SAgents Core, entered through a Session Runtime, which drives AgentFlow, which in turn runs the named agents: Plan, Simple, Fibre and Self-Check. The README's feature list adds memory recall and tool suggestion to that set. The mechanism, as far as the documentation describes it, is sequential role separation rather than peer negotiation. A planning agent produces the decomposition, execution agents carry it out, a self-check agent reviews the result, and memory recall feeds prior context back in. There is no mention of a voting or debate protocol between agents, so anyone expecting emergent multi-agent consensus should read the AgentFlow source before assuming it. Tooling is unified underneath: built-in tools, Skills, MCP servers, browser automation, search and image generation are all reachable from the same execution stack. That single tool registry is what makes the multi-surface design coherent. A tool written once is callable from the desktop app and from a scheduled IM job without a second integration.
Installation Paths and the Python Version Split
Sage ships four ways, and the version requirements differ between them. The web app from source needs Python 3.10+ and Node.js 18+, and starts with three commands: git clone https://github.com/ZHangZHengEric/Sage.git, cd Sage, then ./scripts/dev-up.sh. The UI lands on http://localhost:5173. On first run the script asks you to choose Minimal (SQLite) or Full, and the README calls Minimal the quickest. Two environment overrides exist for the launcher: PYTHON_BIN=... and USE_UV=1 ./scripts/dev-up.sh. The CLI path is separate and shorter. After pip install -e ., you export SAGE_DEFAULT_LLM_API_KEY, SAGE_DEFAULT_LLM_API_BASE_URL, SAGE_DEFAULT_LLM_MODEL_NAME and SAGE_DB_TYPE="file", then run sage doctor to check the setup and sage run "Say hello briefly." or sage chat. The README's own example points the base URL at https://api.deepseek.com/v1 with deepseek-chat as the model. Note the version trap: SAgents v2 and Desktop v2 require Python 3.12+, while the general prerequisite line still says 3.10+. If you are building against the v2 agent core on a 3.10 or 3.11 interpreter, the documented prerequisites will not save you. Desktop users can avoid Python entirely by taking a .dmg, .exe NSIS installer or .deb from Releases.
Sandbox Modes, Gatekeeper, and Other Friction You Will Actually Hit
The README lists three sandbox options for agent runtime isolation: local, passthrough and remote. It does not say what each one confines, what the default is, or how to select one. That is the single largest documentation gap in the material, because sandbox choice determines whether an agent's browser automation and shell-adjacent tools can touch the host. Treat the three names as a prompt to read the code, not as a guarantee. The desktop installers carry their own friction, all of it documented. The macOS build is not Apple-notarized, so first launch requires right-clicking Sage.app in Applications and choosing Open, or going through System Settings, Privacy & Security, Open Anyway. If macOS reports the app as damaged, the README gives the fix: xattr -dr com.apple.quarantine /Applications/Sage.app. Windows users will meet SmartScreen and need More info, then Run anyway. The Linux path is a plain sudo apt install ./Sage-<version>-<arch>.deb. None of this is unusual for an unsigned open source desktop build, but it does mean the desktop route is not a zero-friction download for a non-technical colleague. The Chrome extension is loaded unpacked from app/chrome-extension/ via chrome://extensions/ in Developer mode, and the README notes you may need to point it at a non-default backend port.
Where Sage Is the Wrong Choice
The breadth is the cost. If you want an agent loop inside an existing Python service, Sage hands you a product layer you did not ask for: account authentication, configurable CORS, a shared service architecture, a Vite frontend, a Tauri-style desktop packaging path and a Chrome extension. Every one of those is a surface that can break on upgrade. A library that only exposes the AgentFlow runtime would be a smaller dependency, and Sage is not that. The second limitation is operational. IM delivery through WeChat Personal (iLink), WeCom, Feishu and DingTalk means credentials and, in some cases, account-level integrations that are not yours to configure casually. The README lists the channels as a feature; it does not discuss rate limits, message-size ceilings, attachment type restrictions or what happens when a channel token expires mid-run. Those are the failure modes that will page someone at 2am, and the material is silent on all of them. Third, the release cadence visible in the repository is concentrated in the desktop line, with desktop-v1.1.6, v1.1.7 and v1.1.8 all published on 2026-05-26. Three desktop releases in one day suggests rapid iteration on packaging rather than a settled surface. If you pin to a desktop build, expect to re-verify your install path often.
How Sage Differs From LangGraph and CrewAI
The closest comparisons are LangGraph and CrewAI, and the difference is architectural rather than qualitative. LangGraph models an agent system as a graph of nodes and edges, and leaves the runtime, the UI and the delivery layer to you. CrewAI models it as a crew of role-playing agents with tasks, and likewise stops at the Python boundary. Sage inverts the emphasis: the agent core is one layer among several, and the repository's weight sits in the App Service Layer, the workbench and the client surfaces. If your requirement is a graph you can reason about and embed, LangGraph gives you that with fewer moving parts. If your requirement is a scheduled job that collects answers and posts a file to a Feishu group with a progress view a manager can open, Sage is aimed at exactly that and the graph libraries are not. The honest framing is that Sage is closer to a self-hosted product than to a framework, and it should be evaluated with product criteria: install reliability, upgrade path, credential handling, and whether the workbench covers the file types your team actually produces.
Maintenance, Licensing and What to Pin
Sage is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive starting point, but it says nothing about the third-party model providers, IM platforms or MCP servers you connect, each of which carries its own terms. This is not legal advice; if you are deploying inside a regulated environment, the IM channel integrations in particular deserve a review of their own terms. On maintenance, the repository is not archived and was last pushed on 2026-09-09, with the most recent tagged releases being desktop-v1.1.8 and its two immediate predecessors from 2026-05-26. The README badge claims Version 1.1.0, which does not match the desktop-v1.1.8 tag, so treat the badge as decorative and pin to a specific tag or commit. The upgrade cost is concentrated in whichever surface you deploy. A CLI-only user upgrades by reinstalling the package and re-running sage doctor. A web deployment upgrades through ./scripts/dev-up.sh and has to reconcile the Minimal versus Full stack choice, plus any schema changes in the SQLite or full database. A desktop deployment upgrades by installer and re-clears quarantine on macOS. Pick one surface, pin it, and treat the others as separate products with separate upgrade calendars.
Editorial conclusion
Adopt Sage if you need agent runs that end in delivered messages or files across WeChat, WeCom, Feishu or DingTalk, and you are willing to run the backend yourself. Skip it if you want a single-purpose library to embed in an existing Python service, because the multi-surface product layer is the bulk of what you would be pulling in. Before committing, verify one thing on your own hardware: that the sandbox mode you intend to use (local, passthrough or remote) actually isolates the tools your agents will call, since the README lists the three options without describing what each one confines.
Community notes