Ask Claude Code to "act as a senior backend developer" and you get a marginally different tone, not a different level of output. Agency Agents is built on the bet that the gap between a one-line role prompt and something genuinely useful is process, not personality — each of its 230+ agent definitions bundles a specific workflow, concrete deliverables, and success criteria for one narrow job, rather than asking a general-purpose model to improvise a specialist from a sentence. The project has picked up a striking amount of attention since it grew out of a Reddit thread, and it's now installable across more than a dozen different coding agents, not just Claude Code.
Quick answer: Agency Agents is a free, MIT-licensed library of 230+ markdown persona files — each with a defined workflow, deliverables, and success criteria — that installs into Claude Code, Cursor, Copilot, and a dozen other tools via a desktop app or script. It's worth it for divisions that map to work you do repeatedly; skip the full 230-agent install, since at least one supported tool silently drops agents past ~119. The rest of this piece covers installation, what to verify before trusting it, and where it's genuinely strong.
What's Actually in the Box
Each entry in the roster is a markdown file describing one agent: its area of expertise, a defined workflow it follows, the concrete outputs it's expected to produce, and criteria for what "done well" looks like for that specific job. The roster is organized into divisions — Engineering, Design, Marketing, Sales, Security, Testing, Product, Finance, Game Development, Healthcare, GIS, and more — each with agents scoped to a specific slice of that domain rather than one generalist per department. Engineering alone spans everything from a frontend developer and backend architect down to narrower roles like a database optimizer, an incident response commander, and an embedded firmware engineer.
The pitch, in practice, is the difference between telling a model "write me a database migration" and handing it an agent definition that already encodes how a database optimizer should think about indexing trade-offs, what a finished migration plan should include, and what counts as a red flag before shipping it. Whether that difference is worth a dedicated file per role — versus just writing a good prompt yourself — is really a question of how much repeat use a given task gets in your workflow.
Installing It
There are two paths, and they lead to meaningfully different amounts of manual work:
| Path | What it does |
|---|---|
| Desktop app (macOS, Linux, Windows) | Browses the full roster and installs agents into any supported tool with a click, and keeps them updated automatically |
Scripts (convert.sh + install.sh) | Generates per-tool integration files, then installs interactively — auto-detecting which coding agents you have, letting you pick specific divisions or individual agents rather than all 230+ at once |
The script path is worth using deliberately rather than installing everything: the project's own documentation flags that at least one supported tool's runtime currently caps out around 119 registered agents and silently drops the rest past that limit, so scoping an install to the divisions you actually need (--division engineering,security, for instance) isn't just tidiness — it avoids a real, documented failure mode.
Built for More Than One Agent Harness
What separates this from a typical prompt collection is the multi-tool conversion layer. The same source agent definitions get translated into whatever format a given coding tool expects — native markdown for Claude Code and GitHub Copilot, SKILL.md files for Antigravity and Osaurus, .mdc rules for Cursor, a single consolidated CONVENTIONS.md for Aider, YAML specs for Kimi Code, TOML for Codex — across more than a dozen supported harnesses.
That's a meaningful engineering commitment beyond just writing good prompts: it means the roster isn't locked to whichever tool the author happens to use, and a team standardizing on a house set of agent personas isn't forced to pick one coding assistant to get value from it.
What "Well-Designed" Means Here
The project states its own design philosophy directly rather than leaving it implicit, and it's worth taking at face value because it explains what a contributor is actually supposed to build when adding a new agent: strong personality (real character and voice, not a generic template), clear deliverables (concrete outputs rather than vague guidance), success metrics (measurable standards for what "done" looks like), a proven workflow (a step-by-step process, not improvisation), and a learning-memory element aimed at pattern recognition over repeated use. That fifth point is a stated design goal rather than a mechanism the README documents in technical detail, so it's worth treating as intent rather than a guaranteed feature when evaluating a given agent file.
The project also frames itself explicitly against three alternatives: a one-line "act as a developer" prompt, a flat prompt library with no workflow attached, and a closed AI tool you can't inspect or fork — positioning every agent definition as forkable and adaptable by design, which is the same MIT-licensed openness already covered above.
Benefits of Agency Agents
The value of a persona library shows up less in any single response and more in how consistently a coding agent behaves across repeated tasks. These are the gains a team can reasonably expect when the roster is scoped and read rather than installed blindly.
Process instead of tone
A one-line role prompt mostly changes vocabulary. An agent file that spells out a workflow, the deliverables at the end of it, and the checks that define success gives the model a sequence to follow. For a database migration, that means the agent is already primed to consider indexing trade-offs, rollback steps, and red flags before it writes anything, instead of producing a plausible script and stopping there. The difference matters most on multi-step jobs where skipping a step is the usual failure.
A faster starting point than writing house agents
Writing a good agent definition from scratch takes real time: you have to decide the workflow, the outputs, and what "done" means, then test it. Agency Agents hands you a draft for hundreds of roles. Even when a file doesn't fit your stack, editing an existing structure is quicker than designing one from a blank page, and the contributor template doubles as a checklist for what a complete definition should include.
One roster across many coding tools
Teams rarely use a single assistant. Some developers prefer Cursor, others Claude Code, others Aider. Because the conversion layer translates the same source files into each tool's native format, a team can agree on one set of personas and have them behave the same way regardless of editor. That removes a common source of drift, where each person's private prompts slowly diverge.
Coverage beyond core engineering
Divisions such as Marketing, Sales, Finance, GIS, and Game Development mean non-engineering work can go through the same agent harness. A product team that already uses a coding agent for code review can reuse it for a paid-media audit or a campaign brief without hunting for a separate tool, which keeps the review and approval habits in one place.
Open, forkable definitions
Everything is plain markdown under the MIT License. You can read exactly what an agent is told, change it, and keep the fork in your own repository next to the code it works on. That transparency is the main practical difference from a closed assistant whose instructions you can't inspect, and it makes the library a base to build on rather than a dependency you have to trust.
Agency Agents vs. Other Ways to Specialize an Agent
The README positions the library against three alternatives. Laid side by side, the trade-offs are clearer than the marketing framing suggests:
| Approach | What you get | Maintenance cost | Best for |
|---|---|---|---|
| One-line role prompt ("act as a backend dev") | Tone shift, little process | None | One-off questions |
| Flat prompt library | Reusable wording, no workflow or done-criteria | Low | Teams that mostly need consistent phrasing |
| Agency Agents | Per-role workflow, deliverables, success metrics, converted for 12+ tools | Medium: you still review, scope, and fork | Teams with repeat work that maps to existing divisions |
| House-written agents or skills | Workflow tuned to your stack and standards | Highest: you write and maintain everything | Core, high-volume workflows where defaults don't fit |
The honest read: Agency Agents sits in a useful middle position. It's a faster starting point than writing house agents from scratch, and a much stronger one than a flat prompt list, but the most valuable agents in a mature setup usually end up being forks that encode your own conventions. If you're deciding how much structure a coding agent needs in the first place, our explainer on context engineering covers why the instructions surrounding a model often matter more than the model choice.
Agency Agents Use Cases
The README's own worked examples are a more concrete way to judge the pitch than the feature list, and the roster's divisions point to a few other places where narrow agents earn their keep.
Paid-media account takeover
Inheriting an ad account usually means one person trying to audit tracking, structure, search terms, and creative at once, and missing something. The README's scenario splits that job: a Paid Media Auditor runs a full account assessment, a Tracking & Measurement Specialist verifies conversion tracking is actually accurate, a PPC Campaign Strategist redesigns the account architecture, a Search Query Analyst cleans up wasted spend from search terms, and an Ad Creative Strategist refreshes ad copy and extensions — five narrow roles chained into one takeover process instead of one generalist agent attempting the whole audit.
The outcome is a takeover where each concern gets a dedicated pass with its own deliverable, so a tracking problem doesn't get buried under a creative refresh.
Smart-campus digital twin
The second README example composes a digital twin from seven agents spanning BIM/GIS specialists, drone reality-mapping, web GIS development, and QA validation. It shows the roster reaching into divisions (GIS, Healthcare, Game Development) well outside typical software work. The useful lesson is the hand-off structure: survey data, modelling, the web front end, and validation are separate steps with separate owners, which is how a real project team would split it too.
Database and backend changes
Engineering roles like the database optimizer and backend architect suit work that is easy to get subtly wrong. A migration plan that has to list index changes, expected lock behaviour, and a rollback path benefits from an agent whose definition already demands those items. The developer still reviews the plan, but the review starts from a complete draft instead of a script with the hard parts missing.
Incident response drills
An incident response commander agent gives on-call engineers a structured partner for triage: establishing scope, assigning roles, keeping a timeline, and drafting the post-incident review. Teams most often use this kind of agent in tabletop exercises and post-mortems, where a consistent checklist matters more than speed, before trusting it anywhere near a live outage.
Whether any of these scenarios maps to your own workload is exactly the judgment call this kind of library asks you to make: the value isn't in any single agent, it's in whether a chained sequence of them matches a process you actually run.
Common Agency Agents Mistakes
Most disappointing experiences with a large prompt library come from how it was adopted rather than from the files themselves. These are the patterns worth avoiding.
Installing the full roster by default
Running the installer with every division feels thorough, but it works against you. At least one supported tool, OpenCode, caps out around 119 registered agents and silently drops the rest, so you may not even get the agents you wanted. In tools without a hard limit, hundreds of agents still crowd whatever discovery or activation mechanism the tool uses, making the right one harder to trigger.
Judging agents by their framing
Personality-driven prompts are easy to write persuasively. A file with a vivid voice and confident success metrics can still produce output no better than a plain, carefully written prompt. Teams that skim the persona description and skip the workflow and deliverable sections end up trusting the parts that matter least. Read the process the agent follows and the outputs it promises, not the character it plays.
Treating star count as a quality signal
This repository's star count is unusually high relative to its age and the size of a shell-and-markdown project. Popularity tells you about attention, not about whether a given agent fits your stack. Adopting the library because it looks widely used, without testing a few agents against your own recent work, skips the only evaluation that actually predicts results.
Never forking the agents you keep
The defaults encode someone else's standards. Leaving them untouched means your database agent follows a generic migration checklist instead of your team's rules on naming, locking, or review. The library is MIT-licensed and designed to be forked; not doing so leaves most of its value on the table and lets agent behaviour drift away from how your team actually works.
Agency Agents Best Practices
The underlying idea — that a role prompt gets meaningfully better when it's backed by an explicit workflow and deliverable checklist instead of a one-line persona — is sound, and it's the same principle behind well-scoped Agent Skills generally: narrow, well-specified instructions beat a generic system prompt asked to improvise. Whether a 230-agent library is the right shape for your team depends on how many of those roles actually map to work you do repeatedly. If you're evaluating it today, do this rather than installing everything:
- Read 2-3 agent files closest to your stack before installing anything, and judge the workflow and deliverables, not the framing. If the steps don't match how a good engineer on your team would approach the task, the agent won't either.
- Scope the install to matching divisions (
--division engineering,security) instead of the full 230+. Start with the divisions that cover work you repeat weekly and add more only when a real need appears. - Run a side-by-side test on past work. Pick a task you completed recently, run the relevant agent on it, and compare the result with what your own prompt produced. Keep the agent only if the output is clearly better or more complete.
- Fork and tune the ones you keep so the workflow matches your team's actual standards, not the default. Add your naming conventions, review rules, and definition of done directly to the file.
- Version the agent files with your code. Store your forks in the repository they serve, so changes are reviewed in pull requests and everyone on the team runs the same definitions.
- Chain agents only where the process already has hand-offs. Multi-agent sequences like the paid-media takeover work because each step has a clear output. Don't split a task into five agents if one person would normally do it in one pass.
- Review agent output like a junior colleague's work. A defined workflow reduces skipped steps; it doesn't remove the need for a human to check migrations, security findings, or anything that ships.
Teams building custom Claude Code or multi-agent workflows — whether that means adopting a library like this or writing house-specific agent definitions from scratch — can get hands-on help from Woyce Technologies. For the security side of giving agents more autonomy, see our guide to AI agent security.
FAQ
What is Agency Agents?
Agency Agents is an open-source library of 230+ specialized AI agent persona definitions, covering engineering, design, marketing, security, and more, installable into Claude Code and over a dozen other AI coding tools. Each file describes one narrow role with a workflow, expected deliverables, and success criteria, so the model follows a defined process instead of improvising a specialist from a one-line instruction.
Is Agency Agents free to use?
Yes. It's released under the MIT License and available on GitHub, along with a free desktop app for installing agents into supported tools. MIT licensing means you can fork, modify, and use the agent files commercially. The real cost is the time spent reading, scoping, and tuning the agents you keep, plus the model usage of whichever coding tool runs them.
How is this different from just writing my own custom prompt?
Each agent bundles a defined workflow, concrete deliverable expectations, and success criteria for one specific role, rather than a single-line persona instruction. Whether that's worth using over a well-written custom prompt depends on how often you need that specific role and how closely the packaged workflow matches how your team actually works.
Which AI coding tools does it support?
Claude Code, GitHub Copilot, Cursor, Aider, Windsurf, Gemini CLI, OpenCode, Codex, Kimi Code, Qwen Code, Antigravity, and several others. Each gets agent definitions converted into that tool's native format: markdown for Claude Code and Copilot, .mdc rules for Cursor, a consolidated conventions file for Aider, and TOML or YAML for tools that expect them. One source roster serves every tool your team uses.
Can I install just some of the agents instead of all 230+?
Yes. The install script supports selecting specific divisions or individual agents rather than installing the full roster, for example --division engineering,security. This is also necessary for at least one supported tool that currently has a hard limit on how many agents it can register and silently drops the rest. Scoped installs are easier to review and keep your tool's agent list manageable.
Should I trust an agent library with this many GitHub stars?
Star count is a weak signal on its own. Judge a prompt or agent library by reading the actual definitions and testing them against your real workflow, not by popularity metrics, which can be inflated independent of a project's quality or adoption. A practical test: run two or three agents on a task you've done recently and compare the output with what your own prompt produced.
Is there a desktop app, or do I have to use the command line?
There's a native desktop app for macOS, Linux, and Windows that browses the full roster and installs agents into supported tools with a click, auto-updating after that. On a Mac it's also installable via brew install --cask msitarzewski/agency-agents/agency-agents. The script-based install (convert.sh and install.sh) covers the same ground for anyone who prefers the terminal.
Can I contribute a new agent to the library?
Yes — it accepts pull requests. The project asks contributors to follow a specific template: frontmatter with name, description, and color, an identity and memory section, a core mission, domain-specific critical rules, technical deliverables with real examples, a defined workflow, and success metrics. That same template is a useful checklist for judging how complete any existing agent file actually is.
Conclusion
The problem Agency Agents tries to solve is real: a one-line persona prompt changes a coding agent's tone far more than its output. The library's answer, a markdown file per role with a defined workflow, deliverables, and success criteria, is a sound pattern, and the multi-tool conversion layer means a team isn't locked into one coding assistant to use it.
The caveats matter as much as the idea. Installing all 230+ agents is the wrong default: at least one supported tool silently drops agents past roughly 119, and a bloated roster is harder to review. Persona files are persuasive to read and harder to verify, so the only test that counts is running a few against work you've already done and comparing results. The star count tells you about attention, not quality.
The sensible path is small: pick the two or three divisions that match work you repeat weekly, read those files closely, and fork the ones worth keeping so they encode your team's standards rather than someone else's defaults. If you want help designing agent definitions or multi-agent workflows around your own codebase, our AI agent development team can help you scope it.