Lab 0 — Your first agent¶

uv is a fast Python project manager. It installs the right version of Python for you, creates a virtual environment, and installs packages, all from one tool.

If you don't use Homebrew on macOS, the standalone installer from the Linux tab works on macOS too. It installs uv into ~/.local/bin and adds that folder to your PATH.

Ollama runs language models locally. Nothing you send it leaves your laptop, and it costs nothing per call. On macOS and Windows it runs in the menu bar or system tray once you start the app. On Linux it runs as a systemd service named ollama, with no window or icon.

qwen3:1.7b is a 1.7-billion-parameter model, about 1.4 GB on disk and under 3 GB of memory while it runs. For comparison, the models behind commercial chat assistants are estimated at hundreds of billions to trillions of parameters. Expect it to be noticeably less capable. That's useful: you'll see failures today that a bigger model would hide.

When you run it, you'll see it "think" first before it answers.

uv sync read three files and did three things:

A virtual environment is a private copy of Python and packages for one project, so projects can't break each other. You run code inside it with uv run:

uv run step2_agent_loop.py   # this project's Python and packages

You never need to "activate" anything. If you want to, it's source .venv/bin/activate on macOS or Linux, or .venv\Scripts\activate on Windows. Later in the semester you'll add packages with uv add <package>, which updates pyproject.toml and uv.lock together.

Programs need configuration (which model? which server?) and secrets (passwords, API keys). Neither belongs in your code:

• Configuration changes between machines. Your laptop might need a smaller model than your teammate's. If the model name is in the code, you'd fight over it in every commit.
• Secrets in code end up in git, and git history is forever. Bots scan GitHub for keys around the clock. A key pushed to a public repo is typically found and abused within minutes, and deleting it in a later commit doesn't remove it from the history.

The standard answer is environment variables: named values that live in the environment a program runs in, not in its code. Python reads them with os.getenv("NAME"). Look at config.py to see every variable this lab uses.

You could set them in your terminal before every run, but that gets tedious, so projects keep them in a file named .env and load it at startup (that's the load_dotenv() line in config.py).

Notice the pair: .env.example is committed and tells teammates which variables exist. .env holds your real values and is never committed. You'll use this pattern in every project from now on.

Hugging Face is where most open models, including ours, are published. You'll use it in Part 1 to download your model's tokenizer.

1. Create a free account at https://huggingface.co (or sign in).
2. Go to Settings → Access Tokens and click Create new token.
3. Choose token type Read, name it is456, and create it.
4. Copy the token (it starts with hf_).

Then open .env in your editor and paste it after HF_TOKEN=. Finally, run git status: .env must not appear in the list.

This downloads the tokenizer for your model from Hugging Face, using your token. A tokenizer is the fixed dictionary that turns text into the numbered pieces (tokens) a model reads and writes. Models never see letters or words, only token IDs.

The output labels each piece:

• [thinking] is the model reasoning to itself.
• [tool call] is what it asked your code to run.
• [tool result] is what your code sent back.
• The final line reports model calls, tokens and time.

The agent has no memory between runs, so each question starts from nothing. Run one of them again with --show-messages to print the full conversation exactly as the model last saw it.

Its body is a TODO that returns an error, which is what you saw in question D. load_policy_sections() is already written for you; your code will be about six lines. The comment in the stub gives you the steps:

@tool
def lookup_policy(topic: str) -> str:
    """Look up the company's purchasing and accounts payable policy on a topic, e.g. 'three-way match', 'duplicate invoices', 'new vendors'."""
    # TODO (Part 4): replace the line below with a real implementation.
    #
    #   1. sections = load_policy_sections()
    #   2. Split `topic` into lowercase words.
    #   3. Keep every section whose heading or text contains any of those words.
    #   4. Return the matching sections as "## heading\n\ntext", joined by blank
    #      lines. If nothing matches, return a message that says so AND lists
    #      the available section headings, so the model can try again.
    return "ERROR: lookup_policy is not implemented yet."

When it returns policy text, rerun question D, and add one of your own that needs both the database and the policy, for example Which pending invoices would our policy put on hold, and why?