Setting Up Your First AI System

You've spent five modules learning what AI systems are and why they matter. Now I want to get a model talking to you on your own machine — because everything I learned about building these systems, I learned by running something small and watching what it actually did.

When I built my first internal Support Dashboard, the breakthrough moment wasn't the architecture diagram. It was the first time I sent a real customer message to a model and read what came back. That single round trip — message in, answer out — is the atom that every AI system is built from. Get that working and the rest is composition.

Think of this module like learning to start a car before you learn to drive. We're not going anywhere yet. We're just turning the key, hearing the engine, and confirming the dashboard lights come on. Once you trust that the engine runs, the road trip in the next four modules gets a lot less scary.

By the end of this module you'll have a clean project, the Anthropic SDK installed, and a script you can run that sends a real customer message to Claude and prints a triage response.

Across the rest of this path we build one thing, and we build it for real: a support-triage assistant. It's the de-identified, distilled version of the first system I shipped that actual users depended on.

Here's the job it does. A customer message arrives — something like "my export keeps failing" — and the assistant:

• Answers from what it knows, when the question is simple,
• Classifies and routes the message (billing, bug, how-to, something else), and
• Escalates to a human when it isn't confident.

That's it. No cartoon café, no imaginary bakery. One realistic assistant that does work a support team actually needs, carried from this module all the way to the capstone.

In this module we build the smallest possible slice of it: a single script that hands one customer message to Claude and prints the reply. Modules 07 through 09 grow that slice into the full assistant.

Before we write any code, let's make sure the workbench is set up. None of this is exotic — it's the same toolkit I reach for on every project.

• Python 3.10 or newer — the language we'll use. Check with python3 --version.
• A code editor — VS Code is a fine default, but anything works.
• A terminal — to run commands and your script.
• An Anthropic API key — created from the Anthropic Console. This is the credential that lets your code talk to Claude.

First, a dedicated folder and a virtual environment. A virtual environment is a sandbox: the packages you install for this project stay out of every other project's way, so nothing collides and nothing breaks later.

On Windows the activation line is .venv\Scripts\activate instead. Once it's active, your terminal prompt shows (.venv) — that's how you know packages will land in the sandbox and not your system Python.

Why bother with this? Because the first time I skipped it, I upgraded a library for one project and silently broke another. The sandbox is cheap insurance, and professional setups always use one.

Mid-Module Checkpoint

Before installing anything, look at your terminal. Does the prompt start with (.venv)? If it doesn't, the environment isn't active and your packages will install in the wrong place. Activating it is the most common step beginners skip — and the most common reason "but I installed it!" turns into an import error later.

With the environment active, install the official Anthropic SDK. This is the library that turns a Python function call into a request to Claude and hands you back the response.

pip is Python's package installer — think of it as the app store for Python libraries. That one command downloads the anthropic package and everything it depends on into your virtual environment.

Now wire up your API key. The SDK looks for an environment variable called ANTHROPIC_API_KEY, so we set it in the shell rather than writing it into our code:

This is the moment the module has been building toward. Create a file called triage.py and type in the following. It's the smallest piece of code that does something real: it sends a customer message to Claude and prints the reply.

Run it with python triage.py. After a moment, Claude's reply prints to your terminal. Let's read what each piece is doing, because we'll reuse this exact shape for the rest of the path:

• Anthropic() creates the client. With no arguments, it reads your key from the environment — which is why we set ANTHROPIC_API_KEY and didn't paste it here.
• model="claude-haiku-4-5" picks the model. Haiku is the fast, low-cost member of the family — the right choice for a learner's first calls and for high-volume triage where speed matters.
• max_tokens=1024 caps how long the reply can be, so a runaway response can't surprise you with a giant bill.
• messages=[...] is the conversation — here, one message from the "user" (you, standing in for the customer).

Notice we printed response.content[0].text, not response. The SDK doesn't hand you a plain string — it returns a structured object, and the model's words live inside it. Reaching in for .content[0].text is how you get the actual reply.

Now let's make the call do real triage work. The first version just asked Claude to "triage it." We can be far more useful by giving the model a system prompt — standing instructions that shape every reply. This is the seed of our assistant:

The only new piece is system=instructions. The user message is still the raw customer complaint, but now the model knows its job and answers in a consistent, routable shape. That's the difference between a chatbot and the start of a system.

A Prompt To Sit With

Run the second script a few times with different customer messages. Then ask yourself: what happens when a message is genuinely ambiguous — say, a one-word complaint like "broken"? Should the assistant guess a category, or escalate to a human? There's no single right answer, and how you'd decide is exactly the kind of judgment that separates a demo from a system people can trust. Hold that question; we'll return to it when we add escalation in module 09.

We've turned the key and the engine runs. In the next module we give this assistant a place to live and tools to use by building its first MCP server.