agency-agents: a shell installer, a Markdown roster, and one hard agent ceiling

OpenCode registers about 119 agents and silently drops the rest

One failure mode is documented in enough detail to plan around, and it is the one that matters. OpenCode's runtime currently registers only about 119 agents and silently drops the rest, and the project points at an open upstream issue rather than treating it as its own bug. The consequence is specific: an unrestricted install into OpenCode leaves you with a working setup that is quietly incomplete, with no error to grep for and no warning from the tool. The project's own answer is to install a subset with --division so the selection stays under the ceiling, and the installer is said to warn you when a choice would exceed it. Two cautions sit behind that. The limit belongs to OpenCode, not to this repository, so it can move in either direction, and a ceiling counted in registered agents is a property of the runtime, not a judgement about the quality of any particular agent.

install.sh takes a tool, a division or a named agent, and dry-run is the only preview

The installer's entire interface is a handful of flags, and they compose:

./scripts/install.sh --tool claude-code --division engineering,security
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

Run with no arguments and it opens an interactive wizard to pick tools and teams, while --list teams prints every team with its agent count, which is the first command to reach for when you do not yet know the shape of the roster. The three selection axes are different sizes. --tool picks the destination, --division takes comma-separated groups such as engineering and security, and --agent takes named individuals such as frontend-developer and ui-designer. --dry-run is the only preview on offer. The documentation gives no exit code table, no config file, and no way to persist a selection across machines, so a reproducible setup is a wrapper script you write yourself.

convert.sh generates the integration files, and the order of the two scripts matters

The multi-tool path is a two step sequence, and the first step is the one people skip:

./scripts/convert.sh
./scripts/install.sh
./scripts/install.sh --tool opencode

convert.sh generates integration files for all supported tools, and only after that does install.sh run, interactively, auto-detecting what it finds on the machine. Naming a single tool with --tool skips the wizard but does not replace the conversion step, so the combination to watch is a fresh checkout with generated files missing and a specific --tool value. The documentation also states that the script-based options install the same agents as the desktop app, which is the reassuring half of this: the app and the shell path are two front ends over one roster rather than two rosters. What is not stated is which files the conversion actually rewrites, so a tool added to the list later is worth checking on disk rather than assuming.

The desktop app is a different repository, and this one publishes no releases

The recommended path is a native desktop app for macOS, Linux and Windows, and it is not in this repository. The download link resolves to the releases of a separate project, agency-agents-app, and the app itself is at agencyagents.app. This repository publishes no GitHub releases at all, so the two channels move independently and nothing in the documentation matches an app version to an agent version. The Homebrew cask is a third channel:

brew install --cask msitarzewski/agency-agents/agency-agents

The cask is namespaced under the owner, which matters if you mirror it internally rather than pulling it per machine. The app auto-updates and a clone does not, so a team split across both ends up with divergent rosters unless someone pulls on a schedule. And the app's pitch, browsing the whole roster and installing with a click, is exactly the step you give up when you stay on the command line.

An agent file is four Markdown sections, and none of them is executable

The reference option makes the real shape of the project plain. Each agent file contains identity and personality traits, a core mission and workflows, technical deliverables with code examples, and success metrics and communication style. That is the entire product: prose arranged consistently, which you read, copy or adapt. There is no model call in it, no tool binding, no execution harness, and nothing that measures the success metrics, since those are written as sentences inside the file rather than computed by any part of the repository. The activation example shows the contract, because you ask for a mode inside a session, such as telling Claude to activate Frontend Developer mode and help you build a React component. So the fair description is a library of role prompts with an installer bolted to the front, and the real question is whether the brief in a given file matches your work.

divisions.json and tools.json are the machine-readable spine, and no schema is published

Underneath documentation that is mostly tables, the repository keeps two JSON files at the top level, divisions.json and tools.json, alongside an integrations/ directory, and the shell scripts have to read something to do their work. That is the part of the layout a script author wants and the part the documentation never explains. No field names, no schema, no statement of which file wins when a division name in the prose disagrees with the JSON, and no versioning story for a format the installers depend on. The agent definitions are one Markdown file per agent under a directory named for its division, with the prefix doubled in the path, engineering/engineering-frontend-developer.md. So there are two copies of the same structure, one written for people and one for machines, with no published rule for reconciling them.

Twenty-two directories, and specialisation that varies widely by division

The directory names are the taxonomy: academic, design, engineering, finance, game development, gis, healthcare, marketing, paid media, product, project management, research, sales, security, spatial computing, specialized, strategy, support and testing, plus examples/, integrations/ and scripts/, for twenty-two in total. Engineering is the division expanded in detail, and the granularity there is worth naming as a design decision. Alongside Frontend Developer and Backend Architect sit a Filament Optimization Specialist for restructuring admin forms, an Autonomous Optimization Architect for LLM routing and cost guardrails, an Embedded Firmware Engineer for bare-metal and RTOS work on ESP32, STM32 and Nordic parts, and a Network Engineer who reads Cisco IOS and Juniper Junos show output. The other divisions are not expanded in the visible file, so a reader cannot tell whether security has one agent or twenty, and that asymmetry is precisely what the interactive wizard hides by printing teams with counts.

Editorial conclusion

Treat agency-agents as a prompt library with an installer attached, because that is what the documentation describes: Markdown agent files plus shell scripts that copy them into a tool's configuration directory. It earns a place when you want a starting brief for a role you would otherwise write from scratch. Scope every install with --division or --agent rather than taking the whole roster, because a full copy into OpenCode loses agents without telling you, and decide deliberately between the desktop app and a clone, since the releases sit in agency-agents-app while this repository publishes none. Read SECURITY.md and both contributing guides before you contribute an agent of your own.

Frequently asked questions

Official sources

1. Official README
2. Project repository