Finishing Python, and building your first CrewAI agent

The last Python session before the agents work. Everything here exists because CrewAI and the evaluation framework need it, not for its own sake.

The collections module is the standard library's set of upgraded containers. The honest framing given in class: these are a plus version of the built-in list, tuple, set and dictionary, and most of them you will rarely use in automation. Recognise them, do not memorise them.

from collections import namedtuple, Counter, defaultdict

# a tuple whose positions have names
Info = namedtuple("Info", ["name", "age", "is_married", "grade"])
t = Info(name="Pramod", age=34, is_married=True, grade=9.8)
print(t)         # Info(name='Pramod', age=34, is_married=True, grade=9.8)
print(t.name)    # 'Pramod'   by name
print(t[0])      # 'Pramod'   by index, both still work

The problem it solves is real. A plain tuple ("Pramod", 34, True, 9.8) gives you no way to know what True means or whether 9.8 is a grade or a version. A named tuple keeps tuple behaviour and adds labels.

c = Counter("aaaaabbbbccc")
print(c.most_common(3))   # [('a', 5), ('b', 4), ('c', 3)]
print(c.total())          # 12

d = defaultdict(int)
for w in "test test build".split():
    d[w] += 1
print(dict(d))            # {'test': 2, 'build': 1}
print(d["never-seen"])    # 0, where a plain dict raises KeyError

Counter is the interview one. Counting occurrences in a string is a common coding-round question, and the standard library already does it in one line. defaultdict earns its place by removing the "check if the key exists first" dance.

Python does have an entry point, and it looks like nothing else:

def f1(): print("f1")
def f2(): print("f2")

if __name__ == "__main__":
    print("main guard ran")
    f1()
    f2()

Run the file directly and the block executes. Import the same file from somewhere else and it does not. That is the whole point: it lets a file be both a runnable script and an importable module, which is exactly what you want when a file holds an agent you sometimes run and sometimes import.

The class hit the same problem three separate times, so it is worth naming: a relative path resolves against where you ran the command, not against the file that contains the code.

import os

file_path = os.path.join(os.getcwd(), "testdata.txt")

with open(file_path, "r") as f:
    print(f.read())

with open(...) and the older f = open(...) then f.close() do the same thing. The with form closes the file for you even if something throws in the middle, which is why it is the one to use.

Wrap it when the file might genuinely be missing:

try:
    with open(file_path, "r") as f:
        print(f.read())
except FileNotFoundError:
    print("file not found")

CSV works the same way through the csv module, and pandas does it in fewer lines if you already have it.

An API key does not belong in your source. It goes in a .env file:

GROQ_API_KEY=your_key_here
DB_USER=admin
DB_PASSWORD=super_secret

from dotenv import load_dotenv
import os

load_dotenv()                       # reads .env into the environment
print(os.getenv("DB_USER"))         # 'admin'
print(os.getenv("NOT_SET"))         # None, not an exception

Install it with pip install python-dotenv. Note the mismatch that catches people: the package is python-dotenv, the import is dotenv.

pytest is here because the evaluation framework later in the course is built on it. If you know TestNG, you know this: a test is a function whose name starts with test_, and the assertion is a plain assert.

pip install pytest

pytest                            # everything it can find
pytest test_login.py              # one file
pytest test_login.py::test_valid  # one test
pytest -q                         # quiet, one character per test
pytest -v                         # verbose, one line per test with the result

Discovery is convention, not configuration. pytest collects files named test_*.py or *_test.py, and inside them functions whose names start with test_. A function named anything else is never run, which is the most common reason a test "does not exist".

Assertions are just assert

No assertEquals, no matcher library. pytest rewrites the plain assert statement so that a failure still shows you both sides.

def test_equality():
    assert 3 == 3

def test_membership():
    assert "ok" in "not okay"

When one fails you get the expression and the values, not just "false":

>   def test_fails():        assert 1 == 2
                             ^^^^^^^^^^^^^
E   assert 1 == 2

For floating point, comparing directly is a trap, because 0.1 + 0.2 is not 0.3:

import pytest

def test_almost():
    assert 0.1 + 0.2 == pytest.approx(0.3)

To assert that something does fail:

def test_raises():
    with pytest.raises(ZeroDivisionError):
        1 / 0

def test_raises_match():
    with pytest.raises(ValueError, match="invalid literal"):
        int("abc")

match takes a regular expression and is checked against the message, which stops the test passing on the right exception type raised for the wrong reason.

Fixtures

