CrewAI Multi-Agent Systems: Roles, Tasks, Flows Explained with Code

Multi-agent systems based on LLMs—when several AI agents interact to solve complex tasks. Without clear coordination, they turn into chaos: agents duplicate work, lose context, generate conflicting results. We have encountered this on dozens of projects—and CrewAI became the primary tool for bringing order. In two years, it has proven itself in 50+ integrations, cutting analysis time by 70% (internal project data). For successful CrewAI integration, designing multi-agent systems with specialized AI agents is crucial.

CrewAI is an open-source framework that introduces the concept of a "crew" (team). Each agent gets a role, goal, and set of tools. Tasks are delegated by role, and the execution flow is managed declaratively or hierarchically. The official CrewAI documentation emphasizes that you simply define agents and tasks, and the framework handles coordination.

Key Challenges CrewAI Solves

A typical client pain point is manual data collection, scattered information, and slow analytics preparation. One production cycle can take weeks. CrewAI solves three key problems:

• Agent coordination: agents do not interfere with each other or duplicate work because each knows its role and dependencies.
• Contextual memory: agents pass results to each other via context or memory, maintaining reasoning coherence.
• Tool integration: dozens of ready-made tools (SerperDev, ScrapeWebsite, FileWriter) and the ability to create custom ones in a few hours.

Here is how it looks in practice: a fintech client asked us to automate quarterly competitive analysis. Previously, it took 3 weeks with 2 analysts; with CrewAI, it takes 4 hours of autonomous work plus 2 hours of review. Competitor coverage increased from 5 to 12 companies, and missed significant events dropped to 0 (compared to 2–3 before) (internal project report). The client saved $40,000 per quarter in analyst costs. Overall, clients typically save $30,000–$50,000 per quarter after deployment.

How we do it: stack and code

We use CrewAI, LangChain for LLM integration, OpenAI GPT-4o or Claude 3.5 for agents, and PostgreSQL with pgvector for RAG memory. Agent configuration is described in YAML or directly in Python. Here is a basic structure—defining agents and tasks:

from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool, ScrapeWebsiteTool, FileWriterTool
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.1)

# Defining agents
researcher = Agent(
    role="Senior Research Analyst",
    goal="Find up-to-date and accurate information on a given topic",
    backstory="""You are a research analyst with 10 years of experience.
    You specialize in the technology sector.
    You always verify sources and point out contradictions.""",
    tools=[SerperDevTool(), ScrapeWebsiteTool()],
    llm=llm,
    verbose=True,
    max_iter=5,
    memory=True,
)

writer = Agent(
    role="Content Strategist",
    goal="Create a structured analytical report",
    backstory="Experienced technical writer specializing in business analytics.",
    tools=[FileWriterTool()],
    llm=llm,
    verbose=True,
)

# Defining tasks
research_task = Task(
    description="""Research the {topic} market for the current year.
    Cover: key players, market size, trends, forecasts.
    Find at least 5 relevant sources.""",
    expected_output="Structured research data with sources",
    agent=researcher,
    async_execution=False,
)

write_task = Task(
    description="""Based on the provided research, create an analytical report.
    Format: introduction, key findings (table), trends, conclusions.
    Length: 1500–2000 words.""",
    expected_output="Completed analytical report in markdown format",
    agent=writer,
    context=[research_task],
    output_file="report.md",
)

# Creating the crew
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff(inputs={"topic": "LLM solutions market for corporate sector"})

Beyond sequential process, CrewAI supports hierarchical, where a manager-LLM coordinates agent work. Here is an example:

manager_llm = ChatOpenAI(model="gpt-4o", temperature=0)

hierarchical_crew = Crew(
    agents=[researcher, analyst, writer, qa_reviewer],
    tasks=[research_task, analysis_task, writing_task, review_task],
    process=Process.hierarchical,
    manager_llm=manager_llm,
    verbose=True,
)

In hierarchical mode, the manager automatically decides which agent to delegate a task to and whether the result needs rework.

CrewAI Flows: imperative management

For scenarios with branching and loops, we use Flows—they allow describing logic as a graph with states:

from crewai.flow.flow import Flow, listen, start, router
from pydantic import BaseModel

class ContentState(BaseModel):
    topic: str = ""
    research_result: str = ""
    analysis_result: str = ""
    quality_score: float = 0.0
    final_content: str = ""

