Orchestrate multiple AI agents as one team, on your own computer
Watch progress, send instructions, and approve from the GUI; a Supervisor Agent orchestrates the whole team in the background — all your data stays on your machine

Download · Quick Start · Docs · 中文

• What Is Galley
• Highlights
• Quick Start
• Supervisor / Channels
• Architecture
• Under the Hood
• Why "Galley"?
• Screenshots
• Contributing / Building From Source
• Acknowledgments

Galley runs a team of AI agents on your own computer. Each agent actually gets things done — driving your browser, terminal, and files, even your phone; multiple sessions advance in parallel, ready to switch, take over, and resume at any time. You watch progress, send instructions, and approve actions in the GUI; a Supervisor Agent orchestrates the same team through the CLI — two roles, one shared state.

Powered by the bundled engine — a derivative work of GenericAgent, shipped inside the installer, ready on first launch.

Galley's orchestration layer — a human in the GUI and a Supervisor Agent on the CLI, both first-class operators.

Prepare a usable LLM service first: API Key, Base URL, and model name. Claude / ChatGPT / DeepSeek / Kimi / GLM / MiniMax presets are built in, and any OpenAI-compatible endpoint works.

xattr -dr com.apple.quarantine /Applications/Galley.app

In the running GUI, open Settings → Agent:

You don't need to learn the CLI yourself — tell your Supervisor Agent what you want in natural language and let it operate Galley. The copied SOP is a lightweight hot path; detailed commands and advanced orchestration stay in the reference and Agent API.

Work scales to the right container instead of becoming one giant prompt:

• Simple requests — read from or follow a single session;
• Project / folder work — bind a workspace with Project Workspace and run sessions in parallel;
• Long-term goals — use Goal to set duration and Subagent budget first, then let it run in the background.

You can also connect WeChat / Feishu from Settings → Channels to assign work and dispatch Galley Desktop through chat apps.

# What's running right now?
galley status
galley sessions list

# Start a new session to follow up on a PR
galley session new --project=proj_work \
  --supervisor=ga-claude-1 --reason="follow up on PR review" \
  "look at the feedback on #1234"

# Complex goal: use one Project to hold a group of sessions
galley project create "Release readiness review" \
  --supervisor=ga-claude-1 --reason="parallel release-risk review"

galley session new "Read-only check of app identity, data directory, SQLite migrations, and backup risks. Output risks with evidence." \
  --project=proj_from_create --supervisor=ga-claude-1 --reason="check data safety"

galley session new "Read-only check of packaging, release workflow, bundled resources, and version bumps. Output a release blocker checklist." \
  --project=proj_from_create --supervisor=ga-claude-1 --reason="check release packaging"

galley project follow proj_from_create --tail=80 --until-idle --final-show

# Long-term goal: create a proposal first, then start the Goal controller after explicit confirmation
galley goal propose "ship the next patch release" \
  --supervisor=ga-claude-1 --reason="prepare Goal plan and wait for user confirmation"

galley goal run --proposal=<proposal-id> \
  --confirm-token=<internalConfirmToken> \
  --supervisor=ga-claude-1 --reason="user confirmed Goal start"

galley goal status <goal-id>
galley goal deliverable get <goal-id>

# Watch one session's event stream
galley session watch <id>

# Switch model / archive / restart
galley llm set <id> "another model name"
galley session archive <id> --supervisor=ga-claude-1 --reason="done"

The GUI and the CLI are peer frontends — not a GUI wrapping a CLI, but two equals each talking directly to the same Rust Core. Core is the single authority, owning session / Project / Goal state, SQLite writes, and runner lifecycle; by default it runs the bundled engine, ready out of the box.

