51 Agent System Prompts: What Every's Compound Engineering Architecture Teaches Us

Prompt engineering advice usually focuses on how to write a single good prompt. But for production AI agent systems, the challenge isn’t writing one prompt — it’s designing a system of prompts that work together, cover every edge case, and get smarter over time.

Every Inc’s Compound Engineering Plugin, with 17.7k GitHub stars and an MIT license, offers a rare window into a production-grade agent prompt architecture. Its plugins/compound-engineering/agents/ directory contains 51 markdown files, each defining a specialized agent with a carefully crafted system prompt.

Here’s what their architecture looks like and what agent builders can learn from it.

The 51-Agent Taxonomy

The agents fall into five functional layers:

Layer	Count	Role
Reviewers	23	Code and document review from specialized perspectives
Researchers	7	Context gathering from codebase, web, Slack, and history
Architecture & Strategy	2	High-level design and pattern analysis
Security & Integrity	2	Security audit and data integrity verification
Performance & Observability	4	Performance analysis and system monitoring
Other	3	Deployment verification, PR comment resolution, documentation

Each agent is a single .md file containing a system prompt — no code, no configuration, just structured instructions.

Note: The agents were recently renamed from .agent.md to .md to enable VS Code Copilot tool access (PR #846 in the repository).

The Reviewer Stack (23 Agents)

The reviewer layer is the most heavily staffed, reflecting the methodology’s emphasis on 80% planning and review, 20% execution EveryInc/compound-engineering-plugin — README. Each reviewer agent has a specialized lens:

Security-focused: ce-security-reviewer, ce-security-lens-reviewer — analyze code for vulnerabilities, injection risks, and auth bypasses. ce-data-integrity-guardian verifies data consistency across migrations and state changes.

Quality-focused: ce-correctness-reviewer, ce-coherence-reviewer, ce-maintainability-reviewer, ce-reliability-reviewer — each examines a different quality dimension.

Domain-specific: ce-performance-reviewer checks for optimization opportunities. ce-testing-reviewer validates test coverage and test quality. ce-swift-ios-reviewer brings iOS-specific knowledge.

Process-focused: ce-scope-guardian-reviewer prevents scope creep. ce-adversarial-reviewer actively tries to break the proposed solution. ce-feasibility-reviewer evaluates whether the approach will actually work.

Design-focused: ce-design-lens-reviewer, ce-design-implementation-reviewer, ce-product-lens-reviewer — evaluate design decisions from user and product perspectives.

This specialization is the key insight: trying to review a PR with a single “review this code” prompt means one agent has to simultaneously think about security, performance, correctness, scope, and user experience. Splitting these into separate agents lets each one focus deeply on its domain.

The Researcher Layer (7 Agents)

Before any code is written, the research agents gather context:

• ce-web-researcher — Scrapes the web for best practices and relevant documentation
• ce-repo-research-analyst — Analyzes the current codebase structure and patterns
• ce-learnings-researcher — Retrieves past learnings from the compound knowledge base
• ce-slack-researcher — Searches Slack for organizational context, decisions, and discussions
• ce-best-practices-researcher — Finds established patterns for the specific problem domain
• ce-framework-docs-researcher — Checks official framework documentation
• ce-issue-intelligence-analyst — Analyzes bug reports and feature requests

The research layer is what makes the “compound” part work. Without it, agents operate on whatever context happens to be in the conversation window. With it, they pull in relevant history, decisions, and expertise automatically.

Architecture & Strategy Agents

ce-architecture-strategist evaluates architectural decisions and trade-offs. ce-pattern-recognition-specialist identifies recurring patterns in the codebase that could be abstracted or improved.

These are higher-level agents that don’t review individual lines of code but look at the overall structure and direction. In a compound engineering workflow, they’re consulted during the planning phase — before any implementation starts.

How They Chain Together

The agents don’t work in isolation. The Compound Engineering skills (/ce-* slash commands) orchestrate them in sequences:

1. /ce-plan — Uses researcher agents (web, repo, learnings) to gather context, then architecture agents to evaluate approaches
2. /ce-work — Executes the plan, calling into implementation agents
3. /ce-code-review — Routes the output through the full reviewer stack in parallel (up to 23 reviewer agents)
4. /ce-compound — Captures learnings from the full cycle

This orchestration is defined in the skill files (plugins/compound-engineering/docs/skills/), each specifying which agents to invoke and in what order. See the Compound Engineering README for the full workflow documentation.

Design Patterns for Agent Builders

1. One file, one agent. Each agent is a standalone .md file. No shared configuration, no inheritance. This makes them independently testable and easy to add or remove.

2. Role-based naming. Every agent file starts with ce- and ends with a role descriptor: -reviewer, -researcher, -strategist, -analyst. The naming makes it immediately clear what each agent does.

3. Specialization over generality. Rather than one powerful “code review” agent, Every uses 23 specialized review agents. Each has a narrow focus and deep expertise in that focus.

4. Plain text, no code. The agents are pure system prompts in markdown. No JSON, no YAML configuration, no code wrappers. This makes them accessible to anyone who can write clear instructions.

5. Parallel by design. The review pipeline runs agents in parallel, not sequentially. This is critical for keeping the workflow fast despite the large number of agents. For a broader look at multi-agent architecture patterns, see Designing Effective Multi-Agent Architectures on O’Reilly Radar.

Key Takeaways for Agent Builders

1. Specialized agents outperform generalists. A single “review everything” prompt produces shallow output. Twenty-three specialized prompts, each focused on one dimension, produce deep analysis.
2. Research is infrastructure. Without a research layer, agents operate on stale or incomplete context. Dedicated researcher agents close that gap.
3. Prompts are architecture decisions. The way you structure your system prompts — role boundaries, naming conventions, sequencing — shapes what your agent system can and cannot do.
4. Parallel execution matters. If you have 23 reviewer agents but run them sequentially, your review pipeline takes too long to be practical. Design for parallelism from the start. See Agentic Patterns — Compounding Engineering for a deeper breakdown of how this pattern compounds over time.

The full agent definition set is available at github.com/EveryInc/compound-engineering-plugin.

📖 Related Reads

• NoCode Insider — AI workflow automation with no-code tools, agents, and APIs
• ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NiteAgent.

← Back to all posts