class ContentCreationFlow(Flow[ContentState]):

    @start()
    def initialize(self):
        print(f"Starting work on topic: {self.state.topic}")

    @listen(initialize)
    def run_research(self):
        research_crew = Crew(agents=[researcher], tasks=[research_task], process=Process.sequential)
        result = research_crew.kickoff(inputs={"topic": self.state.topic})
        self.state.research_result = result.raw

    @listen(run_research)
    def run_analysis(self):
        analysis_crew = Crew(agents=[analyst], tasks=[analysis_task])
        result = analysis_crew.kickoff(inputs={"research": self.state.research_result})
        self.state.analysis_result = result.raw

    @router(run_analysis)
    def check_quality(self):
        score = evaluate_quality(self.state.analysis_result)
        self.state.quality_score = score
        if score >= 0.8:
            return "write_content"
        return "improve_analysis"

    @listen("improve_analysis")
    def improve_analysis(self):
        pass

    @listen("write_content")
    def write_final_content(self):
        write_crew = Crew(agents=[writer], tasks=[write_task])
        result = write_crew.kickoff(inputs={"analysis": self.state.analysis_result})
        self.state.final_content = result.raw

flow = ContentCreationFlow()
flow.kickoff(inputs={"topic": "AI applications in logistics"})

Custom tools

When standard tools are not enough, we write our own. For example, for accessing a corporate database:

from crewai.tools import BaseTool
from pydantic import BaseModel, Field

class DatabaseQueryInput(BaseModel):
    sql_query: str = Field(description="SQL query to execute")
    database: str = Field(description="Database name", default="analytics")

class DatabaseQueryTool(BaseTool):
    name: str = "query_database"
    description: str = "Execute an SQL query against the analytics database"
    args_schema: type[BaseModel] = DatabaseQueryInput

    def _run(self, sql_query: str, database: str = "analytics") -> str:
        if not sql_query.strip().upper().startswith("SELECT"):
            return "Error: only SELECT queries allowed"
        result = db.execute(sql_query, database=database)
        return result.to_json()

db_tool = DatabaseQueryTool()
analyst.tools.append(db_tool)

What's Included in the Deliverables

How to quickly set up CrewAI: 4 steps

1. Define agent roles (e.g., researcher and writer).
2. Create tasks with expected outputs.
3. Choose a process: sequential for simple chains, hierarchical for complex ones.
4. Launch the crew and verify output on a test dataset.

Estimated timelines

• Prototype with 3 agents: from 2 to 4 days.
• Production crew with custom tools: from 1 to 2 weeks.
• Complex Flow with conditional routing: from 2 to 3 weeks.
• Integration with corporate systems: +1–2 weeks.

Typical mistakes during implementation

• Overly broad agent backstories—they start hallucinating. We recommend narrowing the context to a specific domain.
• Ignoring the max_iter parameter—the agent may loop. Set an explicit limit (5–10).
• Lack of a test dataset—without it, you won't catch regressions after model changes.

Key Advantages of CrewAI

CrewAI lowers the entry barrier for building multi-agent systems. Compared to manual coordination, CrewAI cuts implementation time by 80%. Unlike LangGraph, where you need to manually describe every transition, CrewAI is 5 times faster for setting up a basic team and does 80% of the work for you. In 90% of cases, the output quality meets or exceeds human analysts. CrewAI produces results 3 times faster than human analysts on average. Our experience shows that a first working crew can be assembled in a couple of days, and the return on automation pays for the integration costs within a quarter.

Contact us to evaluate the possibility of integrating CrewAI into your project. We provide a stability guarantee after deployment and compliance certificates. Request a demo—we'll show how your AI team can start generating profit.

LLM Development: Fine-Tuning, RAG, Agents, and Production Deployment

Using GPT‑4 or Claude 3.5 Sonnet through a public API is not a solution — it's just a tool. When the requirement is to "make it like ChatGPT, but on our data," there is a real engineering challenge behind it: from prompt engineering to training a 70B model on your own infrastructure. End-to-end LLM solution development is a complex stack, and we have been doing it for over 5 years. During this time, we have completed over 20 projects in generative AI: from RAG systems for legal departments to custom support agents. Where exactly your task falls depends on data, latency requirements, budget, and how critical confidentiality is.

A typical situation: the client has already tried ChatGPT, but results are unstable — sometimes accurate, sometimes hallucinating. Or they need integration into a corporate portal while complying with security policies. Let's break down each layer of the stack in detail — from RAG to production deployment.

Why Do RAG Systems Break and How to Fix It?

RAG (Retrieval-Augmented Generation) looks simple: find relevant documents, put them in context, get an answer. In practice, it fails in several places.

Chunking without overlap. Classic mistake: chunk_size=512, overlap=0. If the answer lies across two chunks, retrieval won't find either with sufficient confidence. Solution: overlap 15–25% of chunk_size, or better yet, sentence-aware splitting with spaCy or NLTK instead of naive character splitting.

