Why Python for Agents

Python is a programming language. A program is a list of instructions a computer follows from top to bottom. You will use Python to name values, make decisions, loop, call functions, read JSON, and catch errors. Those skills are the whole foundation of an agent.

An agent is a program that has a goal, looks at what just happened, and then takes a next step. The “brain” of many agents is a language model. The hands are Python functions. The loop that calls those functions is also Python. If you cannot read Python yet, you cannot debug an agent yet. That is why this track starts from zero.

This site runs Python in your browser. You do not need to install Python first. Click Run under a live code box to see output. Output appears only if you call print(). If you compute a value and never print it, the work still happens, but you see nothing.

Why Python

Python is not the fastest language. Models can write many languages. Python wins for agents because the rest of the work already lives here: files, tests, data, and libraries that talk to models.

A library is code other people wrote that you can use. The standard library is the set of libraries that ship with Python itself: json, math, re, pathlib, and more. This editor only has the standard library. There is no pip and no internet inside a live box.

JSON is a common text format for data. It can hold numbers, text, true/false, lists, and null. In Python, JSON null becomes None. You will see this in later lessons. For now, know that almost every tool call an agent makes is “a name plus JSON-shaped data.”

You can build agents in other languages too. Python is the common choice, not the only choice. We use it here because tools are easy to write as functions, and a function is a named piece of code you can call, like print. When an agent uses a tool, that tool is almost always a Python function.

print writes a line

Python reads a program from top to bottom. Each line is an instruction. Blank lines are ignored. You can put more than one statement on a line with a semicolon, but beginners should not. One idea per line is easier to debug.

print writes text you can see. On this site, that text shows up in the output panel. In a real agent, you will later write the same idea as a log. A log is a record of what happened, often saved as a list or a file. For now, print is enough.

print(class="tok-s">"hello")
print(class="tok-s">"step", 1)
print(class="tok-s">"goal:", class="tok-s">"say hello")

You can pass more than one value. Python puts a space between them. Then it starts a new line. print("step", 1) writes step 1. The number is converted to text for you. You do not have to wrap it yourself when you use print with several arguments.

If you forget print, Python still does the work, but you see nothing. The value is thrown away. This is the first “my code did nothing” bug. The code ran. Nobody showed the result.

print can write anything Python can turn into text: numbers, True, None, lists, and dicts. Later lessons explain those types. You can print them today.

Comments start with #

A comment is a note for humans. It starts with # and runs to the end of the line. Python skips it. Comments do not change what the program does.

Write comments to say why. Do not repeat the code in English. step = step + 1 # add one to step is noise. budget = 8 # remaining model calls before we stop is useful, because the number 8 does not explain the rule.

budget = 8  class="tok-c"># how many model calls we have left
class="tok-c"># Do not print secret keys.
print(class="tok-s">"budget", budget)

A comment is not a lock. A comment that says “do not send secrets” does not stop the program. Safety belongs in real checks, not in notes. If you need the program to refuse a bad tool name, you will write an if later, not a comment.

You can also put a comment after code on the same line. Keep it short. If the explanation needs a paragraph, put it above the line instead.

Indent comes later

An indent is spaces at the start of a line. Later, Python uses indent to group lines under if and for. That grouping is called a block. For now, start every line at the left edge. Do not add extra spaces in front of a normal instruction.

If you indent a line that is not inside if, for, def, or similar, Python raises IndentationError. If a live box fails immediately with that word, look at spaces at the start of lines first.

Blank lines are fine. Python ignores them. Use them to separate ideas, the way paragraphs separate ideas in English.

Tabs and spaces both indent, but mixing them causes errors. This site’s editor uses spaces. Use four spaces when you later write a block. Do not guess.

Run code on this page

This page runs Python with a tool called Pyodide. Pyodide is Python inside the browser. It is real Python, with limits.

Rules for the live boxes:

• Use the standard library (the tools that come with Python)
• There is no pip and no internet
• You must print() to see a result
• A run that never finishes will be stopped by the site
• Errors print in the output panel. Read the last line first. It names the error.

On your own computer you save a file like hello.py and run python hello.py. This editor is that file, plus an output panel. The loop is simple: edit, run, read the output, edit again.

If the output is empty, you probably forgot print. If the output is an error, the program stopped at that line. Lines above it did run. That is useful: print above the crash to see what the names held.

Common mistakes

• Forgetting print and thinking the program “did nothing.”
• Adding spaces at the start of a line “to make it look nested.” Python treats those spaces as structure.
• Putting quotes around a comment: #" note" is still a comment, but " # note" is text.
• Writing Print("hi") with a capital P. Names are case-sensitive. The function is print.
• Expecting the last line to show automatically, like a calculator. This site is a script runner, not a calculator.

Run to execute this in your browser. Nothing is sent to a server.

Change the text and click Run. Watch the output panel. Then delete one print and run again. Notice the missing line. That experiment is the whole editor habit: change one thing, read the output, put the line back.

How agents use this

A tool is a function with a name, like search or print. An agent calls a tool, then reads the result. A trace is a printed log of each step: the goal, the tool, and what came back. If you cannot see the trace, you cannot fix a bug.

Start every script by printing the goal. Then print each action. Then print “done” or the error. That three-line habit is how you learn to read a loop before you write one. Later you will store the same facts in a list instead of only printing them. The facts do not change: goal, action, result.

When a real agent fails, people often blame the model. The first check is still Python: did the tool run, did it print, did it return, did the next line see that return? print is how you answer those questions while you are still learning names and types. Logging libraries come later. The idea is the same.

You will also see comments in agent code that describe policy: “reject unknown tools,” “never log the API key.” Treat those as reminders to write real checks. The language starts here: a line of code, a comment, and output you can read.