Eigent packages a multi agent workforce into an Electron desktop app

Two ways to run it, and the README recommends the harder one

The getting started section offers two paths and puts the recommended one first, which is unusual and worth noting. Local deployment is described as fully standalone with complete control over your data and no cloud account required. The quick start cloud connected path is for a preview and connects to Eigent cloud services with account registration.

The quick start is four commands and needs Node.js version 18-22 with npm:

git clone https://github.com/eigent-ai/eigent.git
cd eigent
npm install
npm run dev

The local path points at a separate document, `server/README_EN.md`, and the README lists what that setup includes: a local backend server with full API, local model integration through vLLM, Ollama or LM Studio, complete isolation from cloud services and zero external dependencies.

Recommending the local path while shipping the cloud path first is a coherent choice rather than a contradiction. This is a desktop agent application, and a desktop agent application that phones home on first launch is a different product from one that does not. The distinction matters more for agents than for most software, because agents have file system and terminal access.

There is a third path for organisations, an enterprise offering with SSO, access control, scalable deployment and negotiated SLAs, which the README routes to a sales contact form rather than documenting.

The package.json is a map of the awkward parts

Reading `package.json` tells you more about this codebase than the feature list does. The entry point is `dist-electron/main/index.js`, the package is marked private and the type is module, so this is an Electron main process written as ES modules with Vite doing the bundling.

Then there is the cluster of fix scripts, which is where the real signal is. `postinstall` runs `node scripts/fix-node-pty-permissions.js`, which is a direct consequence of bundling a native module: node-pty gives an agent a terminal, and a terminal means a native addon that needs correct permissions after install. `preinstall-deps.js`, `compile-babel.js`, `fix-venv-paths.js` and `fix-symlinks.js` all run in the `prebuild:deps` chain, and the presence of `fix-venv-paths` tells you the backend is a Python environment that has to be relocated into the packaged app.

The build chain is layered. `prebuild:compile` runs `tsc -p tsconfig.build.json && vite build`. `build` runs the full prebuild chain and then `electron-builder --publish never`. There are per platform variants for mac, Windows and Linux, plus `build:publish` which switches electron-builder to `--publish always`.

That two tier structure, `build:win` and `build:linux` against `build:mac`, is not stylistic. The mac path has its own `test-signing.js` step and the repository carries `entitlements.mac.plist`, because macOS notarisation and the Windows build path have different requirements. A project with three Electron targets and a Python backend has more build surface than the marketing copy suggests.

What the tree says about a TypeScript shell around a Python backend

The top level has forty-nine entries and several of them are worth pausing on. There is `backend/`, which is the Python side the scripts were fixing virtualenv paths for. There is `server/`, which holds the local deployment guide the README points to and is therefore the deployment path, kept distinct from the backend code itself.

There is also `electron/`, `src/`, `package/` and `build/`, four separate directories that a reader would struggle to distinguish from names alone. `src/` is the renderer, `electron/` the main and preload processes, and the other two are packaging inputs rather than application code. An `index.html` at the root plus `vite.config.ts` and `vite.config.web.ts` confirm a Vite setup with a separate web target, which matches the `dev:web` script that runs `vite --config vite.config.web.ts`.

The tooling configuration is thorough and mostly invisible in normal use: `.husky/` for git hooks, `.lintstagedrc.json` with `.prettierrc.json` and `.markdownlint.json` for formatting, `eslint.config.js` for linting, `vitest.config.ts` for tests, `.storybook/` for component development and `components.json`, which is the shadcn configuration file.

Two more entries tell you how seriously this is packaged. `electron-builder.json` holds the desktop build configuration and `licenses/` is a directory rather than a single file, which is how electron-builder handles third party license attribution. `AGENTS.md` at the root is a file written for coding agents working in this repository, which tells you something about who is expected to contribute.

Skills, Connectors and Spaces are the vocabulary

The README lists features in marketing terms, but the release notes use the terms you will actually meet in the product. Two of them are resource types: Skills and Connectors. A third is the container, called a Space.

