AgentManager

What It Does

AgentManager (agentmgr) is a cross-platform CLI and TUI application written in Go that acts as a package manager for AI coding agent CLIs. Instead of manually tracking which coding agents are installed, what version they are, and how to update them via npm, pip, brew, or native installers, agentmgr centralises detection, installation, and update operations across a catalog of 32+ agents including Claude Code, Aider, Amp, Gemini CLI, OpenCode, GitHub Copilot CLI, Goose, and more.

The tool provides both a terminal table view (agentmgr agent list) and an interactive Bubble Tea TUI (agentmgr tui). It supports multiple installation methods per agent (npm, pip, pipx, uv, Homebrew, binary, native), a detection plugin system for custom agents, a background systray helper for passive update notifications, and optional REST and gRPC APIs for programmatic integration. It is a solo-author open-source project under MIT license, at v1.0.24 as of March 2026.

Key Features

• Multi-agent detection: Automatically discovers all installed AI coding agents by probing npm, pip, Homebrew, native binary paths, and package registries
• Catalog of 32+ agents: Maintained catalog.json maps each agent to its installation methods, detection logic, latest version source, and metadata; refreshable from remote
• Version tracking: Compares installed version against latest from npm, PyPI, Homebrew, or GitHub Releases; shows update-available status per agent
• Install and update commands: agentmgr agent install <name> and agentmgr agent update --all unify installation across package managers
• Interactive TUI: Full-screen Bubble Tea interface for browsing and managing agents without memorising commands
• Detection caching: Results cached for 1 hour by default to avoid repeated slow package manager queries; --refresh flag forces re-detection
• Detection plugin system: Custom YAML/JSON plugin definitions allow teams to add proprietary or internal agents to the catalog
• Background systray helper: Separate agentmgr-helper binary monitors for updates and shows OS notifications
• REST and gRPC APIs: Expose catalog and detection data via HTTP or gRPC for integration into CI dashboards or IDE plugins
• Cross-platform: Tested on macOS, Linux, and Windows (CI validates all three)
• Go library: Public packages (pkg/detector, pkg/catalog, pkg/installer) usable as a library in other Go programs

Use Cases

• Individual developer: Quickly see all installed coding agents and their versions in one place, without running npm list -g, pip list, brew list separately
• Team standardisation: Use agentmgr catalog list to see what agents exist, then agentmgr agent install to onboard teammates to a consistent toolset
• Internal tooling/CI: Use the Go library or REST API to incorporate agent version data into onboarding scripts, compliance dashboards, or IDE plugins
• Agent catalog discovery: Browse the catalog to discover lesser-known agents (Droid, Plandex, Dexter, Tokscale) without manual research

Adoption Level Analysis

Small teams (<20 engineers): Reasonable fit for teams where multiple engineers use different AI coding agents and want consistency. The zero-cost MIT tool saves per-developer time on manual version management. Homebrew and go install are simple to add to onboarding docs. Main risk is low community size (19 stars, 1 main contributor) meaning the catalog and bug fixes depend heavily on a single maintainer.

Medium orgs (20–200 engineers): Marginal fit today. The detection plugin system and REST/gRPC APIs are positioned for team-scale use, but the project lacks the community validation and enterprise adoption signals expected for org-wide tooling. Using agentmgr as an internal convenience tool for a developer experience team is reasonable; mandating it org-wide is premature. The lack of authentication, audit logging, or fleet management (push updates to many machines) limits its utility at this scale.

Enterprise (200+ engineers): Not recommended. The project is effectively a single-maintainer hobby project with 19 stars. It has no security review, no CVE history, no SLA, and no enterprise support path. Enterprises managing AI coding agent deployments should evaluate whether internal tooling built on the public Go library (pkg/catalog) is more appropriate than adopting agentmgr directly.

Alternatives

Evidence & Sources

• kevinelliott/agentmanager (GitHub, 19 stars)
• AgentManager v1.0.24 Release Notes
• AgentManager CHANGELOG
• Detection Plugin System Documentation

Notes & Caveats

• Single-maintainer risk: As of April 2026, 98 of 100 commits are from kevinelliott. If the author stops maintaining the project, the catalog (which lists available agents and their detection logic) will go stale. A stale catalog means agentmgr agent list shows outdated version data or misses newly released agents.
• Catalog is opinionated: The 32 included agents reflect the author’s selection. Teams using agents not in the catalog must write detection plugins themselves.
• Slow maintenance pace since February 2026: Latest release (v1.0.24) is from February 28, 2026. The 7 open issues at the time of review are all dependency bumps or platform stubs — the project is not dead, but velocity has slowed significantly.
• No security model: The tool executes npm, pip, brew, and native installers on behalf of the user. There is no signature verification, supply chain audit, or sandboxing for catalog entries. Installing an agent via agentmgr agent install carries the same risks as running the underlying package manager command directly.
• Background helper is macOS-first: The systray helper has an open issue for missing stubs on non-darwin platforms, indicating that Windows/Linux support for the background helper is incomplete.
• gRPC/REST APIs are undocumented externally: While the APIs exist (with OpenAPI spec at agentmgr api spec), there are no documented external integration examples or security controls (no auth, no TLS config in the README). Treat them as internal tooling APIs, not production-safe endpoints.
• No multi-machine fleet management: agentmgr manages agents on a single machine. For managing AI toolchain across a developer fleet, you still need an MDM, Ansible, or similar fleet management layer.