Agency Agents: a native installer for the agency-agents persona catalog
Agency Agents is a small, native app for browsing, installing, and tracking the agent personas from msitarzewski/agency-agents across the AI coding tools you actually use.
At a glance
- What is it?
- Agency Agents is a Tauri 2 desktop app that browses the msitarzewski/agency-agents catalog and renders those personas into the file formats eight AI coding tools expect, keeping a local ledger so installs can be reconciled, updated or removed later.
- Who is it for?
- Adopt Agency Agents if you already use more than one AI coding tool and want one place to see which persona files exist where; skip it if you only ever install agents into Claude Code by hand, since the ledger and reconciliation overhead buy you nothing there.
- 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 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: every AI coding tool wants agent files in its own format
The agency-agents repository is a catalog of specialist AI agent personas. The problem is not finding them, it is placing them. Claude Code reads Markdown from one directory, Codex reads TOML from another, Cursor expects .mdc rule files inside the project, and Osaurus expects a SKILL.md under a slugged directory. The same persona has to be rewritten for each target, and once written there is no record of which file came from which source revision.
Agency Agents is aimed at people who use several of those tools at once. The README frames the design plainly: AI tools do not share a package database, so the app keeps the local install database they are missing. That is the whole pitch. It is not an agent runtime, it does not execute anything, and it is not a replacement for the upstream catalog. It is a control surface over files on disk.
If you use exactly one tool and hand-edit a handful of files, the app solves a problem you do not have. The value appears when the number of tools multiplied by the number of personas gets large enough that you can no longer remember what you installed where.
How the install ledger and reconciliation actually work
Every app-managed install is recorded with a source hash, a rendered hash, the tool, the destination, the scope, and a project path where relevant. That record is the mechanism the rest of the app is built on.
Reconciliation re-renders the canonical source and compares bytes against what is on disk. The result is one of five classifications: current, outdated, modified, removed, or foreign. Modified means someone changed the file outside the app. Foreign means the app found a file in a managed location that it never wrote. The Dashboard surfaces what needs attention and the Agents pane can filter down to exactly those entries.
Two details matter for judging this design. First, the comparison is byte-level against a deterministic render, so it only works because the app controls the rendering. The README states that installs go only to renderer-backed targets that have deterministic byte parity with the upstream agency-agents converter. That constraint explains why some tools are missing. Second, the ledger is local. There is no server-side record, which is consistent with the stated position that the app runs no telemetry and requires no account for core use.
The tool registry follows the same single-source idea. Tool knowledge lives in one upstream-owned tools.json shared by the backend and frontend, and installability is derived from whether the app ships a renderer for that tool's format. Adding a tool is editing one JSON entry, provided a renderer exists. Without a renderer, the tool still shows up in the Tools panel as recognized-only and dimmed.
Installing Agency Agents and installing your first persona
The README points to the latest release for platform builds: a signed and notarized .dmg for macOS 13+ on Apple Silicon and Intel, .deb, .rpm or a portable .AppImage for Linux x86_64, and an .exe installer for Windows x64 and ARM64. The Windows installer is not code-signed yet, so SmartScreen requires More info then Run anyway.
On macOS the README also gives a Homebrew route. The tap is trusted before the cask is installed:
brew tap msitarzewski/agency-agents
brew trust --cask msitarzewski/agency-agents/agency-agents
brew install --cask agency-agentsIf you would rather review the source before running a build, the development app is two commands. The README lists Rust stable, Node.js 22+ and npm as prerequisites, plus Xcode Command Line Tools on macOS:
npm install
npm run tauri devThe README documents a fuller sequence for building from source, including npm run check, cargo test --manifest-path src-tauri/Cargo.toml --lib, and npm run build. There is also a Phase C local QA batch invoked as npm run build:phase-c.
Once the app is running, the first real task is a single install. Open the Agents workspace, use the search and the division filters to find a persona, and read the source in the detail panel before committing. Deploy it to one tool. Then look at where the file landed. This is the part worth internalizing early: Claude Code, Codex, Gemini CLI, GitHub Copilot, Qwen Code and Osaurus install at user scope, while Cursor writes .cursor/rules/*.mdc and opencode writes .opencode/agents/*.md inside the project. The README does not document a rollback command, so the removal path is the app's own remove operation plus the backup feature it lists among its install controls.
Where the app stops: unsupported targets, drift, and scope limits
The clearest limitation is the target list. The upstream agency-agents repository contains integrations for Antigravity, Aider, Windsurf, OpenClaw and Kimi, and the README is explicit that those output shapes need additional app work before they should be exposed as first-class installs. They appear in the Tools panel as recognized-only. If your workflow depends on one of those five, this app will detect the tool and refuse to install into it, which is honest but not useful to you.
Drift handling is a detection feature, not a merge feature. Reconciliation classifies a hand-edited file as modified. The README does not describe a three-way merge or a way to fold your edits back into the canonical source, so a modified file is something to look at, not something the app resolves for you.
Scope is the other constraint. Cursor and opencode installs are project-scoped, so the ledger entry carries a project path. That means a persona installed for one repository is not visible to another, and the Projects panel exists precisely because project installs are a separate category from user installs. Teams, described as replacing the earlier Loadouts concept, are the mechanism for deploying a named group at once.
Finally, the auto-update path is narrower than the app itself. The README states that auto-update checks a signed manifest, verifies against an embedded key, and installs in place with one-click install and relaunch, and that this is live for macOS as of v0.2.0, opt-in and gated by Settings. Linux and Windows users should expect to fetch new builds manually.
How it compares with cloning the catalog and running the converter yourself
The obvious alternative is the upstream agency-agents repository plus its converter, driven from a shell or a script. That approach keeps everything in version control and works on any machine with the right runtime. It also has no GUI, no ledger, and no reconciliation, so answering the question of which persona revision produced a given file means re-running the converter and diffing by hand.
Agency Agents trades that for a Tauri 2 and Svelte 5 desktop shell. The README describes a cross-platform shell with native macOS chrome and opaque native windows on Windows and Linux. The app also ships a bundled corpus baseline for offline-first catalog browsing and can point at a local or managed clone of agency-agents instead.
The trade is real in both directions. Scripts are reproducible and reviewable in a pull request. The app is faster to operate and remembers what it did, but its state lives in a local ledger rather than in your repository, and the README does not document an export of that ledger. The Agentfile export and import that survives from the Loadouts era covers teams, not install history. If auditability of every installed file matters more than convenience, the scripted path is the better fit.
Licence, maintenance and the cost of keeping up
The project is MIT-licensed and the README states it is full source, local-first, and runs no telemetry. For most teams that removes the procurement conversation entirely. The practical licence question is not the app but the personas it installs: those come from the upstream agency-agents catalog, which is a separate repository with its own terms, and the app does not change that relationship. Nothing here is legal advice; check the upstream repository's licence before redistributing rendered persona files.
The last push to the repository was on 2026-09-16, and v0.3.1 was released the same day, after v0.3.0 in July 2026 and v0.2.1 in June 2026. The repository is not archived. Three releases across roughly three months is a steady cadence for a project this size, and the version in package.json matches the v0.3.1 tag.
The upgrade cost is concentrated in two places. The tool registry is a single tools.json shared by backend and frontend, so a tool that changes its agent format upstream requires a renderer change in the app rather than a config edit on your side. And the byte-parity requirement means a renderer that drifts from the upstream converter will reclassify your installed files as outdated on the next reconciliation pass. Expect to re-run reconciliation after every app upgrade rather than assuming installed files stay current.
Editorial conclusion
Adopt Agency Agents if you already use more than one AI coding tool and want one place to see which persona files exist where; skip it if you only ever install agents into Claude Code by hand, since the ledger and reconciliation overhead buy you nothing there. Before trusting it with a working setup, confirm that your tool appears in the renderer-backed target table in the README rather than as a recognized-only entry, and check whether your tool is user-scoped or project-scoped, because Cursor and opencode install into the repository while the others write to your home directory. Then install one persona, edit the rendered file by hand, and reopen the app to see whether the Dashboard classifies it as modified. That single check tells you whether reconciliation works on your machine before you let it manage a full team.
Frequently asked questions
What is the GitHub repo for msitarzewski/agency-agents?
The upstream catalog lives at github.com/msitarzewski/agency-agents, and the desktop app covered here lives at github.com/msitarzewski/agency-agents-app. The README describes the app as a control surface over that catalog, not a replacement for it.
What are Claude Code Agency agents?
They are the personas from the agency-agents catalog rendered into the format Claude Code reads. Agency Agents installs them at user scope to ~/.claude/agents/*.md.
What is the agent app?
Agency Agents is a native desktop app built with Tauri 2 that browses, installs and tracks agent personas across supported AI coding tools. It is not an agent runtime; it installs personas into other tools and does not execute them.
Community notes