A fixture is setup that a test asks for by naming it as a parameter.

import pytest

@pytest.fixture
def user():
    return {"name": "admin", "role": "qa"}

def test_fixture(user):
    assert user["name"] == "admin"

Use yield when there is teardown. Everything before the yield is setup, everything after runs once the test is done, pass or fail.

@pytest.fixture
def resource():
    made = ["open"]
    yield made              # the test runs here
    made.append("closed")   # teardown, runs even if the test failed

Scope controls how often it is built. The default is function, meaning fresh for every test.

Verified: two tests sharing a session-scoped fixture see the same object, so a mutation in the first is visible in the second. That is the point of session scope and also its main hazard.

autouse=True applies a fixture to every test without it being requested, which is handy for logging and dangerous for anything else.

Put shared fixtures in conftest.py. Tests in that directory and below can use them with no import at all.

Parametrize

One test, many cases, each reported separately.

@pytest.mark.parametrize("a,b,expected", [
    (1, 1, 2),
    (2, 3, 5),
    (10, -10, 0),
])
def test_add(a, b, expected):
    assert a + b == expected

Three tests appear in the report, not one. When case two fails you see exactly which inputs did it, which is the whole advantage over a loop inside a single test.

Markers are pytest's tags, the same idea as TestNG groups or Cucumber tags.

import pytest

@pytest.mark.smoke
def test_addition():
    assert 3 == 3

@pytest.mark.regression
def test_subtraction():
    assert 1 - 1 == 0

Declare your markers in pytest.ini to avoid warnings about unknown ones:

[pytest]
markers =
    smoke: quick sanity tests
    regression: fuller suite

pytest -m smoke                 # only tests marked smoke
pytest -m "smoke and not slow"  # boolean expressions work
pytest -m "smoke or slow"

Skips and expected failures

import sys
import pytest

@pytest.mark.skip(reason="not implemented yet")
def test_skipped(): ...

@pytest.mark.skipif(sys.version_info < (3, 11), reason="needs 3.11+")
def test_conditional(): ...

@pytest.mark.xfail(reason="known bug, ticket QA-123")
def test_known_bug():
    assert False

The distinction matters when you read a summary line:

• skipped: did not run.
• xfailed: ran, failed, and that was expected. Not a failure.
• xpassed: ran, and unexpectedly passed. Usually means the bug is fixed and the marker should come off.

A real run of every pytest example on this page reported 12 passed, 2 skipped, 1 xfailed, 1 xpassed.

Flags worth memorising

--lf is the one that changes how a day feels. Fix, rerun only what broke, repeat, and run the suite once at the end.

You will meet pytest twice: once as a Python test framework, and again underneath DeepEval, the LLM evaluation framework later in the course, which is built on it. Evaluating a model output is the same shape as any other test: an expected result, an actual result, and an assertion between them. The markers, fixtures and flags above all carry over unchanged.

CrewAI is a Python framework for orchestrating role-based LLM agents. Open source, and free unless you want to run it on their infrastructure.

It offers two shapes:

• Crew. A team of agents with autonomy, collaborating and passing results to each other.
• Flow. Event-driven. When something happens, do something.

The example used to make it concrete: you have a results.json from a Playwright run, 100 tests with 3 failures. An agent whose single role is finding flaky tests reruns the build, compares the two result files, works out which tests changed their answer, and messages you the list. It runs whether or not your laptop is on.

The distinction that answers "why not just use a coding assistant for this": a coding assistant is triggered, and an agent is autonomous. Deploy the agent on a server and it runs on its trigger, at any hour, without you. The point was made with a real figure: a production team running more than thirty-five independent agents for flaky-test detection, root-cause analysis, bug triage and downtime tracking, none of which anyone wakes up.

Agent accepts more than sixty fields and Task more than thirty. These are the ones worth knowing, all confirmed present on the real classes in crewai 1.15.17.

role, goal and backstory are prompt engineering, not metadata. They are assembled into the system prompt, so vague ones produce vague output. "QA Engineer" beats "Assistant", and a backstory naming the domain beats a generic one.

context is how agents chain. It takes task objects, not strings:

analyse = Task(description="Analyse the ticket", expected_output="a summary", agent=analyst)
write   = Task(description="Write test cases",  expected_output="a list",    agent=writer,
               context=[analyse])          # write now receives analyse's output

Install it, with either package manager. CrewAI requires Python 3.10 or newer (and, as of this version, below 3.14):

pip install crewai

uv tool install crewai

