Role-based multi-agent orchestration framework for building "Crews" of collaborating LLM agents (each with a role, goal, backstory, and optional tools) that execute sequential or hierarchical task pipelines, plus event-driven "Flows" for precise, single-LLM-call orchestration. Use when composing specialized agents (e.g. a research agent + an analysis agent + a writer agent) into a declarative pipeline for complex multi-step tasks like automated literature review or multi-agent research workflows. Distinct from LangGraph's explicit state-machine graphs and smolagents' minimal tool-calling loop — CrewAI is standalone (no LangChain dependency) and expresses orchestration as roles and delegated tasks rather than a graph or a single ReAct loop.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Role-based multi-agent orchestration framework for building "Crews" of collaborating LLM agents (each with a role, goal, backstory, and optional tools) that execute sequential or hierarchical task pipelines, plus event-driven "Flows" for precise, single-LLM-call orchestration. Use when composing specialized agents (e.g. a research agent + an analysis agent + a writer agent) into a declarative pipeline for complex multi-step tasks like automated literature review or multi-agent research workflows. Distinct from LangGraph's explicit state-machine graphs and smolagents' minimal tool-calling loop — CrewAI is standalone (no LangChain dependency) and expresses orchestration as roles and delegated tasks rather than a graph or a single ReAct loop.
license
MIT
allowed-tools
["Read","Write","Edit","Bash"]
compatibility
Requires Python >=3.10,<3.14 and crewai 1.x. Routes most LLM providers through LiteLLM by default, so provider extras (crewai[anthropic], crewai[aws]/[bedrock], crewai[azure-ai-inference], crewai[google-genai]) are usually optional; install crewai[tools] to pull in the separate crewai-tools package of prebuilt tools (web search, file readers, code execution, etc.).
metadata
{"version":"1.0","skill-author":"community"}
CrewAI
Overview
CrewAI is a Python framework, built from scratch independent of LangChain, for orchestrating teams of LLM agents. It has two complementary orchestration models:
Crews — role-based, autonomous collaboration. You define Agents (each with a role, goal, backstory, and optional tools/llm) and Tasks (each with a description, expected_output, and an assigned agent), then wire them into a Crew that runs tasks either Process.sequential (task N's output feeds task N+1) or Process.hierarchical (a manager agent dynamically delegates tasks to the crew).
Flows — event-driven, deterministic control. @start()/@listen()-decorated methods let you chain individual LLM calls, conditionals, and (optionally) whole Crews with precise control, when you need more determinism than a fully autonomous Crew.
Where LangGraph models orchestration explicitly as a state-machine graph, and smolagents minimizes overhead around a single tool-calling loop, CrewAI's abstraction is closer to how a human team is briefed: each agent gets a persona and a goal, and delegates/collaborates through natural-language task handoffs.
Installation
uv pip install crewai
uv pip install "crewai[tools]"# prebuilt tools package (web search, RAG, code exec, file I/O, ...)# Provider extras are usually unnecessary — crewai talks to most providers via LiteLLM model strings
uv pip install "crewai[anthropic]"# only if you need the native (non-LiteLLM) Anthropic SDK path
Set the relevant provider API key as an environment variable (e.g. ANTHROPIC_API_KEY, OPENAI_API_KEY) before running — CrewAI's default llm= resolution picks these up automatically via LiteLLM.
Complex branching/looping control flow you want to see explicitly
Lightweight single-agent tool use, fast prototyping
Determinism
Crews are more autonomous; Flows add explicit control
High (you define every edge)
Low-to-medium (ReAct loop)
Reach for CrewAI when the natural decomposition of your problem is "a team of specialists," and for LangGraph when you need to reason precisely about every possible transition between steps.
Core Concepts
from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="Senior Research Analyst",
goal="Find and summarize the latest findings on {topic}",
backstory="You are an expert at scanning literature and extracting the signal from noise.",
verbose=True,
)
writer = Agent(
role="Technical Writer",
goal="Turn research findings into a clear, well-structured report",
backstory="You write for a technical but time-constrained audience.",
verbose=True,
)
research_task = Task(
description="Research recent developments in {topic} and list the 5 most important findings.",
expected_output="A bulleted list of 5 findings, each with a one-sentence explanation.",
agent=researcher,
)
writing_task = Task(
description="Using the research findings, write a 3-paragraph summary report on {topic}.",
expected_output="A 3-paragraph markdown report.",
agent=writer,
context=[research_task], # explicitly pass research_task's output into this task's context
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential,
verbose=True,
)
result = crew.kickoff(inputs={"topic": "CRISPR base editing"})
print(result.raw)
Process.hierarchical instead assigns a manager LLM (set via Crew(manager_llm=...) or a dedicated manager Agent) that decides at runtime which agent handles which task — useful when the task breakdown isn't known ahead of time.
Tools
from crewai.tools import tool
@tool("Query internal database")defquery_db(sql: str) -> str:
"""Run a read-only SQL query against the internal research database and return rows as text."""return run_query(sql)
researcher = Agent(role="...", goal="...", backstory="...", tools=[query_db])
crewai-tools (via the tools extra) ships common prebuilt tools — web/serper search, file readers, directory readers, RAG tools, code-execution sandboxes — so custom @tool functions are usually only needed for internal/proprietary integrations.
Flows: Event-Driven Control
from crewai.flow.flow import Flow, start, listen
classResearchFlow(Flow):
@start()defget_topic(self):
self.state["topic"] = "single-cell foundation models"returnself.state["topic"]
@listen(get_topic)defrun_research_crew(self, topic):
return research_crew.kickoff(inputs={"topic": topic})
@listen(run_research_crew)defsave_report(self, report):
withopen("report.md", "w") as f:
f.write(report.raw)
ResearchFlow().kickoff()
Flows can mix single LLM calls, plain Python logic, and whole Crew.kickoff() calls as steps — use them when a Crew alone gives you too little control over the sequence of operations.
Memory
Crews support short-term memory (within a run), long-term memory (persisted across runs via a local vector store), and entity memory (tracked facts about specific entities). Enable with Crew(memory=True); for production use, back it with an explicit vector store config rather than the default local one so memory survives across deployments.
Project Scaffolding
crewai create crew my_project
cd my_project
crewai run
This generates the JSON-first layout: agent definitions live in agents/*.jsonc, while tasks, process, and input defaults live in crew.jsonc. If you need the older Python/YAML layout with crew.py, config/agents.yaml, and config/tasks.yaml, create it explicitly:
crewai create crew my_project --classic
Observability
CrewAI emits OpenTelemetry traces (via opentelemetry-sdk, bundled as a dependency) and has a hosted "Crew Control Plane" (part of the commercial AMP Suite) for tracing/monitoring in production; for local debugging, verbose=True on Agent/Crew/Task prints each agent's reasoning and tool calls to stdout.
Common Pitfalls
Vague expected_output. CrewAI agents use expected_output to judge when a task is "done" — a vague description (e.g., "a summary") produces inconsistent, sometimes incomplete outputs; be concrete about format and length ("a bulleted list of exactly 5 findings").
Duplicate or overlapping roles confuse hierarchical delegation. In Process.hierarchical, the manager picks an agent by matching the task to agent roles/goals; near-identical roles across agents lead to unpredictable delegation. Keep roles distinct.
Missing context=[...] between sequential tasks. In Process.sequential, CrewAI passes prior task outputs forward automatically by order, but for non-adjacent dependencies (task 3 needs task 1's output, not task 2's) you must set context= explicitly or the dependency is silently dropped.
Cost/latency compounding in long sequential crews. Each agent call is a full LLM round-trip (sometimes with its own tool-calling sub-loop); a 5-agent sequential crew can be significantly slower/costlier than one well-prompted single-agent call — reserve multi-agent Crews for genuinely decomposable problems, not everything.
Tool description mutation. Recent versions (1.15.x) intentionally stop rewriting a tool's authored description at construction time — if you're relying on CrewAI to auto-generate/adjust a tool's description for the LLM, write the description you actually want up front instead.
Rate limits from verbose=True chains during development. Verbose mode is invaluable for debugging but doesn't reduce actual LLM calls; if you're hitting provider rate limits while iterating, that's real traffic, not a logging artifact — reduce max_iterations/agent count while debugging.
