multi-agent-crew-patterns
Skill4 starsChanged 3 months agoMITView on GitHub
Hierarchical & Sequential Multi-Agent Team Topologies. Covers role specialization (Researcher, Writer, Reviewer, Engineer), shared state passing, task dependency DAGs, error recovery, and consensus voting algorithms for autonomous task resolution.
In this repository19 other files it gives its agents.
- agent-introspection-debuggingSkill
- airops-programmatic-content-engineSkill
- api-designSkill
- code-review-and-qualitySkill
- enterprise-rag-knowledge-systemsSkill
- eval-harnessSkill
- geo-aeo-agent-optimizationSkill
- langchain-agent-patternsSkill
- mcp-server-patternsSkill
- openai-agents-sdkSkill
- pgvector-hybrid-searchSkill
- prd-criticSkill
- product-spec-generatorSkill
- prompt-engineerSkill
- security-and-hardeningSkill
- security-reviewSkill
- signal-based-ai-agentSkill
- tdd-workflowSkill
- ui-ux-pro-maxSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 35
Every agent in a crew requires 4 distinct configuration parameters:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
👥 Multi-Agent Crew & Team Topologies
Multi-Agent Crews partition complex, multi-domain goals across specialized AI agents. Each agent possesses explicit role definitions, goal boundaries, dedicated toolsets, and structured inter-agent communication channels.
🏗️ Topology Patterns
┌────────────────────────────────────────────────────────┐
│ 1. SEQUENTIAL PIPELINE (Linear Dependency DAG) │
│ [Researcher Agent] ──► [Writer Agent] ──► [Reviewer] │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ 2. HIERARCHICAL ORCHESTRATION (Manager + Workers) │
│ ┌──────────────┐ │
│ │ Manager Agent│ │
│ └──────┬───────┘ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ [Data Collector] [Code Generator] [QA Auditor] │
└────────────────────────────────────────────────────────┘1. Role Specification & Agent Identity
Every agent in a crew requires 4 distinct configuration parameters:
from dataclasses import dataclass
from typing import List, Callable
@dataclass
class CrewAgentConfig:
role: str # e.g., "Senior Security Auditor"
goal: str # e.g., "Identify SQL injection and auth vulnerabilities in PRs"
backstory: str # Domain perspective, tone, and constraints
tools: List[Callable]# Accessible function tools
allow_delegation: bool = False2. Sequential Task Execution Engine
Tasks depend on outputs from prior steps:
class TaskDAG:
def __init__(self, description: str, agent: CrewAgentConfig):
self.description = description
self.agent = agent
self.output = None
class SequentialCrewRunner:
def __init__(self, agents: List[CrewAgentConfig], tasks: List[TaskDAG]):
self.agents = agents
self.tasks = tasks
def execute(self, initial_input: str) -> str:
previous_output = initial_input
for task in self.tasks:
print(f"--> [AGENT: {task.agent.role}] Executing Task: {task.description}")
prompt = f"Previous Step Output:\n{previous_output}\n\nTask: {task.description}"
# Execute LLM call with agent instructions & tools
task.output = self.invoke_agent(task.agent, prompt)
previous_output = task.output
return previous_output
def invoke_agent(self, agent: CrewAgentConfig, prompt: str) -> str:
# LLM ReAct execution stub
return f"[{agent.role} Result]: Processed '{prompt[:60]}...'"3. Consensus Voting & Verification Loop
For high-stakes decisions (financial transfers, deployment gating, legal compliance), employ an N-Agent Majority Voting Consensus:
def consensus_gating_vote(voters: List[CrewAgentConfig], task_payload: str) -> dict:
votes = []
for voter in voters:
decision = get_agent_vote(voter, task_payload) # Returns {"vote": "APPROVE" | "REJECT", "reason": "..."}
votes.append(decision)
approvals = sum(1 for v in votes if v["vote"] == "APPROVE")
passed = approvals >= (len(voters) // 2 + 1)
return {
"consensus_passed": passed,
"approval_count": approvals,
"total_voters": len(voters),
"details": votes
}Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