Tools are a separate package, which is what the missing-module error is telling you when an import fails:

pip install crewai-tools

The core install pulls in a lot, including chromadb and openai, so expect it to take a while and to want its own virtual environment.

Then five steps, in order. This is the whole file.

import os
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, LLM

load_dotenv()

# 0. the brain
llm = LLM(
    model="openai/gpt-oss-120b",
    base_url="https://api.groq.com/openai/v1",
    api_key=os.getenv("GROQ_API_KEY"),
)

# 1. the agent identity
qa_agent = Agent(
    role="QA Engineer",
    goal="Analyse the feature or requirement and create 5 to 10 test cases",
    backstory="You are a senior QA engineer with 15 years of experience "
              "in test planning and test case design.",
    llm=llm,
    verbose=True,
)

# 2. the task
task = Task(
    description="Create 5 to 10 test cases for the login page of the practice app.",
    expected_output="A numbered list of test cases, each with a one-line description.",
    agent=qa_agent,
)

# 3. the crew
crew = Crew(agents=[qa_agent], tasks=[task], verbose=True)

# 4. kick off
if __name__ == "__main__":
    result = crew.kickoff()
    print(result)

Run it with python test_analyst_agent.py. That is it.

verbose=True prints everything the agent does as it does it, which is how you see the crew start, the task get assigned, and the final answer come back.

This is the part that fought back live, and it is worth getting right because you will hit it within five minutes of starting.

CrewAI defaults to OpenAI. If you do not have an OpenAI key, you have to point it somewhere else, and the obvious guess does not work.

Route A is the one used in the code above, and it needs nothing extra. Groq exposes an OpenAI-compatible endpoint, so the openai/ prefix plus Groq's base_url is all it takes.

The general lesson is worth more than the fix: the error message named the solution ("install LiteLLM for broad model support") and it went unread while a fix was guessed at instead. Read the whole error before asking anything to repair it.

The same pattern covers any OpenAI-compatible endpoint, which is most of them.

The crew is the container. It holds the agents and the tasks, and kickoff() is the only line that runs anything.

from crewai import Crew, Process

crew = Crew(
    agents=[analyst, writer],
    tasks=[analyse, write],
    process=Process.sequential,     # the default
    verbose=True,
)

• Process.sequential runs tasks in list order, each receiving what came before. Start here.
• Process.hierarchical adds a manager that decides who does what and in which order.

Crew(agents=[...], tasks=[...], process=Process.hierarchical)                  # ValidationError
Crew(agents=[...], tasks=[...], process=Process.hierarchical, manager_llm=llm) # fine

Other crew fields worth knowing: memory, cache, max_rpm, and planning for a planning pass before execution.

Every error here was produced against a real install rather than recalled, so the symptom column is the text the library actually prints.

The most useful thing in the session was not the agent. It was watching an assistant asked to add a small pytest wrapper, and instead rewrite the file, add a main function, generate a config, and start creating files in an unrelated folder. The session's response was to stop it, delete the extra work, and just run the file:

python test_analyst_agent.py

It worked first time, and had worked all along.

The agent built here is entirely hardcoded, which was stated plainly rather than glossed over. The task is a fixed string and the output goes to the terminal. Both become dynamic next: agents and tasks can be parameterised, and the task description can come from a Jira ticket instead of a literal.

The build trailed for the coming sessions: a multi-agent Jira triage system, where one agent fetches the ticket, another does root-cause analysis, a third recommends test cases, and the result is posted to Slack. Guardrails and hallucination checks come after that.

There is a second shape to know about before that. Crew is a team of agents collaborating on tasks. Flow is event-driven: when something happens, run this. Most QA work starts as a crew, and a flow is what you reach for when the trigger matters as much as the work, such as a build finishing or a ticket changing state.

The realistic first project, if you want one before the triage system: an agent whose only role is finding flaky tests. Rerun a build, compare the two result files, work out which tests changed their answer between runs, and post the list to Slack. One role, done unattended, on a schedule nobody has to remember.

• Today's task: build your first CrewAI agent, run it, and post a screenshot of the run.
• Install CrewAI with pip or uv, and put a GROQ_API_KEY in a .env file that is listed in .gitignore.
• Practise the Python exercises. The running count is past 180.
• Ask your questions in the community thread, which was noticeably empty.
• Tuesday and Thursday evening: the AI Fluency certification sessions. Do not miss these.
• Coming next: the rest of CrewAI, a research agent, triage agents, and the multi-agent Jira system.