CrewAI Free code examples in Python

crewai-tools is separate and is where the search, scraping and file tools live. Without it an agent has a role and no way to act on anything.

pip install crewai crewai-tools

export OPENAI_API_KEY="sk-your-key"   # macOS / Linux
setx OPENAI_API_KEY "sk-your-key"     # Windows, then open a new shell

The backstory is prompt text, not flavour — it is what separates two agents that would otherwise behave identically. expected_output matters just as much: it is the only description of done the agent gets.

from crewai import Agent, Crew, Process, Task

researcher = Agent(
    role="Incident Researcher",
    goal="Find every prior occurrence of a given error code",
    backstory=(
        "You read maintenance logs for a living and you never "
        "speculate — if the logs do not say it, you do not report it."
    ),
    llm="gpt-5.4-mini",
    verbose=True,
)

writer = Agent(
    role="Report Writer",
    goal="Turn findings into a one-page brief an engineer can act on",
    backstory="You write for busy people. No preamble, no filler.",
    llm="gpt-5.4-mini",
    verbose=True,
)

context is the handoff: the writer receives the researcher's output rather than re-deriving it. Process.sequential runs them in order — which is the only process most crews need.

research = Task(
    description="Find prior occurrences of error code {code} in the logs.",
    expected_output="A bulleted list of dates, machines and outcomes.",
    agent=researcher,
)

report = Task(
    description="Write a one-page brief from the research.",
    expected_output="Markdown, under 400 words, with a recommendation.",
    agent=writer,
    context=[research],       # the handoff, made explicit
    output_file="brief.md",
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research, report],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff(inputs={"code": "E-4471"})
print(result.raw)

MEASURE BEFORE YOU BELIEVE IN IT. usage_metrics is the number that settles the argument: if two agents cost three times one agent and the brief is no better, the split was for the framework's benefit rather than the user's.

import time

started = time.perf_counter()
result = crew.kickoff(inputs={"code": "E-4471"})
elapsed = time.perf_counter() - started

print(f"{elapsed:.1f}s, {result.usage_metrics}")

# Each task's output is available on its own, which is what makes a
# crew debuggable — you can see WHICH step produced the bad claim.
for task_output in result.tasks_output:
    print(task_output.agent, len(task_output.raw), "chars")

Run this against the crew above on the same inputs. IF THE ANSWERS MATCH, SHIP THIS ONE — it is one model call instead of two, with no handoff to lose context across.

solo = Agent(
    role="Incident Analyst",
    goal="Research an error code and brief an engineer on it",
    backstory="You read maintenance logs and write for busy people.",
    llm="gpt-5.4-mini",
)

one_task = Task(
    description=(
        "Find prior occurrences of error code {code} in the logs, "
        "then write a one-page brief with a recommendation."
    ),
    expected_output="Markdown, under 400 words.",
    agent=solo,
)

control = Crew(agents=[solo], tasks=[one_task], process=Process.sequential)

# A crew is worth its cost when the sub-tasks need different tools or
# different judgement, or when one step must be retried or reviewed
# alone. Splitting work that meets none of those tests buys latency.