+----------------+                  +----------------+
|   Galley GUI   |---+          +---|   Galley CLI   |
|  Tauri/React   |   |          |   |      Rust      |
+----------------+   |          |   +----------------+
                     v          v
              +------------------------+        localhost only
              |      Galley Core       | <----  unix socket / named pipe
              |          Rust          |        0600 / no token / no TLS
              |  - session lifecycle   |
              |  - projects + goals    |
              |  - SQLite authority    |
              |  - runner + events     |
              +-----------+------------+
                          |
             +------------+------------+
             v                         v
       +------------+             +------------+
       | Runner #1  |     ...     | Runner #N  |        one per session
       |  Python    |             |  Python    |
       +-----+------+             +------+-----+
             |                           |
             +------------+--------------+
                          v
              +------------------------+
              |   Galley-managed GA    |
              | - GenericAgent kernel  |
              | - Galley prompt profile|
              | - bundled CPython 3.11 |
              | - bundled dependencies |
              +------------------------+

Tech stack: Tauri v2 + React 19 + TypeScript 5.8 + Tailwind v4 / Rust (Galley Core + Galley CLI) / Python (runner, wraps GenericAgent) / SQLite + FTS5 trigram

More docs: Architecture · Contributing · Docs index

A few design choices that aren't in the feature list but shape Galley's engineering quality:

• Peer frontends, not a GUI wrapping a CLI. The GUI and CLI each connect to the Rust Core independently. If either side exits, sessions and data are unaffected; a new frontend (an IM channel, a future Web client) only needs to speak the same Core protocol — no orchestration logic to rewrite.

• The Rust Core is the single authority. The state machines for sessions / Projects / Goals, SQLite writes, and runner lifecycle all converge in one place. Frontends read projections and send intents; they hold no writable state, which removes multi-end state drift at the root.

• A local-first security model. Inter-process traffic runs over a Unix socket / named pipe with 0600 permissions, localhost only, no token, no TLS — because the trust boundary is "the same user on the same machine." Not forcing network-style auth onto a local tool is a deliberate subtraction.

• The Agent API is a frozen public contract. CLI output carries a schemaVersion, frozen within 0.2.x; every command carries an origin triple (via / supervisor / reason), and the GUI timeline reconstructs who changed a session, why, and when. A Supervisor can program against it with confidence.

• Discipline at the dual-runtime boundary. The default is the bundled engine (CPython 3.11 and dependencies included, ready out of the box); when attaching an external GenericAgent, Galley stays strictly read-only — it never touches the external GA's code, memory, SOP, or mykey.py, so your existing environment stays clean.

• A persistence layer built to evolve. SQLite is the authoritative store, with ordered migrations that make upgrades replayable; past sessions are indexed with FTS5 trigram so even Chinese substrings are searchable, staying resident in the background and instantly searchable when you return.

A ship's galley is both kitchen and workbench. Everyone comes there for a different reason, but the table is the same table.

Galley is that shared table: humans drive work from the GUI, while Supervisor Agents manage the team through the CLI. Both share the same sessions, history, and decision log instead of living in separate tabs.

Galley started as a workbench for GenericAgent. The first two letters of our name are a quiet bow to where we came from.

Project view — sessions advancing around one project	⌘K — every past conversation is full-text searchable
The workspace at rest — background work keeps moving	Dark theme — the same desk at night

git clone https://github.com/wangjc683/galley
cd galley

# Python runner tests
python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"
.venv/bin/python -m pytest          # unit tests
GA_PATH=/path/to/GenericAgent BRIDGE_PYTHON=/path/to/python .venv/bin/python -m pytest -m e2e

# Desktop app development / build
cd gui
pnpm install
pnpm tauri dev                       # macOS / Windows desktop dev mode
pnpm tauri build                     # produces .app / .dmg / .exe

# Galley CLI standalone build
cd ../core
cargo build --release -p galley-cli  # produces target/release/galley

See docs/release-update-sop.md for the CI release flow (background and troubleshooting) and docs/windows-build-checklist.md for manual Windows builds.

Galley's engine is a derivative work of lsdefine/GenericAgent — a minimal, self-evolving agent framework grown from ~3K lines of seed code. Galley would not exist without that clean foundation.

Paper: GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization (arXiv:2604.17091)

MIT