Version 1.0.4, released 2026-09-04, is the release that made these first class objects. It introduces a redesigned way to manage Skills and Connectors: a library style dashboard with dedicated detail views, the ability to inspect source and access details, enable or disable Skills and review their files from one place, and a clearer collection, discovery and detail flow for Connectors. It also brings shared layouts, breadcrumbs, sidebars and content rails across Home, Skills and Connectors, which is what happens when three screens need to feel like one application.

Version 1.0.3, released 2026-08-28, is where Space becomes durable. It adds Git backed Spaces, automatically initialising version history for Eigent managed Spaces, reusing an existing repository when a selected folder already has one, and letting you review task scoped file changes, diffs, checkpoints, branches and version history. It also makes Tasks recoverable: resume an interrupted Task after refreshing or restarting, preserve completed work without automatically repeating external actions, and keep Task history, elapsed time, approvals and recovery state across sessions.

The phrase worth sitting with is without automatically repeating external actions. An agent that sends an email or calls an API is not idempotent, so resuming a task has to distinguish replaying local file edits, which is safe, from replaying side effects, which is not. Getting that distinction right is the difference between a resumable agent and a dangerous one.

Model agnostic in the README, concrete in the release notes

The README claims model agnosticism in a single sentence: connect the models you already use, whether cloud APIs, enterprise gateways or local inference, without locking into one vendor. The specific vocabulary is vLLM, Ollama and LM Studio in the local deployment section, and the feature list names model agnostic, MCP integration, skill integration, and built in browser and terminal toolkits.

The release notes are where this stops being a claim. Version 1.0.2 added Connector Gateway UI and MCP wiring, typed workflow event infrastructure for app level workflow events, and support for BYOK model parameters. BYOK in a release bullet alongside a gateway UI says the model configuration is a settings surface with real parameters, not a single API key field.

Version 1.0.2 is also a list of small desktop problems worth having solved: clipboard image paste in the chat box, improved generated file cards and sandbox path handling, an improved update UX and log download flow, and a fix that prevented project switches from killing live runs.

Underneath all of this is CAMEL-AI, the open source project the README credits as its foundation. That relationship shapes what Eigent is: a desktop application, workflow runtime and distribution story layered on an agent framework rather than a new agent framework. The repository topics reflect the same framing, listing agent framework, agent skills, agentic ai, agentic workflow, desktop agent and multi agent systems.

Open source, with one licensing wrinkle to check

The repository is marked Apache-2.0 and the README has a section on the open source license, along with a build in public statement about every feature, commit and decision being transparent. There are four README translations in the tree, `README_CN.md`, `README_JA.md` and `README_PT-BR.md` alongside the English one, plus `CONTRIBUTING.md` and `SECURITY.md`.

Here is the wrinkle. The `package.json` in the repository records `"license": "MIT"` and `"private": true`. The repository level licence is Apache-2.0 while the package manifest says MIT, and the package is flagged private, meaning it is not published to npm at all. If you are vendoring or redistributing code you would want to resolve which of those two licences governs the parts you take, and the `LICENSE` file and `licenses/` directory are where to start.

The activity numbers suggest a project with real momentum rather than a hobby: 15334 stars, 1829 forks and 235 open issues, with the last recorded push on 2026-09-20. The three recorded releases are v1.0.2 on 2026-07-21, v1.0.3 on 2026-08-28 and v1.0.4 on 2026-09-04, so the version has moved past 1.0 without a 2.0, which reads like a team that treats 1.x as a commitment to a stable shell while continuing to ship features behind it.

Editorial conclusion

Eigent is a packaging and ergonomics project more than a research one. The interesting engineering is not in a new agent algorithm, it is in making long running agent work survive a refresh, in giving every Space a git history so you can diff what an agent did, and in the unglamorous scripts that keep node-pty permissions, Python virtualenv paths and macOS entitlements correct across three platforms. If you want to evaluate it, run the cloud connected quick start first because it is four commands, then read `server/README_EN.md` before committing to the local deployment path. If you want to extend it, the backend is Python and the frontend is TypeScript against Vite, and `AGENTS.md` in the repository root is the file to read first.

Frequently asked questions

Official sources

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