Open Agency is a roster of agent persona files you copy into Claude Code

A directory of documents, not a package

Open Agency is described as an open-source AI workforce featuring specialized agents for development, growth, research, strategy and creativity, each designed to deliver practical results through focused expertise and structured workflows.

What that turns out to be, concretely, is a set of markdown files in themed directories. The top level of the repository is `design/`, `engineering/`, `marketing/`, `product/`, `project-management/`, `spatial-computing/`, `specialized/`, `strategy/`, `support/` and `testing/`, plus `README.md`, `CONTRIBUTING.md`, `LICENSE` and a `.gitignore`. There is no `src/` directory, no package manifest and no build step.

That is not a criticism, it is the design, but it changes what evaluating the project means. There is nothing to install, nothing to run and nothing to break. The only questions are whether the content is any good and whether it fits how you work.

The repository metadata reflects that nature. The primary language is recorded as unknown, there are no GitHub releases, and the last push was on 2026-06-07. The licence is MIT.

The README's framing is worth quoting once, because it explains the intent: think of it as assembling your dream team, except they are AI specialists who never sleep, never complain and always deliver. That is marketing language, and the practical test of it is whether a given file actually changes what the model produces for your codebase.

The README also says the project was inspired by a simple discussion and refined through months of iteration, and that it has evolved into a growing ecosystem of carefully designed AI agent personas. So it is a community-written collection, and the strength of any individual file depends on who wrote it.

The install is a copy command

The quick start gives two options, and the first is the recommended one.

For use with Claude Code:

# Copy agents to your Claude Code directory
cp -r agency-agents/* ~/.claude/agents/

# Now activate any agent in your Claude Code sessions:
# "Hey Claude, activate Frontend Developer mode and help me build a React component"

That is the entire installation. You copy the directory into your Claude Code agents folder, and then you refer to an agent by name in a session, as the comment shows.

The second option is to use the files as reference. The README lists what each agent file contains, and that list is the most useful description of the format in the whole document: identity and personality traits, core mission and workflows, technical deliverables with code examples, and success metrics and communication style.

So each file is a small system prompt with a fixed structure. The personality section sets voice and thinking style, the mission and workflows section sets what the agent does and in what order, the deliverables section shows what output looks like with examples, and the metrics section says what good looks like and how the agent should report.

That structure is the project's real contribution, more than the individual personas. Whether a file is useful depends on whether its sections are filled in with something specific to a domain rather than with general advice, and the README claims exactly that: deep expertise in their domain, not generic prompt templates.

The copy instruction also has an implication. Once the files are in your own directory they are yours, and the README's second option explicitly says to browse the agents and copy or adapt the ones you need. So the realistic workflow is to copy the whole set, then delete most of it and edit what remains.

The roster, division by division

The README organises the agents as an agency with divisions, and the table format is consistent: agent, specialty, and when to use.

The engineering division has seven entries, one per specialisation rather than per seniority. Frontend Developer covers React, Vue and Angular, UI implementation and performance. Backend Architect covers API design, database architecture and scalability. Mobile App Builder covers iOS and Android, React Native and Flutter. AI Engineer covers ML models, deployment and AI integration. DevOps Automator covers CI/CD, infrastructure automation and cloud operations. Rapid Prototyper is for proofs of concept and MVPs, and Senior Developer is aimed at Laravel and Livewire with advanced patterns.

The design division is also seven. UI Designer for visual design, component libraries and design systems. UX Researcher for user testing and behaviour analysis. UX Architect for technical architecture and CSS systems. Brand Guardian for brand identity, consistency and positioning. Visual Storyteller for visual narratives and multimedia content. Whimsy Injector for personality, delight and playful interactions. Image Prompt Engineer for AI image generation prompts.

Marketing is the longest division with eight, running from Growth Hacker and Content Creator through Twitter Engager, TikTok Strategist, Instagram Curator, Reddit Community Builder and App Store Optimizer to Social Media Strategist.

Product has only three: Sprint Prioritizer, Trend Researcher and Feedback Synthesizer.

That unevenness is informative. The marketing and design rosters are where the author invested, and product management, which is where an agent is hardest to write usefully, has three. The remaining top level directories, project-management, spatial-computing, specialized, strategy, support and testing, are not shown in the visible part of the README, so their contents are best seen by browsing the repository.

One thing the roster does not include is a testing division with entries, despite the `testing/` directory existing at the top level, which is a hint that the README and the tree are not perfectly in step.

What the README claims, and what you can check

Four claims define the project, and each can be tested against the files.

The first is domain specialists, deep expertise in their domain, not generic prompt templates. The test is whether a file contains specifics a generic assistant would not produce, such as naming a framework's conventions, a failure mode to watch for, or a concrete deliverable format.

The second is personality-driven, with a distinct voice, thinking style and way of communicating. The test is whether two agents in the same division would visibly behave differently.

The third is outcome-oriented, built to produce real deliverables, code, workflows and measurable results. The test is whether the deliverables section names artifacts rather than advice.

The fourth is production-ready, with battle-tested workflows and success metrics. This is the claim that needs the most scrutiny, and the README gives no way to check it: there is no statement of how the workflows were tested, by whom, or against what. The repository is a set of documents with no tests of its own, no releases and no recorded primary language, so "battle-tested" is a claim you can only evaluate by reading the file and trying it.

That is not a reason to skip it, but it is a reason to treat it as a starting point rather than a reference implementation. The honest summary is that this repository offers breadth and a consistent format, and its quality is uneven because it is community content.

The project metadata also puts a timeframe on it. The last push was on 2026-06-07, so the content is from mid 2026 and the agent ecosystem it targets moves quickly.

When writing your own prompt is the better answer

The alternative to a roster like this is not nothing, it is the file you write yourself, and for many projects that file will be better.

A prompt written for your repository can name your directory layout, your build command, your test conventions, the framework versions you use and the specific thing that went wrong last time. A shared persona file cannot, because it has to be generic enough to be useful to more than one person. So for an agent that operates on your code, which is most of the valuable ones, the shared file is a starting draft and your own version is the destination.

Where a shared roster does win is on the parts that are genuinely cross-project. A content calendar, a brand voice, an App Store optimisation checklist or a design system review do not depend on your codebase, and a person who has thought about them has already done the structuring work. Copying one of those and editing it takes minutes, and that is a good deal.

The other alternative is a maintained framework of agent definitions with tooling around it, where the definitions are tested against models and are versioned with the runtime. The difference in approach is between a content repository and a product: this repository gives you prose that a model will read, with no mechanism to check that the prose still produces the behaviour its author saw.

The practical workflow that follows from all this is simple. Read the roster, pick the one or two files that match a recurring task, copy them, delete the rest, and edit what you copied until it reflects how your team works. Version the result with your project, because the value is in the adaptation and the adaptation is yours.

Editorial conclusion

Adopt Open Agency when you want a starting point for a specific role prompt rather than a blank page, and when the workflow in the file is close enough to your project to be worth adapting. Do not adopt it as a system you can run, because nothing here is executable and the repository has no releases and no recorded primary language, which is what a collection of documents looks like. Verify first that the agent file you want matches how your team actually works, since the README claims battle-tested workflows and success metrics without saying how they were established, that the division structure covers the roles you need, since the marketing and design rosters are considerably longer than the product one, and that you keep the file under version control after copying, because you will edit it.

Frequently asked questions

Official sources

1. Anas-Khan93/ai-agency-agents on GitHub
2. Issues
3. License: MIT
4. README