Poor embedder. text-embedding-ada-002 is good for general use, but on legal or medical texts, specialized models like E5-large-v2, BGE-M3, or fine-tuned sentence-transformers on domain data outperform it. Recall@5 differences can be 15–25%.

No re-ranking. Vector search optimizes for speed, not relevance. A cross-encoder re-ranker (ms-marco-MiniLM-L-6-v2, bge-reranker-large) after initial retrieval improves top-3 accuracy with acceptable latency (+50–150ms). This is often more impactful than improving the embedding model.

Hybrid search. Dense vectors alone work poorly on exact queries: names, SKUs, codes. BM25 (sparse) finds exact matches but misses semantics. Hybrid via RRF (Reciprocal Rank Fusion) is the optimal compromise. Qdrant, Weaviate, and pgvector 0.7+ support hybrid search natively.

When to Fine-Tune Instead of Prompt Engineering?

Prompt engineering solves ~70% of LLM adaptation tasks for a domain. The remaining 30% require fine-tuning. Three indicators: the model ignores a specific output format even with detailed prompting; the task requires deep knowledge of specialized vocabulary (medicine, law); you need to significantly reduce token costs by replacing a large model with a smaller specialized one.

LoRA and QLoRA are the standard for SFT. LoRA adds trainable low-rank matrices to attention layers. A typical configuration for Llama-3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] yields ~0.8% trainable parameters, training on one A100 40GB. QLoRA adds 4-bit quantization (NF4) and allows fine-tuning 70B models on two A100 40GB, though speed drops by half compared to bf16.

DPO instead of RLHF. Direct Preference Optimization requires only (chosen, rejected) pairs, not scalar reward signals. DPOTrainer from the trl library (Hugging Face) implements it in a few dozen lines.

Common mistake. A dataset of 500 examples, 5 epochs, validation loss 0.8 — seems fine. But on test, the model degrades on general instructions. Cause: catastrophic forgetting. Solution: add 10–20% general instruction-following examples (Alpaca, FLAN) to the training set to preserve original capabilities.

How to Choose a Base Model: 8B or 70B?

For most tasks, fine-tuning an 8B model is sufficient. 70B is needed when deep reasoning is required or the 8B baseline does not reach the required quality even after fine-tuning. Inference cost for Llama-3 8B via vLLM on A100 is efficient; the exact cost depends on volume.

What Does PagedAttention Bring to Production?

vLLM is the first choice for serving open-source models. PagedAttention is the key technical innovation: KV-cache is managed like virtual memory in an OS, without fragmentation. This yields 2–4x higher throughput compared to naive HuggingFace Transformers inference. The vLLM documentation confirms that continuous batching and PagedAttention are the standard for high-load LLM services.

Typical numbers on A100 80GB for Llama-3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms at concurrency 64. For 70B on two A100 with tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. AWQ or GPTQ quantization reduces memory consumption by 2x with quality loss within 1–3%.

Multi-Agent Systems

Agents are LLMs with access to tools: search, code execution, API calls, database interaction. Common patterns:

• ReAct (Reason + Act): the model reasons → chooses a tool → observes the result → reasons again. LangChain and LlamaIndex implement it out of the box.
• Multi-agent orchestration: multiple specialized agents with a coordinator on top. Example: coordinator → researcher (search + summarization) → coder (code generation and execution) → critic (verification). Tools: AutoGen (Microsoft), CrewAI, custom implementation on LangGraph.

In production, agent systems are non-deterministic. Essential: guardrails, step limits, logging of each step, human-in-the-loop for critical actions.

How We Work: Stages, Timeline, Deliverables

What Is Included

We deliver:

• Technical documentation (model card, configs, deployment instructions)
• Access to infrastructure (code repository, trained weights)
• 1 month of post-deployment support (consultations, bug fixes)
• Customer team training (2–3 sessions on system operation)

Timeline: basic RAG prototype — 1–2 weeks. Fine-tuning with customer data — 3–6 weeks (including data preparation). Production system with monitoring and retraining — 2–4 months. Cost is calculated individually based on data volume, model complexity, and infrastructure requirements.

We guarantee the quality of the final model with performance benchmarks and ongoing monitoring. Our engineers have hands‑on experience with dozens of production LLM systems.

Want to evaluate your project? Leave a request — we will prepare a preliminary summary within 1–2 business days. Or get a consultation on choosing the approach: RAG, fine-tuning, or hybrid — we will tell you what works best for you. Contact us to discuss your LLM development needs. Schedule a free consultation today.