AgentX (sxhxliang/agent-studio): an ACP desktop client for multiple coding agents

The gap AgentX fills: one window for several ACP agents

Most people running coding agents end up with a terminal tab per agent, a separate editor, and no shared view of what each agent did. AgentX is aimed at that situation. The README describes it as a cross-platform desktop application that connects to multiple AI agents simultaneously via the Agent Client Protocol (ACP), and lists Codex, Claude, Kimi Code, Qwen, Qoder, OpenCode, Gemini, AugmentCode and Iflow as agents tested against the repository's config.json. It also points at the ACP project's own list of implementing agents, naming AgentPool, Blackbox AI, Docker's cagent, Goose, OpenHands and others. The target user is therefore someone who already has an ACP-speaking agent installed and configured, not someone looking for a model or an inference runtime. AgentX ships no model weights and the README makes no claim that it hosts one.

How the pieces fit: GPUI, Tokio, ACP and Tree-sitter

The architecture visible in the README is a Rust desktop client. The UI layer is GPUI, the GPU-accelerated framework from Zed Industries, with gpui-component supplying widgets. Async work runs on Tokio. Syntax highlighting in the editor comes from Tree-sitter, and agent communication goes through the agent-client-protocol crate. The data flow implied by that stack is: the app spawns or connects to an agent process over ACP, receives a stream of responses including thinking blocks and tool calls, and renders them in the conversation panel while a separate tool call viewer exposes the details of individual executions. Sessions are organised per conversation and persisted automatically, which the README calls auto-save. The dock system is drag-and-drop, so the editor, terminal and conversation panels are not fixed in place. One consequence worth noting: because GPUI is the rendering layer, the app inherits that framework's platform requirements rather than using a web view, which is why the Linux build needs libxcb and libfontconfig.

Building and running AgentX from source

The README gives a short build path. You need Rust 1.83+ with the 2024 edition, plus platform dependencies: the MSVC toolchain on Windows, libxcb, libfontconfig and libssl-dev on Linux, and Xcode command line tools on macOS. From a clone of the repository the commands are cargo run for a debug build and cargo build --release for a release build. For day-to-day work the README suggests RUST_LOG=info cargo run to get logging, cargo test, cargo clippy and cargo fmt. If you prefer binaries, the releases page carries agentx-v{version}-x86_64-windows.zip and agentx-{version}-setup.exe for Windows, agentx-v{version}-x86_64-linux.tar.gz and agentx_{version}_amd64.deb for Linux, and dmg images for Apple Silicon and Intel macOS. The Linux instructions include sudo dpkg -i agentx_0.5.0_amd64.deb and an AppImage path requiring chmod +x. Package managers are listed as coming soon for winget, Homebrew and the AppImage-style installs, so treat those as unavailable today.

Configuration is the weakest documented surface

The quick start tells you to configure your AI agent in Settings then MCP Config, and the supported-agents section says the tested list is based on config.json in the repository. That is the whole of the configuration story in the README. There is no schema, no example config.json contents, no list of accepted keys, and no note on whether the file is read from the repository root, a user config directory or somewhere else. For an application whose entire value depends on launching and talking to external agent processes, that is a real gap: the exact command line, environment variables and protocol handshake for each agent are the parts a new user needs first. The README also links to a user guide at docs/user-guide.md and an architecture document at CLAUDE.md, but the supplied material does not include their contents, so I cannot say whether the missing detail lives there. Verify that before assuming the configuration is undocumented rather than merely documented elsewhere.

Version drift between the README badge and the releases

The README's version badge reads 0.5.0, and its install examples use 0.5.0 filenames such as agentx_0.5.0_amd64.deb. The releases listed for this repository are v0.3.1 from 2026-02-11, v0.3.0 from 2026-02-09 and v0.2.9 from 2026-02-05. The last push to the default branch is dated 2026-06-29. Those three facts do not line up into a clean picture: either the 0.5.0 assets exist on the releases page but were not included in the release list supplied here, or the README was updated ahead of a release that has not shipped under that tag. Either way, the practical instruction is to check the releases page for the exact asset name before running a dpkg or tar command copied from the README, because the filename in the example may not match what is downloadable. This is a documentation hygiene problem, not evidence about code quality.

Licence, maintenance and upgrade cost

The README carries an Apache 2.0 badge linking to a LICENSE file, but the repository metadata supplied here records the licence as unknown. Those two signals conflict, and the difference matters: Apache 2.0 permits commercial use and modification with attribution and notice requirements, while an unlicensed repository grants no rights by default. Do not rely on the badge alone; open the LICENSE file and read it. On maintenance, the cadence visible in the material is roughly one release every few days in early February 2026, then a gap to a branch push in late June 2026, which suggests bursts of activity rather than a steady schedule. Upgrade cost for a desktop binary is low in principle, but the app depends on the ACP crate and on whichever agent binaries you have installed; a protocol change on either side is the failure mode to watch. The README does not state a compatibility policy for ACP versions, so pin the AgentX version you validate against and re-test your agent connections after each upgrade.

When AgentX is the wrong tool, and what to use instead

AgentX assumes an agent already exists and speaks ACP. If your workflow is a single agent invoked from a shell, the app adds a GUI layer without removing the terminal you still need for everything else. If you want an editor-first experience where the agent is a panel inside the editor you already use, an editor extension is a better fit: the difference is architectural, since AgentX is a standalone GPUI application that happens to embed an LSP-enabled editor, rather than an extension loaded into a host editor. If you need a headless agent that runs in CI with no display server, this is not it; the Linux build requires libxcb and libfontconfig precisely because it draws a window. And if you need a supported, versioned configuration contract before you wire it into a team workflow, the README does not yet provide one. The honest comparison is not against another desktop client but against the terminal multiplexer you are already using: AgentX trades a scriptable text interface for a dockable GUI with a tool call viewer, and you should decide whether that trade is worth the extra process to manage.

Editorial conclusion

Adopt AgentX if you already run two or more ACP-compatible agents and want their sessions side by side with an editor and terminal in one window, and you are comfortable building Rust 1.83+ from source when a release binary does not fit your platform. Do not adopt it if you need a stable, documented configuration contract, a published third-party security review, or an agent runtime of its own: it is a client, and the README does not state a licence file or a configuration schema. Before committing, verify the LICENSE file in the repository, open Settings then MCP Config and confirm your agent's ACP command is accepted, and check whether the release assets for your platform match the version you intend to run.

Official sources

1. Issues
2. README
3. Releases
4. sxhxliang/agent-studio on GitHub