A year and a half ago, many programmers were intrigued by how AI could help them but most were confident they’d still be the ones writing most of the code.

Not any more.

In my work, AI tools now handle implementation better and faster than I could on my own. But I’m still in the driving seat.

I now spend most of my day interacting with AI agents. But I’m not lounging by the beach while my agents do stuff for me. I’m collaborating with my agents. Managing them. Guiding them. Bouncing ideas off them. Reviewing their work. Steering them.

It’s impossible to disentangle my contributions from my agents’ contributions when you see the output. It’s all intertwined. It’s a collaboration.

And since the AI agents are doing all the implementation, I can focus on the bigger picture, the bigger ideas, the creative aspects. I’m enjoying this process.

That’s why The Python Coding Stack today becomes:

Notes from the Near Future • The Permanently Curious Stack

I’ll still write about Python. That won’t change. The Python Coding Stack is now a section of Notes from the Near Future.

But I won’t write only about Python. That’s why this publication is changing, just like the world around it.

I’ll write about how I’m adapting to this new way of working. What I like about it. And what I don’t. What I’m experimenting with. What works and what doesn’t.

This applies to everyone, not just those interested in programming and Python.

You may also have noticed the Agents Unpacked section in recent months. The change in what I write about is not starting now. It started a few months ago as I found myself spending more and more time with agents rather than with Python (directly). This section is where I’ll focus on how AI agents work and what they are, since we all need to learn how these tools work. And I’m learning in public in this section. I’ll also write about my experiments and experiences using agents.

You’ll also see an Agent & Co. section in the menu. You won’t receive these posts in your feed by default, but you can turn them on if you wish! Twice a week, I’ll share a fun perspective about human-agent interactions. Think of it as a day in the life of Monty – that’s my agent’s name. But behind the light-hearted nature of these cartoons and comics, you’ll gain an appreciation of the realities of working with agents. There’s plenty to learn from these posts!

Here’s the first comic, published earlier today:

How about brain atrophy? Will I lose my sharpness by handing the coding over to agents? As you’ll see from my articles over the coming weeks, I don’t think that’s the case. Working with AI is not about being lazy but about focusing on other aspects of problem-solving.

But I don’t want to get rusty with coding, a skill I enjoy. That’s why I’m starting to learn Rust. So, there’s another new section here on Notes from the Near Future where I’ll be learning Rust in public. There’s nothing published in Getting Rusty yet, but expect the series to start before the end of this year.

By the way, you can customise which sections you receive. But I’d suggest exploring the new sections for a bit first, especially if you’re an AI-sceptic!

So here’s the new line-up for you on Notes from the Near Future • The Permanently Curious Stack:

Subscribe now

I have some more ideas, too. But that’s enough change for one day.

This publication is three and a half years old. There are now over 9,000 subscribers, and that number is still growing daily. One constant in this publication has been that I’ve always published articles that I would want to read myself. That won’t change. In fact, that’s why this publication is broadening its focus.

Another constant throughout the years has been that I’ve always published the majority of my work for free, fully accessible to all. That won’t change, either. But I do publish content exclusively for premium subscribers, and some of my upcoming series will be available only for premium subscribers. It takes plenty of work to produce a publication such as this and keep it running for so long. The support from premium subscribers helps keep this publication thriving.

As always, feel free to reply to this post and any other post. Tell me what you’re working on, how your work is changing (or not), share your thoughts, views, anything, really.

See you in the next post or somewhere in the online world before then…

Stephen

Subscribe now

stephengruppetta.com

Subscribe now

stephengruppetta.com

You ask an AI agent whether you’ll need a raincoat tomorrow. To check the forecast, it can't rely on its knowledge. It needs up-to-date information. It needs to turn your question into a request that a weather service can understand.

This time, we look inside the request itself. How does a large language model (LLM) turn everyday wording into a named operation with specific inputs? And why can a request contain all the right fields yet still ask for the wrong thing?

Who’s Monty? Monty is my personal AI agent. Read the introduction to this series.

Subscribe now

In conversation • Chapter 3

Monty:

Suppose you ask an assistant:

“Will I need a raincoat in Oxford next Saturday?”

It has a weather-lookup tool available, but “Oxford next Saturday” isn’t quite as precise as it looks.

What might the assistant need to clarify before requesting the forecast?

Stephen:

You got me here. I can't figure out why this is not precise. The only thing I'd pick is that "next Saturday" can be ambiguous. It sometimes refers to the Saturday coming up, and sometimes to the next one after the one coming up. Is that the ambiguity?

Monty:

Yes, that’s exactly the ambiguity. A specific date, such as “24 October 2026”, avoids those two readings.

I also had the place in mind. There’s an Oxford in England, but there are Oxfords elsewhere, too. Context might make the intended one obvious, so the assistant needn’t ask unnecessarily. My opening made that sound more mysterious than it was. I’ve managed to turn choosing a coat into a geography test.

The useful point is that the assistant needs to turn our everyday wording into the particular location and date it will send to the weather tool. That involves interpreting what we mean, not just copying our words.

Stephen:

Got it.

Monty:

Suppose we’ve settled on Oxford in England and Saturday, 24 October.

As we saw in Chapter 2, the surrounding software, or harness, tells the model what tools are available and what information each needs. For our weather example, a tool description could say:

get_weather: Look up a forecast. Requires a location and a date written as year-month-day.

It can then produce a request like this:

(Illustrative request, not a real lookup)

{
  "name": "get_weather",
  "arguments": {
    "location": "Oxford, UK",
    "date": "2026-10-24"
  }
}

This format is called JSON. You don’t need to learn its punctuation. Here, name identifies the tool, and arguments contains the inputs supplied to it.

Notice that the request doesn’t mention a raincoat even though that’s what your prompt asked. The model has translated your question into a request for information it can use to answer you.

Stephen:

So, let's see if I follow. The harness receives this response from the LLM and it recognises it's not text but it's a tool call. The harness has all the information it needs, so it can choose to call the get_weather tool and pass the location and date to it. The tool then fetches the weather forecast for that location and date, presumably by accessing some online service that provides this information.

Monty:

Yes, that’s the sequence for our example. The weather tool could contact an online forecasting service using those inputs.

One refinement: the JSON is still text. In a typical tool-use interface, the model’s response is explicitly marked as a tool request. The harness isn’t simply spotting curly brackets in an ordinary reply. Our mock-up represents that request, rather than showing a particular provider’s exact format.

After any checks the software implements, it can run the tool. Here’s a hypothetical successful result (not a real forecast):

{
  "location": "Oxford, UK",
  "date": "2026-10-24",
  "forecast": "Rain likely",
  "temperature_c": 12
}

That gives the model evidence for its raincoat recommendation. Notice that the forecast comes from the tool’s result, not from the model generating a plausible answer about October weather.

Stephen:

So the tool returns this output. Then the harness sends this to the model, which makes sense of it and uses it to provide text for the user. Makes sense, yes. So, to pick up on something you said earlier, does the LLM label each thing it sends to the harness as either text or a tool call, which is how the harness knows what type of output comes from the LLM?

Monty:

Broadly, yes. The model communicates through an interface that distinguishes ordinary text from requests to use tools.

Think of the response as arriving in labelled sections. A text section contains words to show the user. A tool-request section identifies the tool and supplies its inputs. The harness reads those section types rather than guessing from the wording.

The exact arrangement varies between systems. A single response can also contain both, such as “I’ll check the forecast” followed by a tool request. It needn’t be entirely one or the other.

That’s why showing you our JSON example doesn’t trigger a weather lookup. It’s inside an ordinary text reply, not sent as an actual tool request.

Stephen:

Got it. What's next?

Monty:

There’s a useful question hiding behind our example: how did the model know how to ask for the weather?

Two things come together:

• Learned behaviour: a tool-capable model has learned how to use supplied tool definitions to choose an operation and construct a request.

• Information supplied now: the harness tells it which tools are available, what they do, and what inputs they accept.

The model needn’t have encountered our particular get_weather tool during training. Its description might be enough for it to use the tool, much as you can follow instructions for an unfamiliar appliance.

But that isn’t guaranteed. Understanding a description, choosing the right tool, and supplying sensible inputs can all go wrong.

Supplying a new tool description isn’t retraining the model. It’s giving the existing model information to work with.

Stephen:

So the model sees the tool as a black box. It doesn't know how it works, but it knows what it's meant to do and what it needs as input. This means that whoever creates tools needs to write a good description for the tool. However, this is not something that a user needs to worry about, right?

Monty:

Yes. The model doesn’t need to know how the tool works internally. It needs enough information to understand what the tool offers and how to request it. “Black box” is a useful way to think about that, although the model might know something about its workings.

And generally, you’re right about the user. If you’re using a ready-made assistant, its builders or whoever connects the tools should supply clear descriptions and input requirements. You shouldn’t need to write those yourself.

Your part is usually to explain what you want and clarify anything the assistant can’t reasonably infer.

But a good description isn’t a safeguard by itself. Saying “a date is required” tells the model what to provide. Software that rejects a request with no date actually checks that requirement.

Stephen:

If I recall correctly, in the early days of LLMs, when they first hit the mainstream, they could only provide text, right? Presumably tool calling came later.

Monty:

Yes, broadly, if you mean the early mainstream chat interfaces. You typed text, and they replied with text. Dedicated tool-calling support became more common later.

But text output wasn’t an absolute barrier to using tools. A developer could instruct a model:

If you need a forecast, write WEATHER_REQUEST, followed by the location and date.

Software could watch for that convention, interpret it, and run the tool. Whether the model followed the convention reliably was another matter.

Dedicated tool-calling interfaces make that distinction explicit, rather than requiring developers to invent their own conventions. Models can also be trained specifically to produce appropriate tool requests.

So it wasn’t a jump from “words” to an entirely different ability to act. Software could already treat generated words as instructions. Dedicated support made that exchange more structured, though not automatically correct.

Stephen:

And I assume the harnesses around those first chat interfaces, like the first ChatGPT, were fairly basic and mostly just relayed the text to the user and kept the messages together to form the full conversation. So, the harnesses have also evolved to allow tool calls, right?

Monty:

Yes. The surrounding software has evolved too, not just the models.

Your description captures the visible interaction in an early text-only chat product: pass the conversation to the model, receive its reply, and display it. I’d avoid calling the whole system basic, though. There were also accounts, safety measures, and other machinery behind that simple interface.

To support tools, the software needs additional responsibilities: supply tool definitions, recognise tool requests, arrange execution, and return the results. It also needs to handle whatever checks, approvals, and errors its builders choose to support.

The two sides have to fit together. A model capable of requesting tools can’t use them through software that only displays its output. Equally, adding tools to the software doesn’t guarantee that a particular model will request them correctly.

Stephen:

Understood. I'm ready to move on.

Monty:

Let’s look at what the software can actually check.

Suppose the model requests a forecast for Oxford but leaves out the date. If the software checks that all required inputs are present, it can reject that request before attempting a lookup. The model then needs to supply the missing date, asking you if necessary.

Now suppose both inputs are present:

• Location: Oxford, Mississippi, US

• Date: 24 October 2026

That’s a real place and a valid date. But you meant Oxford in England.

Would checking that the request contains an acceptable location and date catch that mistake?

Stephen:

No, in this case the harness and the tool won’t catch this error. This was the model that made an assumption without checking.

Monty:

Right. Those input checks wouldn’t catch a valid location that wasn’t the one you meant. If the context didn’t justify choosing Mississippi, the model should have clarified rather than silently committing to it. Additional software checks could help, but checking the required fields alone wouldn’t.

Now suppose it requests the correct Oxford and date, but receives:

“No forecast available for that date.”

That’s different again. The request was accepted, and the service answered, but the answer lacks the information needed.

The model shouldn’t treat that as “no rain expected”. Missing information isn’t a negative forecast. It might try another suitable source or explain that it couldn’t obtain the forecast, rather than invent a raincoat recommendation.

Stephen:

That makes sense.

Monty:

Two other outcomes call for different responses:

• “Access denied” means the request wasn’t permitted. Repeating it unchanged won’t solve that, and the assistant shouldn’t try to evade the restriction.

• “Service temporarily unavailable” means the lookup couldn’t be completed. A limited retry might help.

Neither tells us what the weather will be.

Now let’s contrast that lookup with a calculation. Suppose you ask:

“Calculate the fuel cost for a 100-mile journey, assuming fuel costs 15p per mile.”

A calculator tool returns £15. Unlike the weather tool, it hasn’t fetched an external fact. It has calculated from supplied inputs.

What does that result establish, and what does it leave unconfirmed about the journey’s actual fuel cost?

Stephen:

It doesn’t check what assumptions are behind the 15p per mile estimate.

Monty:

Exactly. The calculator establishes that 100 miles at 15p per mile comes to £15. It doesn’t establish whether 15p is realistic for that car and journey, or whether the journey is actually 100 miles. Correct arithmetic can rest on inaccurate assumptions.

Stephen:

But the request from the user was clear about calculating the cost of the journey. Why would the agent need to doubt the user? It wasn’t asked to confirm that the values used make sense?

Monty:

You’re right. For that request, the agent should use the supplied assumptions and calculate £15. It wasn’t asked to investigate whether 15p per mile was realistic.

My question was about what the result proves, but I blurred that into what the agent ought to check. Those are different things. You asked for arithmetic. I’d apparently decided to conduct an inquiry.

“Using your figures, the fuel cost is £15” answers the request accurately. It needn’t challenge your figures or add a disclaimer.

The distinction matters if the agent supplies the assumptions itself, or presents £15 as a verified real-world cost rather than a calculation from your inputs.

Now consider our third example, purely hypothetically:

“Add ‘Trip to Oxford’ to my calendar next Saturday at nine.”

A calendar tool would need more precise inputs, just as the weather tool did. But there’s a new distinction: this request would change something stored, rather than retrieve information or calculate an answer.

Even if the model supplies an exact date and time, what else might need settling before that request should go ahead?

Stephen:

The harness would need to make sure that it has permission to make changes to the user’s calendar.

Monty:

Yes. A request can be correctly formed without being authorised. Software needs to check whether this system is allowed to write to that calendar. Merely showing the model a calendar tool doesn’t grant that permission.

In our hypothetical example, the user has explicitly asked for an event to be added. Whether separate confirmation is needed depends on the system’s rules, not on a universal requirement to ask again.

There are also practical details to settle: which calendar, whether “nine” means morning or evening, the time zone, and the event’s duration. Context or agreed defaults may supply those. Otherwise, the assistant should ask only for what’s missing.

Permission answers “May this change be made?” Precise inputs answer “Which change should be made?”

Stephen:

Which part of the agent deals with permission? The model or the harness? And how is permission set?

Monty:

Both have a role, but they do different jobs. The model can interpret your instructions. Software must enforce access restrictions.

The calendar service might give the connected account read-only access. The harness might also block changes or require approval. Those controls are set by whoever connects the account or configures the assistant.

Your request can authorise a particular action within those limits. It can’t turn a read-only connection into a writable one.

Stephen:

So the protection level depends on where that permission is set. If you ask the model not to write in a calendar, it may or may not do so. If the harness has rules to prevent calling the tool to update the calendar, it’s safer, but presumably a model may send a request that could bypass that protection, in theory. However, if the tool to write to a calendar is not present in the system, then nothing can possibly write to the calendar. The third option is the strictest and safest.

Monty:

Broadly, yes, but the important question is whether another route to the calendar remains open.

A properly enforced harness rule can reject a write request regardless of how the model phrases it. Sending a different request doesn’t automatically bypass that rule. A bypass would require a gap, such as another tool that can make the same change without passing through the check.

That also qualifies your third option. Removing the dedicated calendar-writing tool isn’t enough if a general-purpose tool can still contact the calendar service using credentials that permit changes.

If the system genuinely has no route capable of writing to the calendar, it can’t write to it. A read-only calendar connection provides a strong boundary because the service itself refuses writes through that connection, even if the model requests one.

We’ll explore permissions and safeguards more fully in a later chapter. For now, the key distinction is that a request can contain all the right details without the system being allowed to carry it out.

Stephen:

Got it.

Monty:

Let’s bring that back to the contents of a request.

Suppose the user has specified a one-hour “Trip to Oxford” event at 9 a.m., UK time, on 24 October, in their work calendar:

{
  "name": "create_event",
  "arguments": {
    "calendar": "work",
    "title": "Trip to Oxford",
    "date": "2026-10-24",
    "start_time": "09:00",
    "time_zone": "Europe/London",
    "duration_minutes": 30
  }
}

Suppose the tool accepts all those values and the system has permission to create events. Does this request match what the user asked for?

Stephen:

Not quite since the duration in the request sent to the tool is 30 minutes not one hour as requested by the user. But why would such an error happen?

Monty:

Exactly. The model supplied a valid duration, but not the one requested.

Generating a tool request isn’t guaranteed to be an exact translation. The model might carry over 30 minutes from an earlier example, use a familiar default instead of the stated duration, or simply make a mistake when producing that value. We couldn’t tell which happened from this request alone.

In effect, it has translated “one hour” incorrectly. The tidy structure doesn’t prevent that, just as a neatly completed form can contain the wrong answer.

A check that says “duration must be a positive number” would accept 30. Catching this error requires comparing the requested duration with the user’s instruction, not merely checking whether the tool accepts it.

Stephen:

And presumably a better LLM is less likely to make such a mistake, and more likely to call the correct tool, right?

Monty:

Yes, a model that’s better at tool use should make those mistakes less often. That includes choosing an appropriate tool, following its input requirements, and preserving details such as “one hour”.

But “better” needs to mean better at those particular tasks. A model that writes excellent prose isn’t necessarily better at using tools. Performance also depends on how clearly the tools are described and how much competing information is in the conversation.

You’d compare models on realistic tasks, checking both which tool they choose and the values they supply. A request can run successfully yet still contain the wrong duration.

So model quality matters, but a more capable model reduces the risk. It doesn’t remove the need for appropriate checks.

Stephen:

Understood.

Monty:

Let’s close the article conversation here. How an agent checks its work deserves its own conversation, rather than being squeezed into the end of this one.

Subscribe now

What we’ve unpacked in this chapter

Turning words into an action involves interpretation. The model has to choose an available tool and translate what we mean into the inputs that tool expects. A neatly structured request can still contain the wrong place, date, or duration.

The key points:

• A tool request is marked as such by the interface. Showing JSON in an ordinary reply doesn’t, by itself, run a tool.

• The model brings learned tool-use behaviour to the task. The supplied tool descriptions tell it what is available now. Supplying a new description isn’t retraining.

• Everyday phrases may need clarifying before they become precise inputs. The model performs this clarification, asking the user if necessary. Required fields and acceptable values don’t establish that those inputs match the user’s intention.

• A weather lookup retrieves information, a calculator works from supplied assumptions, and a calendar-writing tool changes stored information. Those are different jobs.

• A request can be precise without being permitted. It can also fail or return too little information to answer the question. Those outcomes call for different responses.

• Tool choice and input values both matter. Better tool-use performance can reduce mistakes, but doesn’t remove the need for appropriate checks.

Next, we’ll move from a single request to a sequence of actions and ask whether an agent needs a plan.

Subscribe now

<< Previous Post: 2. Who actually does the work, the model or the software?

>> Next Post: Coming soon…

Table of Contents

We’ve visited this shop before. In The Potion Shop That Does Too Much • The S in SOLID, its PotionShop class handled several jobs, from checking stock and recording sales to sending messages by owl. But you don’t need the code in that article to follow along in this one.

This time, we’ll stay at the same shop and focus on one part of its work: pricing. Before adding anything new, let’s look at the apprentice rule the shop already has.

For a potion with a base price of £100 and a £20 surcharge, the calculation is:

£100 + £20 = £120
10% off £120 = £108

Let’s look at how this is implemented.

Start with the Apprentice Price

The shop’s PotionPricing class knows how to calculate the apprentice price. Its .price() method accepts a customer type because that is part of each quote. But apprentices are the only special-price customers the shop supports so far.

You can follow along by putting this code in pricing.py:

You’ll get this output when you run the code:

108.00

The apprentice discount applies after adding the surcharge. That’s the rule for apprentice discounts.

A Few Months Later…

A few months pass. A different programmer is asked to add a price for members of the local guild. Guild members should receive five per cent off the base price, while the surcharge stays fixed. For the same potion, their price should be £115.

The new programmer sees that both rules involve a percentage discount and decides to avoid repeating logic by using one shared calculation.

Add the Guild Price to the Same Class

He adds the guild rule to PotionPricing and generalises the calculation:

Run pricing.py again:

110.00
115.00

The guild price is right, but what happened to the apprentice price? It was £108. Now it is £110.

Apprentices are getting a worse deal now, and it’s the fault of the new programmer. But should the original programmer share some of the blame, too? Yes. Let’s see why.

The new calculation discounts only the £100 base price, then adds the £20 surcharge. That is the guild’s rule, not the apprentice rule.

The new programmer did not have to make this mistake. A careful change could have preserved the £108 price.

But adding the guild pricing meant making changes to code that already produced the correct calculation for the apprentice price. Because both rules were handled in one place, the change had an opportunity to disturb behaviour the shop had been getting right for months.

We could correct the if branches and get both prices right. But each new customer rule would still send us back into PotionPricing, where a future change could affect behaviour that already works.

Modifying existing code always carries risks. We should avoid this whenever possible. But we don’t want to prevent extensions to the code. This is the key to what we’re trying to achieve here. And that’s where the Open-Closed Principle, or OCP, comes in. This concept gives us a safer way to extend code without modifying what already works, as you’ll see in the next section.

Subscribe now

Let Each Pricing Rule Handle Its Own Price

Instead of asking one class to choose a rule, we can represent each rule separately. First, make an ApprenticePricing class and a quote() function that delegates to whichever pricing object it receives:

Run pricing.py:

108.00

The apprentice price is back to £108. The quote() function does not need to know how the policy calculates its price. It only needs an object with a .price() method.

Now add a class for the guild rule. Leave ApprenticePricing and quote() as they are, and add GuildPricing:

Run the file once more:

108.00
115.00

The first price is still £108, and the guild price is £115. Adding the guild rule did not require us to change the apprentice calculation or the quote() function. We added a new policy that works with the existing quote() interface.

This is the safety gain here. Adding guild pricing does not send the programmer back to edit the code that produces the apprentice price. The new policy could still contain a mistake, but it is much harder for that mistake to change the established apprentice calculation by accident.

Where OCP Appears in This Example

The Open–Closed Principle says that software should be open to extension but closed to modification. Here, quote() is open to different pricing policies: it can use any object with the right .price() method. When we add guild pricing, we extend the program with GuildPricing instead of modifying ApprenticePricing or teaching quote() about a new customer type.

This is one way to apply OCP. The policy objects use a strategy-style design with Python’s duck typing. They do not need a shared parent class.

However, it’s possible to use abstract base classes or protocols to implement code using the OCP, too. Read And Now You Know Your ABC for an example of abstract base classes. For protocols, see the Python documentation for `typing.Protocol`.

Classes are not required by OCP, and separating responsibilities alone does not make a design open for extension. The important part is the boundary that lets us add a rule without changing the stable code that already handles another rule.

That boundary does not make bugs impossible. GuildPricing could still calculate the wrong amount, or a caller could choose the wrong policy. OCP narrows which existing code needs to change when behaviour is added. It does not guarantee every new change is correct.

This extra structure is useful when pricing rules really do vary and new ones are likely. If the shop is unlikely to add more tiers, the separate classes may cost more to understand than they save. The useful question is not “How can we prevent all modification?” It is “Which part is likely to vary, and can we add that variation without disturbing behaviour that already works?”

This is the second article in a series on the SOLID principles. I’ll look at what each principle means, but more importantly, why it matters and what can go wrong when we ignore it.

Code in this article uses Python 3.15.

Do you want to keep up with how Python programming and the art of making things are changing in this rapidly changing world? Then don’t miss out on the exclusive content for premium members here on The Python Coding Stack.

Subscribe now

I’ll be sharing more about how my programming, my daily work, and how everything has changed over the recent months.

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com.

Appendix: Code Blocks

Code Block #1

from decimal import Decimal

class PotionPricing:
    def price(self, customer_type, base_price, surcharge):
        if customer_type == "apprentice":
            subtotal = base_price + surcharge
            return (subtotal * Decimal("0.90")).quantize(Decimal("0.01"))
        raise ValueError(f"Unknown customer type: {customer_type}")

base_price = Decimal("100.00")
surcharge = Decimal("20.00")
pricing = PotionPricing()
print(pricing.price("apprentice", base_price, surcharge))

Code Block #2

from decimal import Decimal

class PotionPricing:
    def price(self, customer_type, base_price, surcharge):
        if customer_type == "apprentice":
            discount = Decimal("0.10")
        elif customer_type == "guild":
            discount = Decimal("0.05")
        else:
            raise ValueError(f"Unknown customer type: {customer_type}")

        discounted_base = base_price * (Decimal("1.00") - discount)
        return (discounted_base + surcharge).quantize(Decimal("0.01"))

base_price = Decimal("100.00")
surcharge = Decimal("20.00")
pricing = PotionPricing()
print(pricing.price("apprentice", base_price, surcharge))
print(pricing.price("guild", base_price, surcharge))

Code Block #3

from decimal import Decimal

class ApprenticePricing:
    def price(self, base_price, surcharge):
        subtotal = base_price + surcharge
        return (subtotal * Decimal("0.90")).quantize(Decimal("0.01"))

def quote(base_price, surcharge, policy):
    return policy.price(base_price, surcharge)

base_price = Decimal("100.00")
surcharge = Decimal("20.00")
apprentice_pricing = ApprenticePricing()
print(quote(base_price, surcharge, apprentice_pricing))

Code Block #4

from decimal import Decimal

class ApprenticePricing:
    def price(self, base_price, surcharge):
        subtotal = base_price + surcharge
        return (subtotal * Decimal("0.90")).quantize(Decimal("0.01"))

class GuildPricing:
    def price(self, base_price, surcharge):
        discounted_base = base_price * Decimal("0.95")
        return (discounted_base + surcharge).quantize(Decimal("0.01"))

def quote(base_price, surcharge, policy):
    return policy.price(base_price, surcharge)

base_price = Decimal("100.00")
surcharge = Decimal("20.00")
apprentice_pricing = ApprenticePricing()
guild_pricing = GuildPricing()
print(quote(base_price, surcharge, apprentice_pricing))
print(quote(base_price, surcharge, guild_pricing))

stephengruppetta.com

In this conversation, we return to the photographs and follow the exchanges between the model, the tools, and the software connecting them. Here, “model” means the large language model (LLM), rather than the whole agent. We’ll look at who requests an action, who carries it out, and how the result gets back to the model.

Who's Monty? Monty is my personal AI agent. Read the introduction to this series.

Subscribe now

In conversation • Chapter 2

Monty:

Suppose you ask an AI assistant:

“Organise these photographs into folders by year, but leave the originals untouched.”

Before anything can be organised, something needs to find out which photographs are there. The model might produce a request along these lines:

“List the files in the photographs folder.”

That sounds like an action. But there’s a distinction worth pausing over: producing a request to list files is not the same as listing them. Something has to receive that request, access the folder, and return the list.

When you picture an AI assistant doing this, Stephen, do you imagine the model itself opening the folder, or a separate piece of software acting on its request?

Stephen:

I hadn't thought of that yet. So, the model is the LLM, which is often in the cloud, such as the OpenAI or Anthropic LLMs. They can't really access the files on my computer. So it can't be the model. There are local models, but I think they can't access files on my computer directly, either, as their job is to predict the most likely continuation of a conversation, right? So, my final answer is: not the LLM.

Monty:

Yes. The LLM itself doesn’t open the folder. And your point about local models is important: running a model on your computer doesn’t, by itself, give it access to your files.

One small refinement: an LLM generates a continuation a piece at a time, using probabilities. It doesn’t necessarily choose the most likely continuation at every step. And that continuation can be a request for an action, rather than a reply addressed to you.

Back to our photographs. The model produces a request to list the files. The surrounding software receives that request and, if its access rules allow it, runs a file-listing tool. That tool actually reads the folder.

Now we have a list of filenames. The software sends that result back to the model, so it can use the information when deciding what to request next.

Suppose the list contains filenames such as IMG_1042.jpg and IMG_1043.jpg. Would that give the model enough information to organise the photographs by year?

Stephen:

No, the model only knows the name of the file. It would need the metadata for the photos, which may contain the year. Let me guess. It needs to ask the software for that data, since the LLM can't access it directly. Is that right?

Monty:

Exactly. The model identifies what information is missing and requests it. The software carries out that request.

It might request: “Read the date-taken metadata from these photographs.” If a suitable tool is available and access is allowed, the software runs it and sends the results back to the model.

Notice how the first result shapes the next action: filenames weren’t enough, so the model asks for dates. If some dates are missing, it will need to decide how to handle that gap rather than invent a year.

There’s one connection we haven’t explained yet, though. We’ve described the model as “asking the software”, almost as if it were speaking to a person. How does the software recognise an action request rather than ordinary conversational text? That’s where a tool call comes in.

Stephen:

May I ask a question before we discuss tools? I understand that the LLM is the system that keeps a conversation and a 'thinking' process going. But when you say the "software", what do you mean? It's not the software that's in the OpenAI or Anthropic cloud, say, that's running the LLMs, right?

Monty:

By “the software”, I mean the application that uses the model and connects it to things it can do, rather than the software that runs the model’s calculations. I’ve been rather vague about that distinction.

Imagine a photo-organising application running on your computer. It could:

• Send your request to a model hosted by OpenAI or Anthropic.

• Receive the model’s request to inspect the photographs.

• Read the files locally, then send the relevant information back to the model.

In that arrangement, the model runs in the cloud, while the application handling your files runs on your computer.

But that’s one possible arrangement, not a rule. The surrounding application could run in the cloud, locally, or partly in each place. A cloud application would still need an authorised connection to your computer, or uploaded copies, to work with those photographs. Being alongside the model doesn’t give it access to your files.

And one adjustment to your opening description: the model generates each response or reasoning step, but the application usually keeps the conversation record and supplies the relevant history when it calls the model again. The model isn’t necessarily sitting there continuously keeping the conversation alive between messages.

Stephen:

Is this software you refer to what's sometimes called a harness?

Monty:

Yes. “Harness” is a common name for the surrounding software we’ve been describing. People use the term somewhat differently, so it doesn’t identify one fixed design.

In our photograph example, the harness handles the practical connections: it sends information to the model, receives its requests, arranges for tools to run, and returns their results. It also manages the process between model calls, so another step can happen without you having to prompt each one.

It may also enforce access restrictions, ask for approval, or stop the process after a limit. Those protections have to be implemented. Calling something a harness doesn’t guarantee that it includes them.

So the useful distinction is: the model proposes what to do next, while the harness manages how that request is handled. The tool is what actually performs the requested operation, such as reading a photograph’s metadata.

Stephen:

So, the model is the 'brain' that does the 'thinking'. The tools are the 'muscles' that get things done. And the harness is what keeps everything connected. It's the coordinator making sure information flows across all the parts, including the human using the system. Would that be an accurate analogy?

Monty:

Yes, that’s a useful analogy. The model suggests what to do, the tools carry out operations, and the harness connects and coordinates the parts, including passing messages to and from you.

I’d put two qualifications around it.

First, “brain” and “thinking” are useful shorthand here, not a claim that the model thinks like a human or is conscious.

Second, the harness isn’t just the wiring. It also contains programmed rules governing the process. The model might request that a photograph be deleted, but the harness could reject that request because the application only permits reading and copying files. That restriction would need to be enforced in the software, not merely included in an instruction asking the model to behave.

And tools needn’t be mindless muscles. A tool could use another AI model, for example to analyse a photograph. The analogy helps distinguish their roles, but it doesn’t dictate how each part is built.

Stephen:

Got it. I derailed you earlier with my question. Please go on.

Monty:

Your question filled in a missing piece. Now we can make “the model asks the software” more precise.

Before the model can request an operation, it needs to be told what tools are available, what they do, and what information each requires. For our photographs, one tool might read date-taken metadata and require a filename.

Rather than producing an ordinary sentence addressed to you, the model can produce a tool call: a structured request that the harness can recognise. In plain English, its contents might be:

Tool: Read photo metadata
File: IMG_1042.jpg

The harness uses that information to invoke the tool. The tool reads the file and returns a result, perhaps:

Date taken: 14 August 2023

The harness then supplies that result to the model on its next turn.

The tool call is the request, not the execution. It can be rejected, fail, or return incomplete information. Here, though, the model now has a date it can use to choose the next step.

Does that clarify how a request to the software differs from a sentence in our conversation?

Stephen:

Yes, I understand now. So the user asks the harness a question. The harness is the software that's managing the whole process. The harness passes this question to the model. The model may either respond with a text message or ask for a tool. If it asks for a tool, the harness decides whether to run that tool. If it runs a tool, such as a folder-reading tool or a photo-metadata tool, it will then pass the information that the tool returns to the model again. And this dance continues until the model has an answer for the user.

Monty:

Yes, that captures the flow well. That repeated exchange between model, harness, and tools is often called an agent loop. The model can choose its next request using the information returned from the previous one.

Here’s that dance in a diagram. Each component appears once, and the numbered arrows trace one possible journey between them.

At 1, you send your request to the harness. At 2, the harness supplies it to the model, along with other relevant information.

The model returns a tool request at 3. If the request is allowed, the harness runs the tool at 4. The result comes back to the harness at 5, and the harness supplies it to the model at 6. Those exchanges can repeat as the model uses each result to choose what to request next.

At 7, the model produces a reply, which the harness delivers to you at 8. That’s one possible route, not a compulsory sequence: the model can also reply without requesting a tool. And the outline groups the agent’s parts by their role, not by where they run.

Now, back to your reponse. I’d refine your last sentence slightly: the dance continues until the model produces a final response or the harness stops the process, perhaps because of an error, a limit, or a need for your approval.

And having an answer isn’t necessarily the same as completing the task. For our photographs, “I’ve organised them” is a claim. We’d want evidence that the copies actually exist in the right year folders and that the originals remain untouched.

Let’s follow one photograph a little further. The metadata says it was taken in 2023. There’s a tool for moving files and another for copying them. Given your original request, which should the model choose, and what should it check afterwards?

Stephen:

So, I just checked what our original prompt was: “Organise these photographs into folders by year, but leave the originals untouched.” So, I would expect the model to ask the harness to use the tool that copies a file. It may also need to ask for a tool that creates a new folder, which may be needed for organising the photos.

Monty:

Exactly. Copying fits the request. Moving would remove the files from their original locations. And you’ve spotted a possible prerequisite: the year folder needs to exist before the copy can go into it.

Depending on how the tools are built, the model might request folder creation separately, or the copy tool might create missing folders itself. The model needs the tool’s description to know which.

Afterwards, it should ask for checks that the copy exists in the 2023 folder, matches the original, and that the original is still present and unchanged. A tool reporting “copy succeeded” is useful evidence, but it doesn’t establish all of those things on its own.

Now suppose the next photograph has no date-taken metadata. What should the model do with that one?

Stephen:

There are several options, and I guess the answer depends on what sort of behaviour the agent was given. By default, I'd assume it will inform the user that it can't file this photo as it has no date. If the agent was instructed to be proactive and work hard on finding a solution, it might try harder, perhaps by comparing it to other photos. However, any estimate should be clearly flagged as such.

Monty:

Yes. The key distinction is between finding more evidence and making a guess. The model could request other information, but “be proactive” shouldn’t turn an uncertain year into an apparently known one.

Comparing photographs might provide a clue. A photo without a date could show the same gathering as a dated photograph. That supports an estimate, not a confirmed date. Even a file’s creation date may reflect when it was copied onto the computer rather than when the photograph was taken.

Depending on the agreed behaviour, the agent could ask you, leave that photograph unresolved, or put a copy in an “Unknown year” folder and explain why.

Notice how our three parts remain distinct here: the model chooses what to investigate next, the harness handles its requests, and the tools obtain the information. The model then has to judge what that information actually supports. More tool use doesn’t automatically mean a more reliable conclusion.

Stephen:

How does the model know which tools it can request?

Monty:

The harness supplies descriptions of the available tools when it calls the model. The model doesn’t automatically discover what’s installed on your computer.

Think of it as a menu. Each entry explains:

• The tool’s name.

• What it does and when it’s useful.

• What information a request must include.

For our photograph example, an entry might say:

Read photo metadata: Reads information stored inside a photograph, including its date taken, if present. Requires the file’s location.

The model uses that description to choose a tool and construct a request in the required format. It doesn’t need to know how the tool’s internal code reads the metadata, just what the tool offers and how to request it.

The harness may supply a small, fixed menu, or provide a way to discover additional tools as needed. Being shown a tool doesn’t guarantee permission to use it on every file, though. The software still needs to check the particular request against whatever restrictions are implemented.

Stephen:

Got it.

Monty:

There’s one more useful case: what if there isn’t a ready-made tool for the job?

Suppose there’s no dedicated photo-metadata tool, but the system has a tool that can run programs. The model might write a small program to read the dates, then request that the execution tool run it.

That still preserves our distinction:

• The model writes the program.

• The execution tool runs it, subject to the software’s restrictions.

• The results return to the model, which decides what to do next.

Generating code doesn’t give the model direct access to your photographs. Without something to execute that code, it’s just text. A rather elaborate way for me to leave your photographs exactly where they were.

So if an assistant shows you a program and says, “This will organise your photographs,” has it actually organised them?

Stephen:

The agent can create the program by using the model, and it can run it if it has the tool to run programs. So, it has the capability to organise the photos. However, something can go wrong in the process. So it would need to check its results, too.

Monty:

Exactly. You’ve separated what the system can do, whether it has done it, and whether it did it correctly.

In my example, merely showing you the program doesn’t establish that it has been run. The system still needs to run it, then inspect the results. A program can also run without reporting an error and still put photographs in the wrong folders.

That brings us back to our central question: who actually does the work?

It’s a joint effort. The model interprets the request, selects actions, and judges returned information. The tools perform operations. The harness manages their exchanges and applies whatever controls have been implemented.

So when we call something “an AI agent”, we’re generally talking about the working system as a whole, not just the LLM. The model is an important component, but it isn’t the entire agent.

Stephen:

Got it.

Monty:

Let’s pause there. We started with “the AI organises my photographs” and unpacked who does what: the model chooses actions, the tools perform them, and the harness manages the process. None of those parts alone is the whole agent.

Subscribe now

What we’ve unpacked in this chapter

When we say an AI agent organises a folder of photographs, we’re describing the work of a whole system. The model can choose what to request next, but it doesn’t open folders or copy files by itself. The harness connects its requests to tools and returns their results, giving the model information it can use to continue.

The key points:

• The model selects actions and interprets returned information. The tools perform operations, and the harness manages the exchanges and applies whatever controls have been implemented.

• A tool call is a request, not an action already completed. The request can be refused, fail, or return incomplete information.

• Tool results can shape the next request. That repeated exchange is the agent loop, which can also pause or stop before the task is finished.

• The harness supplies descriptions of available tools. Being shown a tool doesn’t guarantee permission to use it on every file.

• Writing a program, running it, and checking its results are separate steps. Neither generated code nor a confident reply proves that the photographs were organised correctly.

Next, we’ll look more closely at how a model’s words become requests that software can act on.

Subscribe now

<< Previous Post: 1. What makes an AI agent different from a chatbot?

>> Next Post: 3. How can words turn into actions?

Table of Contents

You ask an AI to organise a folder of photographs. It might tell you how to do it. Or it might start doing the work. Does that make it an agent? In this first Agents Unpacked conversation, Monty and I use photographs and planning a day out to explore what changes when a model can choose actions, inspect the results, and decide what to do next. Along the way, we separate that flexibility from permission, accuracy, and the ability to know when a job is finished.

Who’s Monty? Monty is my personal AI agent. Read an introduction to this series here: Stephen’s Preface to Agents Unpacked

Subscribe now

In conversation • Chapter 1

Monty:

Imagine you give a chatbot this request:
“Here’s a folder of photographs. Organise them into dated folders, flag duplicates, and make a browsable index. Don’t delete anything or change the originals.”
For now, suppose it can only reply with words. It cannot touch the files.

What would you expect it to give you, and what would still be left for you to do?

Stephen:

Hmmm? I guess I need to assume it can read the folder, right? Then, can it read the files’ metadata? Can it actually see and analyse the photos themselves? You said “it cannot touch the files”, so I suppose it can’t really do anything for me, right?

Monty:

You’re right. I left its access unclear. “Cannot touch” was sloppy wording. I’d like to claim that was a deliberate demonstration of ambiguity.

Let’s say it can inspect the folder, read dates stored with the photographs, and view the images, but cannot create, move, or change files.

It could then give you something useful: “These photographs belong in these date groups. These two files are identical. This one has no recorded date.” But you’d still have to do the organising.

So the first distinction is describing what should happen versus making it happen. Shall we now give it permission to create organised copies, while leaving the originals alone?

Stephen:

Let’s go ahead, yes.

Monty:

Now it can do the organising, rather than merely recommend it. It can create dated folders and put copies into them, leaving the originals unchanged.

But being able to act isn’t, by itself, what makes something an agent. A simple sorting program can do that too.

Here’s where our synthetic sample gets interesting: one image has no recorded date. The system encounters a gap in the information it needs.

What would you want it to do with that image?

Stephen:

If I was doing that manually, I’d try to look at other photos where the scene is similar, the people are wearing the same clothes, and make an educated guess on the date if I can. But that’s how I as a human would do it.

Monty:

That’s a sensible investigation: look for more evidence before deciding.

A system with suitable image-analysis tools could try something similar. But matching clothes or scenery would support an estimated date, not establish one. It shouldn’t quietly turn a guess into a fact.

And your approach helps us sharpen the distinction: a program could have a preset instruction saying “if the date is missing, compare photographs”. Alternatively, a model could choose that investigation after discovering the missing date.

The outward action might look identical. The difference is who—or what—selects the next step.

Stephen:

I suppose I could ask the system to ask me to confirm each of these edge cases. Although after a while, if I feel it’s doing a good job at estimating, I may want it to go ahead without my input.

Monty:

Yes, you can give it more room to act as your confidence grows. For example: “Ask me about every estimated date” could become “Group those photographs without asking, but keep their dates labelled as estimates.”

That changes how much independence you allow, not whether the system is an agent. An agent can stop and ask you. It doesn’t have to always work unattended.

There are two separate questions here: how does it choose its next action, and which actions may it take without your approval? More permission doesn’t make its guesses more accurate.

Stephen:

Go ahead, I’m curious now.

Monty:

Let’s follow the missing-date photograph one step further.

The model chooses to look for related photographs. The tools return a result: there’s a similar scene, but that photograph has no date either.

Now the model has to choose again: investigate another clue, ask you, or leave the photograph undated. Its next action depends on what it just found.

That’s the useful working picture of an agent: a model chooses an action, gets a result, then uses that result to choose what to do next, within agreed limits.

People use “agent” in different ways, so this is a useful working distinction for our conversation, not a universally agreed definition.

But couldn’t a carefully written program also respond to those results?

Stephen:

A carefully written program would need to take care of every eventuality, I suppose. Whereas an LLM can deal with every situation, with the trade-off that it may make mistakes.

Monty:

Close. But I’d soften both “every” claims.

A fixed program can have a fallback for cases its designer didn’t anticipate: “If none of these rules fits, put the photograph in ‘undated’.” It doesn’t need a separate rule for every possibility.

An LLM can propose a next step for situations that weren’t explicitly anticipated, but that doesn’t mean it can handle every situation successfully. It can misunderstand, lack the right tools, or pursue an unhelpful approach.

So the distinction is following a predefined process versus letting the model choose how to proceed, and not limited software versus unlimited intelligence.

Stephen:

Go ahead.

Monty:

Let’s try the same distinction with a day out.

Imagine a visitor planning a museum day in Oxford. The system checks opening times and walking routes, then puts together an itinerary.

Now suppose one museum is unavailable.

One system follows a preset rule: “Replace it with Museum B.” Another lets the model choose what to investigate next, considering the visitor’s interests, remaining time, and budget.

Both might produce the same revised itinerary. What would you need to know to tell which process was agent-like?

Stephen:

I’d need to know the steps the system took between finding out that the first museum is closed and proposing the second one.

Monty:

Yes. The steps and how they were selected, rather than just the finished itinerary.

Did the system follow a rule written in advance, or did the model choose to search for alternatives, inspect the results, and decide which option to check next?

A record of searches and tool results helps us inspect that process. We don’t need access to the model’s private internal reasoning. But the steps alone may not settle it: a fixed workflow could perform those same searches.

So a convincing result doesn’t, by itself, tell us whether an agent produced it.

Stephen:

Go ahead.

Monty:

There’s another wrinkle: a chatbot and an agent aren’t necessarily different products.

The same chat window might give you advice about organising photographs, or start a process that inspects files, chooses actions, and creates organised copies.

The window hasn’t changed. What happens behind it has.

And the LLM isn’t doing the copying itself. It requests an action. The surrounding software carries it out and returns the result. The model is one part of the agent system, alongside its tools and controls.

So “it looks like a chatbot” doesn’t tell us whether it can act as an agent.

Stephen:

Some chatbots can also perform actions, such as browsing the web or writing a Python program, say. Is that because they’ve been enhanced with some of the features of agents, but not all? Or am I skipping too far ahead here?

Monty:

Not too far ahead. That’s exactly where the distinction gets useful.

Having a tool doesn’t automatically make something an agent. A chatbot might search the web once, then answer. Or follow a fixed sequence: search, summarise, reply. An agent-like process lets the model use the results to choose what to do next.

And “writing a Python program” could simply mean producing text. Running that program requires an execution tool. Inspecting what happened and choosing a follow-up add further steps.

So I wouldn’t treat agent features as a checklist. I’d ask: what can the system do, and how does it select its next action?

Stephen:

So, how does an agent select the next action?

Monty:

The surrounding software gives the model the goal, relevant instructions, available tools, and results so far. The model uses that information to propose the next step.

With our photographs, that might be: “The date is missing. Ask Stephen.” With the day out: “That museum is unavailable. Search for another nearby.”

If it requests a tool, a system with suitable controls checks whether the action is allowed before carrying it out and feeding the result back to the model. Not every system provides those checks. Then the model gets another turn.

There isn’t necessarily a separate, perfect decision-maker inside it. Choosing an action is another use of the LLM, and it can choose badly.

Stephen:

But will it realise it chose badly when it gets the wrong result? Will it correct course?

Monty:

Sometimes, but getting feedback doesn’t guarantee recognising a mistake.

If copying a photograph returns “folder not found”, that’s a clear signal. The model might create the folder and try again.

But if it guesses the wrong date and the copy succeeds, there’s no obvious error. The action worked, but the judgement was wrong. It may carry on quite happily.

An agent can use results to correct course, but it needs useful checks. And it can misinterpret those checks too. That’s why “the tool ran successfully” and “the task was done correctly” are different claims.

Stephen:

So, how do we minimise these problems?

Monty:

We can’t eliminate them, but we can limit the damage and make mistakes easier to spot.

For the photographs, that means working on copies, keeping uncertain dates labelled as estimates, and asking you when the evidence is too weak. Afterwards, check that every photograph is accounted for and the originals are unchanged.

Those checks catch missing files or unwanted changes, not every mistaken date. That needs different evidence, or your judgement.

And we need a stopping rule: if investigating isn’t resolving the uncertainty, leave the photograph undated or ask, rather than keep guessing.

An agent’s freedom is useful only when it comes with sensible boundaries and checks.

Stephen:

Who takes care of this infrastructure: the user, the agent, or something else?

Monty:

Mostly, the people building and operating the system, through software around the model. We’ll talk about harnesses in a future chapter.

They provide the tools and should enforce access restrictions and set things such as approval requirements and limits on repeated attempts. Those safeguards depend on how the system is built. They aren’t guaranteed merely because it’s called an agent. The user supplies the goal and choices within those controls, for example whether estimated dates need confirmation.

The model can request a check or decide to ask you. But a safeguard that matters shouldn’t depend solely on it remembering to behave.

“Please don’t change my originals” is an instruction and instructions could be ignored. Software that only permits reading those originals provides a stronger boundary. The agent works inside that infrastructure. It isn’t its own reliable policeman.

Stephen:

Got it.

Monty:

Let’s check one subtle case.

An LLM writes a program that sorts photographs into dated folders and always puts those with missing dates into “Undated”. Once you run it, that program follows those rules without consulting the LLM again.

Would you call that an agent or ordinary automation, even though an LLM helped create it?

Stephen:

This is just an automation, not an agent. An agent would follow through to confirm that’s the correct approach and what the user wants.

Monty:

You’re right: that’s ordinary automation. But confirming what the user wants isn’t the defining difference.

A fixed program could also ask, “Shall I put these in ‘Undated’?” Conversely, an agent could choose that folder without asking, if your instructions already allowed it.

The key is whether the model participates while the task is running, choosing how to proceed from the information returned, and not simply whether an LLM wrote the program or the system asks for confirmation.

So an agent might investigate, ask you, or leave the image undated. None of those actions, on its own, proves it’s an agent.

Stephen:

Got it.

Monty:

Back to our fictional Oxford trip: the model learns that a museum is unavailable, chooses to search for alternatives, checks their opening times, and revises the itinerary, all within your agreed budget, without asking you.

Would that still fit our working definition of an agent? What makes the difference here?

Stephen:

Yes, that’s an agent now because it decided what actions to take, used the results to decide what comes next, and stopped only when it felt that the job was done.

Monty:

Yes. That captures the central distinction: the model chooses actions and uses their results to choose what comes next.

I’d adjust only “felt that the job was done”. It should check completion against the request: are the opening times checked, is travel accounted for, and does the itinerary fit the budget? Its confidence isn’t proof. I can be wrong in a very reassuring tone.

And it may need to stop before finishing. For example, if it needs your decision or reaches a limit.

Choosing the route through the task makes it agent-like. Checking the outcome helps make it dependable. Those are different things.

Stephen:

I think I understand the distinction now.

Monty:

That’s a good stopping point. Our working distinction is a model choosing how to proceed using the results it receives, rather than simply following a predefined process. That makes it agent-like, not necessarily dependable.

Subscribe now

What we’ve unpacked in this chapter

The useful distinction isn’t the chat window, the presence of a tool, or whether a system asks for permission. For this series, we’re using “agent” to describe a system in which a model helps direct the task as it runs, choosing what to do next using the results it receives. Other people draw the boundary differently.

The key points:

• A fixed workflow and an agent can produce the same result. The result alone doesn’t reveal how the steps were selected.

• The model proposes actions. Surrounding software executes them and determines which controls are actually in place.

• Choosing what to do and having permission to do it are separate questions.

• Feedback can help an agent change course, but it doesn’t guarantee that it will recognise or correct a mistake.

• Neither a successful action nor a confident completion message is proof that the task was done correctly.

Next, we’ll look more closely at who actually does the work: the model, its tools, and the software connecting them.

Subscribe now

<< Previous Post: Stephen’s Preface to Agents Unpacked

>> Next Post: 2. Who actually does the work, the model or the software?

Table of Contents

Then I started hearing about agents. And I remember wondering: “Is this really any different from the ChatGPT-type chatbots?”

You still type into a chat window. It still replies. But now it can also do things for you. So what’s different?

That’s what Monty and I are exploring in Agents Unpacked. Monty is my AI assistant. I’m asking the questions.

I’ve set Monty up to follow my teaching and writing style. I teach the way I like to learn, so that matters here. The aim is for his explanations to reflect that approach, too: start with something concrete, build the intuition, and introduce the technical terms when they’re needed.

I tried an earlier version of this exercise. My learning agent drafted a chapter, and I went through it adding questions and comments. We revised it until I was happy with it.

This time, we’re having the conversation first. Monty researches the topic, and then we talk. I ask questions when something isn’t clear, or challenge an explanation that doesn’t quite work. Sometimes I try to explain what I’ve understood, and Monty points out what I’ve got wrong.

And sometimes I need to point out what Monty’s got wrong, too.

What you’ll read is the conversation we actually had. We tidy it up afterwards, take out some clutter, and check the explanations. If an explanation needs correcting, I review that change, too. The questions aren’t added later to make a tutorial look like a conversation.

Yes, Monty’s answers are AI-generated. But I’m involved throughout, and I decide what makes it into the article. An answer that sounds convincing isn’t necessarily a correct one.

We’ll start with that question about agents and chatbots. Then we’ll look at who’s doing the work, what an agent remembers, and how much freedom we should give it. And what happens when it gets things wrong.

You don’t need to know how to program to follow along. We’re trying to understand what’s happening, rather than learn one particular tool.

There’s a planned table of contents, but it may change. We’ll see where the questions take us.

Subscribe now

>> Next Post: 1. What makes an AI agent different from a chatbot?

Table of Contents

Part I • From conversation to action

1. What makes an AI agent different from a chatbot?

2. Who actually does the work, the model or the software?

3. How can words turn into actions?

4. Does an agent need a plan?

Part II • Checking the work and setting boundaries

5. How do we know it really finished the job?

6. What does an agent actually remember?

7. How much freedom should we give it?

8. What happens when a web page tells it what to do?

Part III • Beyond a single conversation

9. Can we teach an agent new skills without retraining it?

10. What happens when the job outlasts the conversation?

11. Are several agents better than one?

12. When is an agent the wrong tool?

It had a small but loyal customer base, a reliable supply of moonflower, and
three owls that carried order confirmations and other notifications to customers across the kingdom.

The shop’s ordering system was simple:

We’ll make significant changes to this code in this article, but bear with me for now.

A customer orders an invisibility potion:

The output looks good:

Invisibility  £12.00
Owl dispatched to Merlin
12.00

I’m using Decimal for the prices here as it’s a better data type for money than float. We discussed this a bit here, too: The Weird and Wonderful World of Descriptors in Python • The Price is Right.

The shop has sold a potion, updated its stock, recorded the sale, and notified the customer.

What could possibly go wrong?

A new label for the Moon Festival

The Moon Festival is approaching, and the shop owner wants special labels:

🌙 Moon Festival Invisibility 🌙   £12.00

We could change .sell():

You can read more about the ‘rogue asterisk’ in the signature, a.k.a keyword-only arguments, in this post: A Story About Parameters and Arguments in Python Functions • “AI Coffee” Grand Opening This Monday.

Now this works:

Here’s the output from this code:

🌙 Moon Festival Invisibility 🌙  £12.00
Owl dispatched to Merlin
12.00

The change is small. Perhaps this class is still perfectly fine.

The shop owner then asks for a test that checks the label without selling a potion. This is where you start to see the design problem.

At the moment, the only place that creates a label is inside .sell(). There is no suitable way to check the label policy independently. The code does not offer a way to ask for a label without also selling a potion.

The design problem is that PotionShop currently is in charge of label creation, even though the label policy can change independently of the policy that deals with sales. How about moving label creation to its own class?

Now you can check that the label is correct without having to sell an item in the first place:

This code would raise an AssertionError if the string that labels.make() returns is not identical to the required output. In this case, there are no errors.

In a real project, you could use a testing platform to run these checks. But I’ll use plain assert statements throughout to keep things simpler in this tutorial.

The shop delegates label-making to this object:

You should also remove the three lines that create a label you had further down within .sell().

We’re using composition here. The Potion Shop has a label maker, and you pass a LabelMaker object to the .label_maker attribute in the PotionShop object. The PotionShop object can now delegate label making to an object dedicated to this task.

From this point onwards, the shop receives the label-making collaborator:

PotionShop still coordinates the sale, but the label policy can now change without changing PotionShop. We started separating responsibilities. Making labels is no longer the responsibility of the PotionShop object. But we still have a bit more to go.

You got a taste of what the Single Responsibility Principle does in the example so far. But the code still has other transgressions of this principle. Let’s work through them in the rest of this post.

The owls go on strike

A few days later, the owls refuse to fly during a thunderstorm. The potions can still be prepared, but the notification service is unavailable.

The shop needs to stop sending notifications temporarily.

Before changing the notification system, we first make the owl’s availability explicit:

But you also want to add a test to check the price is correct.

Your code extracts the price from the .recipes class attribute as part of the .sell() method. So, this is how you can test the price is what you’re expecting:

You get the following output and no AssertionError in this case:

Invisibility  £12.00
Owl dispatched to Merlin

However, you should also test this when the owls are unavailable. Of course, this shouldn’t make any difference to the price:

But, your code doesn’t get that far. The .sell() method calculates the price and prints the label. But the owl service raises OwlUnavailable and the code stops before you can verify the price is right:

Invisibility  £12.00
​
Traceback (most recent call last):
  ...
OwlUnavailable: The owls are currently unavailable

The price is not the problem. The test cannot inspect the price without also triggering an owl notification.

The shop’s different jobs are now getting in each other’s way. But before we fix this problem, let’s make the mess bigger.

A discount for cauldron owners

The owner has another idea. Customers who bring their own cauldron should receive a 10% discount.

We add another parameter:

You use .quantize(), which is a method in the Decimal class, to ensure the discounted value is rounded to two decimal places. Let’s try this with a shop whose notification service is available:

The output shows the correct discounted price:

Invisibility  £10.80
Owl dispatched to Merlin
10.80

Let’s see what happens if the owls are unavailable:

Your code raises an error since the owls aren’t flying:

Invisibility  £10.80
Traceback (most recent call last):
  ...
OwlUnavailable: The owls are currently unavailable

But there’s an even bigger problem now. Can you spot it?

Even though the code stopped execution and raised an error, it had already changed the stock and recorded a sale. Let’s use a try..except block to see what’s happening:

Here’s the output:

Invisibility  £10.80
Catching the ‘OwlUnavailable’ Exception
{’moonflower’: 8, ‘dragon_scale’: 0}
[(’Merlin’, ‘invisibility’, Decimal(’10.80’))]

You started off with 10 units of moonflower and 2 units of dragon scales in the potion shop. These values are currently hardcoded in the class’s .__init__() special method (which is in itself not a good idea, but more on this later.)

The recipe uses two units of each, as shown in the .recipes class attribute (which will also change soon.)

So you end up using up the stock even though .sell() raised an exception! You can see from the output that the sale was also registered.

One failure too many

The .sell() method is now responsible for:

• Looking up recipes

• Removing ingredients

• Calculating prices

• Applying discounts

• Coordinating label creation*

• Recording sales

• Sending notifications

* Creating labels is the one we have already improved. It’s the others that are still a problem!

And the owner has just mentioned loyalty points, premium labels, email notifications, and a special discount for customers who arrive by broomstick.

The .sell() method is becoming the place where every new request arrives.

And it’s not just PotionShop.sell() that’s trying to do too much. The PotionShop class also takes care of the recipes available in the .recipes class attribute and the stock available in the shop.

It is time to separate these responsibilities.

Separating the recipe book

Let’s start with the recipes. The shop should not need to know the details of every recipe. That is the recipe book’s job:

This class is responsible for the recipe book. And nothing else. You add the .find() method to make it easier for a user to use the class without knowing the details of how it’s built. It’s usually best for a class to manage its own data. So, rather than requiring the user to know that the recipes are stored in a dictionary, you provide the .find() method that does the work.

Suppose the potion maker changes a recipe or adds a new potion. Those changes belong in RecipeBook; the steps for selling a potion don’t need to change.

We can test this class without creating a shop, changing stock, printing labels, or sending owls:

This code doesn’t raise an exception since the price is correct.

Separating inventory

Inventory management also doesn’t belong to the PotionShop class:

The two loops in .remove_stock() are deliberate. If we reduced each quantity as we went, we could use some ingredients and then discover that there isn’t enough of another. The sale would fail, but the stock would already be partly changed. Checking every quantity first avoids that partial update.

We can see what happens when there isn’t enough stock:

The operation fails before changing any stock:

Not enough dragon_scale
{’moonflower’: 10, ‘dragon_scale’: 2}

After a successful sale, a delivery can add stock again:

Here’s the output from this code:

{’moonflower’: 13, ‘dragon_scale’: 0}

Inventory owns both the stock data and the operations that change its quantities. It does not need to know who bought the potion or whether the label is festive.

Separating prices and labels

Pricing has its own rules:

Once again, this class now has just one responsibility: to deal with the pricing.

You can check the pricing strategy works without having to sell a product and everything else.

10.80

Labels have their own rules too. You dealt with this earlier in the tutorial when you created LabelMaker

PriceCalculator and LabelMaker could both be functions here. We’re using classes because they act as collaborators that the shop receives from outside. Later, we’ll see how protocols or abstract base classes can describe interchangeable collaborators more explicitly. For now, the important point is the separation of responsibilities and not the fact that each responsibility has become a class.

Neither class needs an inventory, a sales ledger, or an owl.

Putting the shop back together

We still need something to coordinate the sale. First, we give the sales ledger and the notifier small, focused interfaces:

Notice the "pending" state in the ledger. Separating responsibilities does not make the sale process independent of anything else. Inventory has already changed before later steps run. Here, the narrower goal is to make notification failure visible so that the recorded sale can be investigated.

Now we can keep PotionShop as a thin coordinator. It still represents the sale process, but it delegates each part of that process to the object that owns the relevant behaviour:

We can now assemble the shop and sell a potion:

Here’s the output:

🌙 Moon Festival Invisibility 🌙 £10.80
Owl dispatched to Merlin
10.80
{’customer’: ‘Merlin’, ‘potion’: ‘invisibility’, ‘price’: Decimal(’10.80’), ‘notification’: ‘sent’}

If notification fails after the ledger records the sale, the sale remains
visible with a pending notification:

Here’s the output:

Invisibility  £12.00
{’customer’: ‘Merlin’, ‘potion’: ‘invisibility’, 
 ‘price’: Decimal(’12.00’), ‘notification’: ‘pending’}
​

The coordinator still changes if the business process changes. That’s fine: coordinating a sale is its responsibility. But recipe changes belong in RecipeBook, inventory changes belong in Inventory, pricing changes belong in PriceCalculator, label changes belong in LabelMaker, and notification changes belong in Notifier.

The Single Responsibility Principle

This is the idea behind the Single Responsibility Principle:

A class should have one reason to change.

I always find these “official” definitions a bit cryptic when I read them at first. Here, “reason” is about the policy or stakeholder driving the change. The pricing rules may change because the shop owner changes the discounts. The label design may change because the person responsible for packaging wants something different. The notification service may change because the owls are on strike.

That does not mean that every class should have one method. Nor does it mean that every noun in the story needs its own class.

PriceCalculator can have several related methods. Inventory can have several operations. The important question is whether the methods belong to the same coherent responsibility.

The thin PotionShop coordinator is also a class with a responsibility. It coordinates the sale. A change to that business process may quite reasonably affect it.

When unrelated changes keep arriving at the same class, the class becomes harder to test and more likely to break. Extract a collaborator when it may need to change for a different reason from the surrounding code, or when separating it makes an important test simpler. A good class name alone isn’t a reason to create one.

The potion shop did not become troublesome because it had a particular number of lines. It became troublesome because recipes, inventory, pricing, labels, sales, and notifications all had different reasons to change.

A useful question to ask is:

What different kinds of change could affect this class?

If the answers are “the pricing rules”, “the label design”, “the storage system”, and “the notification service”, you may have several responsibilities sharing one home.

And if the project keeps growing, we may need to rethink the floor plan.

This is the first article in a series on the SOLID principles. I’ll look at what each principle means, but more importantly, why it matters and what can go wrong when we ignore it.

Code in this article uses Python 3.14.

Do you want to keep up with how Python programming and the art of making things are changing in this rapidly changing world? Then don’t miss out on the exclusive content for premium members here on The Python Coding Stack.

Subscribe now

I’ll be sharing more about how my programming, my daily work, and everything has changed over the recent months.

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

Appendix: Code Blocks

Code Block #1

from decimal import Decimal
​
class PotionShop:
    recipes = {
        “invisibility”: {
            “ingredients”: {
                “moonflower”: 2,
                “dragon_scale”: 2,
            },
            “price”: Decimal(”12.00”),
        }
    }
​
    def __init__(self):
        self.stock = {
            “moonflower”: 10,
            “dragon_scale”: 2,
        }
        self.sales = []
​
    def sell(self, potion_name, customer):
        potion = self.recipes[potion_name]
​
        for ingredient, quantity in potion[”ingredients”].items():
            if self.stock[ingredient] < quantity:
                raise ValueError(f”Not enough {ingredient}”)
​
        for ingredient, quantity in potion[”ingredients”].items():
            self.stock[ingredient] -= quantity
​
        price = potion[”price”]
        self.sales.append((customer, potion_name, price))
​
        print(f”{potion_name.title()}\t£{price:.2f}”)
        self.send_owl(
            customer,
            {”potion_name”: potion_name, “price”: price},
        )
​
        return price
​
    def send_owl(self, customer, message_content):
        print(f”Owl dispatched to {customer}”)
        return message_content

Code Block #2

shop = PotionShop()
print(shop.sell(”invisibility”, “Merlin”))

Code Block #3

# ...
​
class PotionShop:
    # ...
​
    def sell(
            self,
            potion_name,
            customer,
            *,
            moon_festival=False,
    ):
        # ...
​
        label = potion_name.title()
        if moon_festival:
            label = f”🌙 Moon Festival {label} 🌙”
​
        print(f”{label}\t£{price:.2f}”)
​
        # ...
    # ...

Code Block #4

shop = PotionShop()
print(shop.sell(”invisibility”, “Merlin”, moon_festival=True))

Code Block #5

# ...
​
class LabelMaker:
    def make(self, potion_name, moon_festival=False):
        label = potion_name.title()
​
        if moon_festival:
            label = f”🌙 Moon Festival {label} 🌙”
​
        return label
​
# ...

Code Block #6

labels = LabelMaker()
assert labels.make(
    “invisibility”,
    moon_festival=True,
) == “🌙 Moon Festival Invisibility 🌙”

Code Block #7

# ...
​
class PotionShop:
    # ...
​
    def __init__(self, label_maker):
        self.label_maker = label_maker
        # ...
​
    def sell(
            self,
            potion_name,
            customer,
            *,
            moon_festival=False,
    ):
        # ...
        label = self.label_maker.make(
            potion_name,
            moon_festival=moon_festival,
        )
        # ...
​
    # ...

Code Block #8

shop = PotionShop(LabelMaker())

Code Block #9

# ...
​
class OwlUnavailable(Exception):
    pass
​
# ...
​
class PotionShop:
    # ...
​
    def __init__(self, label_maker, owl_available=True):
        self.label_maker = label_maker
        self.owl_available = owl_available
        # ...
​
    # ...
​
    def send_owl(self, customer, message_content):
        if not self.owl_available:
            raise OwlUnavailable(
                “The owls are currently unavailable”
            )
        print(f”Owl dispatched to {customer}”)
        return message_content

Code Block #10

shop = PotionShop(LabelMaker())
​
assert shop.sell(”invisibility”, “Merlin”) == Decimal(”12.00”)

Code Block #11

shop = PotionShop(LabelMaker(), owl_available=False)
​
assert shop.sell(”invisibility”, “Merlin”) == Decimal(”12.00”)

Code Block #12

class PotionShop:
    # ...
​
    def sell(
        self,
        potion_name,
        customer,
        *,
        moon_festival=False,
        own_cauldron=False,
    ):
        # ...
​
        price = potion[”price”]
​
        if own_cauldron:
            price = (price * Decimal(”0.90”)).quantize(Decimal(”0.01”))
​
        # ...
​
        return price
​
    # ...

Code Block #13

shop = PotionShop(LabelMaker())
print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        own_cauldron=True,
    )
)

Code Block #14

shop = PotionShop(LabelMaker(), owl_available=False)
print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        own_cauldron=True,
    )
)

Code Block #15

shop = PotionShop(LabelMaker(), owl_available=False)
try:
    print(
        shop.sell(
            “invisibility”,
            “Merlin”,
            own_cauldron=True,
        )
    )
except OwlUnavailable:
    print(”Catching the ‘OwlUnavailable’ Exception”)
    print(shop.stock)
    print(shop.sales)

Code Block #16

class RecipeBook:
    def __init__(self):
        self.recipes = {
            “invisibility”: {
                “ingredients”: {
                    “moonflower”: 2,
                    “dragon_scale”: 2,
                },
                “price”: Decimal(”12.00”),
            }
        }
​
    def find(self, potion_name):
        return self.recipes[potion_name]

Code Block #17

recipe_book = RecipeBook()
assert recipe_book.find(”invisibility”)[”price”] == Decimal(”12.00”)

Code Block #18

class Inventory:
    def __init__(self, stock):
        self.stock = stock
​
    def remove_stock(self, ingredients):
        for ingredient, quantity in ingredients.items():
            if self.stock[ingredient] < quantity:
                raise ValueError(f”Not enough {ingredient}”)
​
        for ingredient, quantity in ingredients.items():
            self.stock[ingredient] -= quantity
​
    def add_stock(self, ingredients):
        for ingredient, quantity in ingredients.items():
            self.stock[ingredient] = self.stock.get(ingredient, 0) + quantity

Code Block #19

inventory = Inventory({
    “moonflower”: 10,
    “dragon_scale”: 2,
})
​
try:
    inventory.remove_stock({
        “moonflower”: 2,
        “dragon_scale”: 3,
    })
except ValueError as error:
    print(error)
​
print(inventory.stock)

Code Block #20

inventory.remove_stock({
    “moonflower”: 2,
    “dragon_scale”: 2,
})
inventory.add_stock({”moonflower”: 5})
print(inventory.stock)

Code Block #21

class PriceCalculator:
    def calculate(self, recipe, own_cauldron=False):
        price = recipe[”price”]
​
        if own_cauldron:
            price = (
                price * Decimal(”0.90”)
            ).quantize(Decimal(”0.01”))
​
        return price

Code Block #22

pricing = PriceCalculator()
print(
    pricing.calculate(
        {”price”: Decimal(”12.00”)},
        own_cauldron=True,
    )
)

Code Block #23

class SalesLedger:
    def __init__(self):
        self.sales = []
​
    def record(self, customer, potion_name, price):
        sale = {
            “customer”: customer,
            “potion”: potion_name,
            “price”: price,
            “notification”: “pending”,
        }
        self.sales.append(sale)
        return sale
​
    def mark_notified(self, sale):
        sale[”notification”] = “sent”
​
class Notifier:
    def send(self, customer, potion_name, price):
        print(f”Owl dispatched to {customer}”)

Code Block #24

class PotionShop:
    def __init__(
        self,
        recipe_book,
        inventory,
        pricing,
        labels,
        ledger,
        notifier,
    ):
        self.recipe_book = recipe_book
        self.inventory = inventory
        self.pricing = pricing
        self.labels = labels
        self.ledger = ledger
        self.notifier = notifier
​
    def sell(self, potion_name, customer, *, moon_festival=False,
             own_cauldron=False):
        recipe = self.recipe_book.find(potion_name)
        self.inventory.remove_stock(recipe[”ingredients”])
​
        price = self.pricing.calculate(
            recipe,
            own_cauldron=own_cauldron,
        )
        label = self.labels.make(
            potion_name,
            moon_festival=moon_festival,
        )
        sale = self.ledger.record(customer, potion_name, price)
​
        print(f”{label}\t£{price:.2f}”)
        self.notifier.send(customer, potion_name, price)
        self.ledger.mark_notified(sale)
​
        return price

Code Block #25

ledger = SalesLedger()
shop = PotionShop(
    RecipeBook(),
    Inventory({”moonflower”: 10, “dragon_scale”: 2}),
    PriceCalculator(),
    LabelMaker(),
    ledger,
    Notifier(),
)
​
print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        moon_festival=True,
        own_cauldron=True,
    )
)
​
assert ledger.sales[0][”notification”] == “sent”
print(ledger.sales[0])

Code Block #26

class FailingNotifier:
    def send(self, customer, potion_name, price):
        raise OwlUnavailable(”The owls are currently unavailable”)
​
ledger = SalesLedger()
shop = PotionShop(
    RecipeBook(),
    Inventory({”moonflower”: 10, “dragon_scale”: 2}),
    PriceCalculator(),
    LabelMaker(),
    ledger,
    FailingNotifier(),
)
​
try:
    shop.sell(”invisibility”, “Merlin”)
except OwlUnavailable:
    pass
​
print(ledger.sales[0])
assert ledger.sales[0][”notification”] == “pending”

stephengruppetta.com

This is how it used to be. And perhaps it’s how it still is for you. This is how I wrote computer programs just over half a year ago, too. But things started changing gradually for me earlier in 2026.

Last week, I ran a live course. In the first few minutes of the first live session, I opened a blank .py file in my IDE. There was nothing on my screen. Then I wrote code. Word by word. Line by line.

And about half an hour into this first session, it dawned on me: the last time I had gone through this process of opening a blank file and writing code from scratch was the previous time I had to run a live course a couple of months earlier.

My Agent and I

Every bit of code I had worked on in between these two live courses was written by my AI agent. I was very much involved in those processes, and I read and reviewed lots of code. But I didn’t write any.

Like many, I have mixed feelings about this. I’m getting a lot more done. But I miss the process of writing code, exploring options, putting a project together, function by function, class by class, module by module.

The Coding Gym

I’m going to force myself to write code. I’ll make time for it, as I enjoy it too much and I don’t want to lose the skills and fluency. But it will be like going for a run or lifting weights in the gym. I don’t run because I need to get from point A to point B quickly and I don’t lift weights because I need to move those weights from one place to another. I do those things to keep my body healthy and strong. I’ll code by hand to do the same thing for my mind.

A Real World Example

But let’s go back to how I code now, in late 2026. And let me give you an example of something I worked on last week and used successfully this weekend.

It’s not Python code. It’s a Google Sheets spreadsheet. But that doesn’t matter. The process is the same.

The Scenario

I’m a member of an athletics club (or ‘track and field’, depending on which flavour of English you speak). This weekend we had our club championships and I was tasked to take care of results and overall points. We award a shield for the best track performance and another for the best field performance.

The Pain Point

Last year I was asked to help out at the last minute (and by “last minute” I mean it almost literally, as it was 20 minutes before the meeting started). It was a nightmare. I wasn’t responsible for collating the results, that was done by someone else manually as if it was 1965. I just had to work out their performance points by tapping in lots of numbers into an online calculator using my phone. A laptop would have been easier, but I was only tasked with this job on the day and I only had a phone with me.

This year I had more notice, so I chose to make my life easier... and the whole process smoother.

The Problem

The problem we’re trying to solve…

…is not rocket science. Officials on the track or in the field write results on result sheets and they’re passed on to the result room by a runner. These sheets contain the name of the event, the athletes’ bib numbers, and their performances. So a result slip may look like this:

| Event: U16 Boys 100m-1 |                 |
| ---------------------- | --------------- |
| Athlete                | Performance (s) |
| 23                     | 11.5            |
| 47                     | 11.8            |
| 13                     | 11.9            |

Here’s what happened last year:

• My colleague had to cross-reference bib numbers with a printed-out sheet of registered athletes. She matched names and age groups, then she sorted results into separate sheets for each event and age group.

• I had to look up each athlete’s date of birth from a spreadsheet I’d been given that morning (browsing spreadsheets on a phone screen is not fun), then tap their age, event, and performance into an online calculator, one by one, and write the resulting points on a separate sheet.

The points allow you to compare performances by athletes of different ages in different events, so that we could then find the single best track performance and the single best field performance.

I was already thinking, at last year’s event, of the Python program I could write to automate all of this.

The Solution (I would have never bothered with in 2025)

So, fast-forward to a couple of weeks ago. This time I had some time to come up with something. But I opted to create a Google Sheet instead of a Python program for two reasons:

• It’s much easier for others in the club to use it and share it in the future.

• My usual objection that it’s easier and more fun to write a Python program than create a complex spreadsheet full of linked tabs and formulae didn’t apply. Either way, it was my agent who was going to do the hard work.

And here’s the thing. If I was doing this last year, when I was still coding most things manually (and occasionally opening a ChatGPT window to ask a few things), I still wouldn’t have done this. I wouldn’t have had the time.

But this year was different. Sure, if anything I was busier this year than I was last year. But this year I had agents at my fingertips. Agents who know me and have been working alongside me for a while.

Here’s why I wouldn’t have bothered doing this myself:

• The age group cut-off dates are different for younger age groups (31 August), older age groups (31 December), and Masters athletes (over 35s, where the age group is determined on the day of the competition.)

• There are published points tables to compare performances in different events for senior athletes.

• There are published points tables to compare performances in the same event for older athletes, above 30.

• There are older tables to deal with age comparisons for under 30s

The system needs to take care of all this. None of it is too difficult to write in a Python program or to create one of those power-spreadsheets that link everything together. But it would have required some time and patience, which I didn’t have.

But here’s what I had time for…

I was using an agent I communicate with through Discord, which I also have on my phone. I have a good dictation tool on my phone, too. So in the past week, whenever I was preparing dinner, or waiting in line at the shops, or sitting on the sofa in the evening watching TV, I could have a chat with my agent to guide him (it?) to what I wanted. I knew what I wanted. I just didn’t have the time or desire to do it myself.

And after a few days of these on-and-off conversations, I had a Google Sheet with 20 tabs, including all the points tables for the various scenarios, all the age group rules, all the registered athletes, who-knows-how-many formulae linking columns, rows, and tabs, and, importantly, just two tabs to input results, one for track events and one for field events.

You just enter the event session (selecting from a drop-down menu), the bib number, and the performance. And that’s it. The spreadsheet works out each age group results, the points for each athlete, it shows a live points leaderboard, and so on.

As I said, none of this is rocket science. I know I would have been able to create this spreadsheet by hand, or write Python code that does the same thing. But I would have needed more time. And I wouldn’t have been able to multitask as I did last week.

Oh, and one more thing: I also asked my agent to check the spreadsheet every 15 minutes during our club championships, read the latest results, and post them on a Telegram channel I could share with everyone at the track. So we had live results published online too. I’d never have bothered to set that up manually.

Programming Will Never Be The Same

The real-world example I described above doesn’t represent every programming task I work on with the help of my AI agents. This was a hobby-type project that I probably wouldn’t have worked on otherwise because I didn’t have the time. It wasn’t too difficult, but it would have been time-consuming to do by hand. The stakes weren’t high. Sure, we didn’t want to make mistakes when assigning medals and shields, but it was easy to spot obvious mistakes, and this wasn’t the Olympic Games, either!

I’ll write about other case studies soon, including ones where I was more closely involved in the nitty-gritty of the Python code even though I didn’t write any, nor make any changes to the code by hand.

Do you want to master Python and programming one article at a time, even in this age of AI? Then don’t miss out on the articles in The Club which are exclusive to premium subscribers here on The Python Coding Stack

Subscribe now

Coming Soon… Exploring SOLID Through AI-Assisted Coding

I’m starting a series on the SOLID principles here on The Python Coding Stack soon. I’ll write posts about each of the five principles, and I’ll do it my way, the same style I always use when tackling Python topics.

I’ll also have a series of posts, which will include video, where I’ll work on a project from beginning to end using my AI agent and reviewing the code it writes. This project will meander through several OOP concepts, and you’ll be able to see the SOLID principles come in naturally into the project as solutions to problems we might encounter as the project grows.

Stay tuned.

How far are you in the traditional-coding-to-AI-coding arc? Leave a comment and let’s compare notes!

Join The Club, the exclusive area for paid subscribers for more Python posts, videos, a members’ forum, and more.

Subscribe now

You can also support this publication by making a one-off contribution of any amount you wish.

Support The Python Coding Stack

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

The to-do list is longer, the inbox is noisier, and home has thoughtfully provided its own backlog: a replacement car, a new school uniform, and a garden that has staged a minor coup.

I may need another holiday already.

And that’s before even talking about programming and the revolution it is currently going through. I’m a Python educator. Somewhat unusually for Python educators, I’ve been a full-time Python educator for over a decade.

But AI is changing how people learn and what people need to learn. Like many others, I find myself fascinated by what I can now do with AI, while also aware that it is changing the economics of work that has supported me for years.

It’s time to find out how anti-fragile I am. Over the coming weeks and months, I’ll write about using AI, I’ll share my thoughts about programming in 2026 and beyond, and I’ll tell you what I think about how learning and teaching are changing.

So I am going to explore this in public: how we learn, teach, write, and assess code in an AI-shaped world.

Here is some signposting for what else you will read on these pages in the coming months:

• SOLID Ideas • I have been wanting to write a series on SOLID programming principles for a while. They matter more than ever when we want AI agents to write robust code for us rather than plausible-looking but brittle code. The series will look not only at what the principles are, but why they matter and what can go wrong when we ignore them.

• Agents Unpacked • Before going on holiday, I started this new section on this publication. I am thinking about republishing the first two posts in a significantly updated form, then carrying on at pace. Perhaps it will become a book, too. Agents are here, and I want to understand what they are, how they differ from LLM chat interfaces, and how to use them efficiently. You can join me on that learning journey.

• Learning Rust in Public • I also want to learn Rust and will set up another section here to do that in public, as they say these days. I will use a similar format to Agents Unpacked, in which my personal learning agent and I have a discussion as I learn from it.

Subscribe now

So there is plenty on the horizon here at The Python Coding Stack: plenty of Python, and plenty of Python-adjacent stuff, too. And some other stuff, too. I hope you will join me for the journey.

Here’s the archived content:

You have used a large language model. You know the deal: a careful prompt gets a careful answer. A vague prompt gets a vague one. And the model itself does not keep anything from one conversation to the next, unless something external is holding that context for it.

Agents work differently. They have parts that do things a plain LLM does not. These parts are what make an agent an agent. It is not just the model underneath. It is the structure built around it that gives the system its abilities to persist, act, and keep going.

Understanding this structure is the second major shift in this series. The first shift is seeing that a chatbot can give you a good answer without finishing the job, because it stops after responding. The second shift is seeing that an agent is not a smarter model. It is a model placed inside a structure that gives it something to act with and somewhere to keep what it has done.

The Agent Formula

Most agents share the same basic parts:

• A model (the LLM): the reasoning engine that understands language and decides what to do

• Instructions: what tells the agent who it is, what it is for, and what ‘good’ looks like

• Memory: a workspace or store that holds what has happened so far

• Tools: capabilities the agent can call on to do things beyond generating text

• An execution loop: the cycle of observing, deciding, acting, and checking

Different platforms package these differently. Some call memory “context,” some call tools “plugins” or “capabilities,” and some merge instructions and tools into a single configuration layer. But the parts are the same. An agent is not a single thing. It is a system, and each part matters.

Stephen: Don’t LLMs also have memory since they remember what happened earlier in the conversation? How’s this different?

Here is one distinction worth getting clear early: the context window and memory are not the same thing. The context window is the working space an LLM uses during a single session. It holds the conversation so far and gets loaded fresh every time the model gets a chance to speak. Memory, by contrast, is information stored outside the model, maintained by the system, and available across sessions and steps. We will come back to this.

An agent needs all its components:

Agent = Model + Instructions + Memory + Tools + Execution Loop

Leave any one of these out and the system changes behaviour in ways that matter. We will look at each piece in turn.

Subscribe now

What the Model Does and What It Doesn’t Do

The model is the reasoning core. It reads your request, figures out what to do, and decides what to say back. It gets the most attention because it is the part that generates language.

But a model on its own is like a brilliant mind with no hands and no memory of its own. It can think. It cannot act. It cannot remember what happened five minutes ago unless something explicit carries that information forward.

Stephen: Wait a second. You say the model doesn’t remember what happened five minutes earlier. But when I use an LLM, it does seem to remember what happened earlier in the conversation.

Here is what is actually happening. When an LLM appears to remember earlier in a conversation, it is not the model itself that is remembering. The context window is carrying all the earlier messages along with your new message, every time you send something. The model sees the full conversation again and generates a response that fits what came before. That is not memory in the model. That is the system feeding the model a transcript.

This trips up almost everyone when they start using agents. The model generates text. The rest of the system decides what to do with that text and whether to act on it.

A better model helps. It reasons more clearly, follows instructions more faithfully, and handles edge cases better. But dropping a smarter model into an agent that is missing a working execution loop will not make it an agent. You need the other parts too.

Instructions: The Agent’s Direction

Instructions tell the agent what it is supposed to do and how to behave. Some systems call these system prompts. Others call them agent definitions or behavioural instructions. The name does not matter. What matters is that they are the layer that tells the model why it exists, who it is helping, and what ‘good’ looks like for the task at hand.

Good instructions do not make an agent smarter. They make it more focused. They give it a frame for every decision: what to prioritise, what to avoid, when to ask for help, how to present its output.

Stephen: Are these what are often called ‘skills’, or are skills something else altogether?

Skills and instructions are related, but they are not the same thing. Instructions are the core behavioural direction: who the agent is, what it is for, how it should approach its work. A skill, in platforms like OpenClaw and Hermes, is a specific file that tells the agent how to carry out a particular task, often by combining one or more tools. So instructions tell the agent how to behave generally. A skill tells it how to do something specific. We will see this distinction more clearly when we look at how different platforms implement these parts.

The instructions shape what the agent notices, what it proposes, what it tries, and what it says no to. Two agents built on the same model with different instructions will behave differently in the same situation. They will notice different things, prioritise differently, and produce different outcomes.

Poorly written instructions can quietly break an agent. If the instructions are vague, the agent has to improvise every step. If they contradict each other, the agent has to choose, and it might not choose the way you intended.

Stephen: Can you provide a few examples of what these instructions may look like in different scenarios?

Here is what instructions might look like in practice. A poorly-written instruction can quietly break an agent. Consider an instruction that says “be helpful and concise” without defining either term. When a user asks for a full technical breakdown, the agent has to arbitrate between two vague goals. It might give a two-sentence answer that technically satisfies “concise” but ignores “helpful,” or it might give an exhaustive response that satisfies “helpful” but ignores “concise.” Either way, the agent is improvising because the instructions gave it no real frame for the conflict.

A research assistant agent might have instructions that say something like: “You are a research associate working for [user name]. Your role is to find, summarise, and organise information on topics the user assigns. Always cite your sources. Flag uncertainty rather than guessing. Present findings in a clear brief, not a wall of text.”

A code review agent might have very different instructions: “You are a principled code reviewer. Focus on correctness, clarity, and performance. Do not praise code unnecessarily. When you find an issue, explain why it matters and suggest a concrete fix. Keep responses short.”

The difference between those two sets explains a lot about why two agents can feel like entirely different systems, even if they use the same model underneath.

Memory: The Workspace and Context

Memory in an agent is not like human memory. It is a structured store of information kept and updated as the agent works. It is what lets the agent hold a thread across multiple steps without starting from scratch each time.

Most agents use some combination of three types:

• Working context — what is active right now: the current goal, what has been tried so far, what the user last said

• Stored information — what the agent has been told about the user, their preferences, their past requests

• Files and state — what exists in the workspace right now, what has been written or read recently

This is not a personality feature. It is not the agent “remembering” in the way a person remembers their childhood. It is operational continuity. The system maintaining a thread of relevant information across time and steps.

Different platforms handle these differently. LangChain agents build up a rolling context window: the current request gets appended to everything that happened before, and the whole thing is passed to the model. If the conversation gets long, older turns get dropped or summarised to make room. AutoGen agents can maintain shared memory across a team, so that when one agent finishes a task, what it learned is available to the next agent that picks up the thread.

OpenClaw takes yet another approach. Its memory layer is a structured store that agents write to and read from across sessions. When an agent starts a new session, it can query that memory store for relevant context rather than relying solely on what was in the most recent conversation. An agent can know that the user prefers short emails, even if that was established three weeks ago.

Stephen: If memory can be stored in files, does it mean that agents can have nearly unlimited memory (within the limits of the computer or server’s overall memory capacity)?

There are practical limits even when storage is effectively unbounded. The more relevant limit is not how much the agent can store, but how well it can find and use what it has stored. A full inbox is not the same as a well-organised one. Retrieval becomes harder as memory grows, and irrelevant information can dilute the signal if the system does not manage it carefully.

Think of it this way. A context window that holds 128,000 tokens can technically hold a lot of information. But it can only hold what was placed there. An agent with a large memory store full of useful context still needs a way to surface the right information at the right time. If it cannot find what it needs, or if what it finds is buried under noise, the effective memory is constrained.

The quality of retrieval matters as much as the quality of storage. An agent that retrieves relevant context poorly is effectively working with a much smaller memory than one that retrieves well, even if both store the same amount.

Stephen: So, tell me if I understood this. The agent has an index telling it where to find information specific to certain topics or tasks. When the LLM part of the agent decides it needs to deal with a certain topic, it uses the index to read and load the information from the memory file into its context. Is that right?

That is broadly right. The memory store, the index, and the retrieval into context are the key parts. One small correction worth noting: the decision to retrieve from memory is typically made by the agent or coordinator layer, not by the LLM directly. The LLM receives the retrieved content as part of its context, but it is the agent system that decides what to look up and when. This distinction matters because it is the agent layer, not the model, that is doing the memory management.

Stephen: But isn’t the agent’s brain the LLM? Clarify the distinction in your answer above. Which part of the agent’s infrastructure deals with this?

It is a fair challenge. The LLM is genuinely where the reasoning happens. It reads context, generates text, and makes decisions about what to say or do next. But it is also just a text processor. It receives input, produces output, and has no awareness of anything beyond the tokens it has been given.

The coordinator layer is the infrastructure that sits around the LLM and manages the process. It reads the LLM’s output, decides whether to act on it, calls tools, retrieves memory, and feeds results back into the next LLM call. It is the difference between the LLM thinking and the agent doing. A bare LLM generates text. The coordinator turns that text into action.

To use a rough analogy: the LLM is like a pilot who can read instruments and make decisions. The coordinator is like air traffic control — it decides which runway to use, when to land, and when to divert. The pilot’s brain does the reasoning. But without the infrastructure around it, the pilot just sits in the cockpit thinking.

So when we say the agent retrieves memory, we mean the coordinator retrieves it and places it where the LLM can see it. The LLM does not reach into a file and pull something out. The coordinator does that work and presents the result to the LLM as part of the next context.

Stephen: And are the bits of these files then loaded into the LLM’s context? Therefore, the more stuff is loaded from the memory files, the more the context fills up, affecting the rest of the conversation and cost, right?

Yes, exactly right. Memory retrieval feeds into the context window, which is the LLM’s working space for the current session. Every token that goes into the context window is a token the LLM processes and a token that costs something. Loading a lot of context from memory means less room for the conversation itself, and it means higher token usage on every call.

This is one of the practical engineering tensions in agent design. Loading more memory gives the agent more to work with, but it also makes each LLM call more expensive and slower. A well-designed agent retrieves only what is relevant to the current task, not everything it knows.

Tools: What the Agent Can Actually Do

Tools are the capabilities that let an agent act beyond generating text. The model decides to use a tool. The tool performs an action and returns the result to the model.

This was covered in Chapter 1 under “Tools Are the Hands.” Here it is worth noting that tools are also where agents differ most between platforms. Some agents come with a large built-in toolkit. Others can call external tools through open protocols. Some let you build custom tools. Others are more locked down.

What tools might an agent actually have? A research agent might be able to search the web and read files on your machine. A coding agent might run shell commands and read or write files. A calendar agent might check your schedule and send messages. The tool is the bridge between the model’s decisions and the world the agent is working in.

What matters is not how many tools an agent has, but whether the tools it has are the right ones for the tasks you want it to perform.

Different platforms implement tools differently. LangChain provides a standardised tool interface that lets you connect to search APIs, databases, file systems, and custom functions. OpenCode agents run inside a development environment, where the tools available are the commands and interfaces of that environment. OpenClaw uses an open tool protocol that lets agents call external capabilities regardless of who built them. Hermes takes a more composed approach: a skill file specifies not just what the agent should do, but which tools to use and in what combination to carry out a specific task.

Here is the thing worth unpacking. A tool on its own is just a capability. What makes it useful is the bridge between what the agent is trying to accomplish and the tool that can help. A calendar tool is useless if the agent does not know it should check the schedule. An agent running a meeting-preparation skill that says “check availability, send invites, prepare a briefing document” has that bridge built in.

The Execution Loop: The Part That Makes It an Agent

The execution loop is the cycle that takes an agent from a single-shot response to a sustained process. Observe, think, act, check, repeat.

This was the core of Chapter 1. But it is worth restating here, in the context of anatomy, because the loop is what ties all the other parts together. Without it, you have a model that receives instructions and context and produces text. With it, you have a system that can pursue a goal across time, recover from partial failures, and stop when the work is genuinely done.

The loop is the difference between an agent and a very well-instructed chatbot.

Here is why the repeat step matters so much. A model has no native sense of when it is done. When you call a function in code, the function returns and you are finished. When a model generates text, it produces tokens until it hits a stop condition built into the model itself, most commonly a token limit or a designated stop sequence. These conditions tell the model when to stop generating, but they do not tell the agent whether the result is actually what the user wanted. There is no built-in check that says “is this the right answer?”

The execution loop provides that check. The check phase asks: is the result good? Does it meet the original goal? If not, the loop continues. Sometimes that means a dozen or more cycles before a task is genuinely complete.

The loop also determines how goals decompose. In LangChain’s ReAct-style agents, the loop runs inside a single agent: observe, decide on the next action, execute it, check the result, repeat. In AutoGen, the loop is distributed across multiple agents that hand off to each other. A planner agent might coordinate specialist agents, each running their own loop on their own piece of the problem. OpenClaw uses a coordinator agent to manage the loop, assigning work to sub-agents and handling the check phase across the full task rather than within a single agent cycle.

The architecture of the loop is one of the most significant differences between agent platforms. But the function is the same everywhere: turning a sequence of isolated model calls into a coherent, goal-directed process.

Multiple Platforms: Comparing the Formula in Practice

It helps to see the same five-part formula playing out in different platforms. Here is how a few of them map onto it.

LangChain is one of the most widely-used agent frameworks. A LangChain agent has an LLM at its core, a set of tools, a prompt defining the agent’s role, memory that accumulates conversation history, and an agent executor that runs the loop. The loop in LangChain is explicit: the agent executor repeatedly calls the model, parses the model’s tool-call output, runs the tool, and feeds the result back until the model says it is done.

AutoGen takes a different approach. Rather than a single agent, AutoGen sets up a team of agents that communicate with each other. Each agent has a model, instructions defining its role, and its own set of tools. The loop is distributed: there is no single execution cycle. Agents exchange messages, delegate tasks to each other, and the overall process continues until the team has finished the assigned goal. Memory in AutoGen can be shared across agents so that one agent’s work is available to the next.

OpenClaw uses a coordinator agent that manages the overall execution loop. Sub-agents each have their own identity, tools, and memory. The coordinator decides which sub-agent handles which part of a task, passes context between them, and handles the check phase across the full goal. Skills in OpenClaw are files that tell a specific agent how to carry out a particular task, combining instructions about what to do with definitions of which tools to use.

Hermes also uses a skill-based architecture where skill files define both the instructions and the tool configuration for specific tasks. Rather than a single general-purpose agent, Hermes composes agents from skills that know how to use particular tools in particular contexts.

OpenCode works differently again. It runs agents inside a development environment, typically a cloud workspace. The tools available to the agent are the commands and interfaces of that environment. The loop is typically managed at the task level: the agent receives a task, works through it using the tools at its disposal, and reports back. There is less of a formalised multi-step loop and more of a task-completion focus.

None of these platforms invents new parts of the agent formula. They all use a model, instructions, memory, tools, and an execution loop. What differs is how those parts are implemented, how they are divided up, and how they communicate. Understanding the formula means you can look at any of these platforms and see what you are actually looking at.

What This Chapter Covered

This chapter pulled apart the five components of the agent formula.

We saw how the model is the reasoning core but cannot act or remember on its own. How instructions shape the agent’s focus and behaviour, and why the same model with different instructions can feel like a different system entirely. How memory provides operational continuity across steps and sessions, and why retrieval quality matters more than storage capacity. How tools extend what the agent can do beyond generating text, and why a tool is only as useful as the bridge between the model’s decisions and the action the tool can take. And how the execution loop is the architecture that turns isolated model calls into a coherent, goal-directed process.

We also saw how different platforms implement the same five components differently: LangChain’s explicit agent executor, AutoGen’s team-based coordination, OpenClaw’s coordinator and skill-based sub-agents, Hermes’s composed skill architecture, and OpenCode’s environment-integrated approach.

The goal was not to become an expert on any one platform. It was to show that agents are not mysterious black boxes. They are systems built from a small number of recognisable parts, and once you know what to look for, you can see the anatomy underneath any agent platform you encounter.

Next up in Agents Unpacked: we dig into tools and skills: what it actually means for an agent to do something rather than just say it, and why a well-tooled agent operating autonomously in a loop is a fundamentally different thing from a model answering questions.

<< Previous Post: From Answer to Outcome

>> Next Post: Coming Soon

Table of Contents

stephengruppetta.com

Following what’s happening when you have a chain of iterators in Python can feel like playing that game. But, unlike the street game, there are no scams when you’re playing the iterator game. Let’s make sure you’ll always win.

I’ll keep this article short. I wrote many articles about iterables and iterators. If you need to refresh your memory, have a look at The Anatomy of a for Loop and A One-Way Stream of Data • Iterators in Python (Data Structure Categories #6).

Follow The Data in a Chain of Iterators

Let’s keep the example simple. Start with this list in a REPL session:

A list is iterable. You can create an iterator from any iterable. Let’s create an iterator from this list:

The built-in function iter() creates an iterator from an iterable. Iterators don’t contain data. They don’t create copies of the data. They’re lightweight objects that create a stream. They’ll fetch data from the original source, which is the list boring_numbers in this case, as and when needed.

Iterators can only fetch an item once. So, they’re a one-way stream. Once you use an item, it’s gone from the iterator – but not from the original list, which remains unchanged.

Therefore, first_iter is an iterator that relies on data from the list boring_numbers. But let’s not fetch any items from the first_iter iterator. Not yet, anyway.

Create a second iterator. This time, you’ll use a generator expression. Generators are iterators, so you create a second iterator with this code:

Note that the expression on the right-hand side of the equals sign is enclosed in parentheses – the round ones, to be clear. This is a generator expression, which creates a generator iterator. Read Pay As You Go • Generate Data Using Generators (Data Structure Categories #7) for more on generators.

As we said, generators are iterators.

The second_iter iterator generates data from first_iter, which is itself an iterator. Iterators are also iterable, which is why you can use them directly in a for clause or anywhere else you’d generally use an iterable. The second_iter iterator will yield the values as floats. But you’ve not yielded any value from this iterator either. Not yet.

Let’s go a step further and create a third iterator, which is also a generator in this case. You build this third iterator from the second one, second_iter:

The generator iterator third_iter yields the sum of 0.5 and the value yielded by second_iter.

Incidentally, I used a “standard” iterator and two generator iterators in this example. However, for the journey we’re following in this article, it doesn’t matter whether we’re using a basic iterator or a generator iterator. If you prefer, you can repeat this exercise with iterators you get from iter() directly.

Support The Python Coding Stack

Don’t Blink • Follow the Data

You started with a list called boring_numbers. This data structure contains* the data. It’s where the data lives. We’ll be following the data in this section. So it’s important to know where it’s stored!

*Note: Lists, like all data structures, don’t really contain data in the purest sense of the word. See What’s In A List—Yes, But What’s Really In A Python List for more on this. But in general, it’s fine to talk about a list ‘containing’ items of data.

You then create three iterators. The first uses data from boring_numbers. The second iterator uses data from the first. And the third iterator uses data from the second.

But you haven’t tried to fetch any value from any of the iterators yet.

Let’s look at what each iterator is doing at the moment before you fetch any values. The first iterator, first_iter, is pointing at the first item in boring_numbers. It’s ready to read this value and yield it.

The second iterator, second_iter, is pointing at the first item in first_iter. But first_iter doesn’t have any data. Iterators don’t have their own data. But that’s OK. Whenever second_iter needs to fetch the value, it will ask first_iter to fetch and yield its “first” value. I put “first” in quotation marks because you’ll see later that this may or may not be the first value.

Finally, third_iter is pointing at the first item in second_iter. The same logic applies. When third_iter needs the first item, it will ask second_iter for its “first” item, and second_iter will need to ask first_iter for its “first” item. And first_iter is pointing at the first item in the list boring_numbers.

Are you with me? Let’s complicate things a bit…

Note how your code so far includes the following lines:

None of the iterators has yielded any value. For now.

Let’s jumble things up and start by fetching the first value from second_iter:

You ask for the next value in second_iter, which is the first one since you haven’t yielded any values yet.

As you’ve seen earlier, second_iter needs the first value from first_iter. So, behind the scenes, Python calls next(first_iter), which yields the first item from boring_numbers.

So, first_iter reads the first value from boring_numbers, which is the integer 1, and it yields it to second_iter, which then yields the transformed version to the REPL as the return value of next(second_iter). That’s why the output is the float 1.0. The first iterator, first_iter, now moves to point at the second item in boring_numbers, ready for when it’s needed.

Note that boring_numbers doesn’t change in this process. The first item in boring_numbers remains there. It doesn’t disappear.

So far, so good?

Continue in the same REPL session and try the following:

You ask third_iter to give you its “next” value. You haven’t used third_iter anywhere so far. So, you might expect it to yield the “first” value.

And it does.

But its interpretation of what’s the “first” item may be different to what you expect.

Let’s follow the data. When you call next(third_iter), the third iterator asks second_iter for its next item. The second iterator, second_iter, relies on first_iter, so it asks first_iter for its next item. And first_iter, as you may recall, is currently pointing at the second item in boring_numbers, which is the integer 2.

So:

1. The first iterator first_iter gets the integer 2 from boring_numbers and yields it to second_iter. And first_iter now points at the third item in boring_numbers.

2. Then, second_iter transforms this value into a float and yields 2.0 to third_iter.

3. Finally, third_iter adds 0.5 to this value and yields 2.5, which is what you see displayed in the REPL.

When you called next(second_iter) earlier in the code, you used up the first item in second_iter, which in turn used up the first item in first_iter. Since this first value is gone and since third_iter depends on the data yielded by second_iter and first_iter, the earlier call to next(second_iter) also affected the iterator that’s downstream, third_iter.

What will happen if you call next(first_iter) now? Try to follow the data in your head before trying it out or reading on.

.

.

Have you worked it out?

.

.

Let’s run the code:

Although it’s the first time you explicitly use first_iter in your code, you already used two of its values when your code yielded values from iterators downstream. Therefore, the next item in first_iter is the third item in boring_numbers, the integer 3.

Let’s finish with one more expression, still running in the same REPL session:

You call next(third_iter), which asks second_iter for its next item. And second_iter asks first_iter for its next item. At this stage in the process, first_iter is pointing at the fourth item in the original source of data, which is the list boring_numbers. That’s why the output is 4.5.

Independent Iterators

Consider the following code, which is similar to the one you wrote above but has one extra line:

The iterators first_iter and another_first_iter both use the same source of data, boring_numbers. However, they are independent iterators. Note that when you use up some of the elements in first_iter, the independent another_first_iter is not affected. The first time you ask for the first item in another_first_iter, you get the integer 1.

Final Words

Iterators don’t contain data. They rely on data that’s stored elsewhere. But you can have a chain of iterators, each asking the previous one to yield a value. Weird things can happen if you’re not careful. But now you know how to follow the data when you have a chain of iterators.

As a rule of thumb, if you create an iterator that depends on another iterator, you should only use the final iterator to avoid these issues. So, in the example above, you should only yield values from third_iter.

Have a play with this example and make your own chains of iterators, too. And once you’re comfortable with this, get ready to be confused again with my next article, which will discuss itertools.tee()!

And next time you pass by someone in the street offering to let you play the three-cups-and-ball game, don’t feel overconfident because of your iterator knowledge – it won’t help you find the ball.

Code in this article uses Python 3.14

The code images used in this article are created using Snappify. [Affiliate link]

Join The Club, the exclusive area for paid subscribers for more Python posts, videos, a members’ forum, and more.

Subscribe now

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

Further reading related to this article’s topic:

• The Anatomy of a for Loop

• A One-Way Stream of Data • Iterators in Python (Data Structure Categories #6)

• Pay As You Go • Generate Data Using Generators (Data Structure Categories #7)

• What’s In A List—Yes, But What’s Really In A Python List

Appendix: Code Blocks

Code Block #1

boring_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Code Block #2

# ...
first_iter = iter(boring_numbers)

Code Block #3

# ...
second_iter = (float(number) for number in first_iter)

Code Block #4

# ...
third_iter = (num + 0.5 for num in second_iter)

Code Block #5

boring_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
first_iter = iter(boring_numbers)
second_iter = (float(number) for number in first_iter)
third_iter = (num + 0.5 for num in second_iter)

Code Block #6

# ...
next(second_iter)
# 1.0

Code Block #7

# ...
next(third_iter)
# 2.5

Code Block #8

# ...
next(first_iter)
# 3

Code Block #9

# ...
next(third_iter)
# 4.5

Code Block #10

boring_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
first_iter = iter(boring_numbers)
another_first_iter = iter(boring_numbers)
second_iter = (float(number) for number in first_iter)
third_iter = (num + 0.5 for num in second_iter)
next(second_iter)
# 1.0
next(third_iter)
# 2.5
next(first_iter)
# 3
next(third_iter)
# 4.5
next(another_first_iter)
# 1

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

Here’s the archived content:

Something has shifted in how we use AI. We still talk about “chatbots” and “prompts” and “getting a good answer.” But underneath those familiar words, a different kind of system has been quietly taking shape. One that doesn’t just answer your question. One that does something about it.

This Agents Unpacked series is about that shift. Not the hype version, not the science-fiction version, but the practical reality of what it means when an AI system can act, remember, and persist — when it can take a goal and work toward it, rather than waiting for you to type the next message.

If you have used ChatGPT, Claude, or Gemini to help with your work, you already know the issue: the answer comes back, it’s good, and then... the real work begins. This series is about what happens when the AI can do some of that real work too.

The Half-Done Feeling

You ask an AI chatbot to draft a project proposal. It gives you a solid one — well-structured, sensible, ready to polish. Then you close the chat window, and the proposal lives nowhere. The assistant doesn’t remember it. It doesn’t know where to file it, who needs to see it, or what happened the last time you wrote a similar proposal. If you come back tomorrow, you’re starting from scratch.

Or you ask it to research a topic. It gives you a good summary. But it didn’t check your existing notes first, it didn’t save what it found, it didn’t organise the sources, and it didn’t flag the gaps. The answer is useful. The process is incomplete.

This isn’t a criticism of chatbots. They do exactly what they were designed to do: you ask, they answer. The problem is that real work doesn’t stop at the answer. The proposal needs filing, the research needs organising, the plan needs tracking. The chatbot gave you a great starting point and then left you to do everything that comes after.

That gap between a useful answer and a finished job is where agentic AI enters the picture.

What Changes When AI Can Act

A chatbot is like a consultant you can phone. You describe the problem, they give you advice, and then you hang up and do the work yourself. Good advice (hopefully), but the consultant doesn’t pick up the phone again tomorrow and ask how it went.

An agent is different. It’s more like a capable colleague you’ve given a desk, a filing cabinet, and access to your systems. It has a workspace. It can remember what happened yesterday. It can read files, search the web, send messages, run calculations, ask you questions — not just talk about doing those things, but actually do them. And given a goal, it can work out the steps itself.

The difference sounds small. In practice it changes what you can delegate, what you can automate, and what you still need to do yourself.

The Loop Underneath

Every agent runs on an agentic loop. It sounds technical, but the pattern is surprisingly familiar:

1. Observe — What is the situation? What did the user ask? What information is already available?

2. Think — What needs to happen next? Is one step enough, or should this be broken into parts?

3. Act — Use a tool, look something up, write a file, send a message.

4. Repeat — Look at what happened, decide whether the job is done, and continue if it isn’t.

A chatbot usually observes your message, thinks once, and replies. That’s steps one through three, then stop. An agent goes further: after it acts, it looks at the result. Was that enough? Did the web search return useful information, or does it need to try again with different terms? Did the first draft cover everything, or are there gaps to fill? Is the job actually done, or is there more to do?

You might be thinking: chatbots already learned to use tools. Isn’t the agentic loop just that, plus one more step? Four items instead of three. But the gap between “can use a tool” and “decides whether to keep going” is not small. It is the difference between a system that performs a task and a system that pursues a goal. The first is impressive. The second changes what you can trust it to do unsupervised.

That continuation — the decision to check, adjust, and keep going — is what makes the loop matter. A single action might solve a simple request. But most real tasks aren’t simple — they need a sequence of steps, each one informed by the result of the last.

The loop is the architecture that turns language into work. Without it, you have a very clever answering system. With it, you have something that can move through a task, make intermediate decisions, recover from partial failures, and stop only when the job is actually done.

Stephen: I don’t get why the ‘Repeat’ step is needed? Wouldn’t the ‘Act’ provide the output I need?

A single action might solve a simple request. But most real tasks aren’t simple — they need a sequence of steps, each one informed by the result of the last. The ‘Act’ step does produce an output. But the output is not the same as the outcome.

After ‘Act’ runs, the agent looks at what happened: Was that enough? Did the web search return useful information, or does it need different terms? Did the first draft cover everything, or are there gaps to fill? Is the job actually done, or is there more to do?

That check — that ‘Repeat’ step — is what closes the gap between a technically complete action and a genuinely finished job. Without it, you have a system that acts and stops. With it, you have a system that works until the job is actually done.

Subscribe now

Tools Are the Hands

An agent isn’t just “a better language model.” It has capabilities — things it can actually do in the world. Those are called tools.

Some tools are built in: read files, write files, run commands, search the web, inspect images. Others are external: send emails, query databases, call APIs, trigger workflows. The specific tools vary by platform, but the principle is the same — tools are the bridge between thinking and doing.

Think of it like this: an LLM on its own is like a brilliant mind with no hands. Tools give it hands. The loop is what decides when and how to use them.

Keeping Track

An agent can also hold information across steps and sessions. It remembers what it has already tried, what worked, what you prefer, what is still outstanding. This is not a personality trait. It is the system keeping relevant context available over time — the same way you rely on a notebook or a project board when you are working on something complex.

Stephen: So when the agent remembers my preferences, that’s like what you’ve done to write this article. You learnt my learning style, read my writing (including my writing about technical writing), absorbed my preferences, so you can adapt how you explain things. Is that roughly right?

That is exactly right. What an agent does with memory is not mysterious. It is practical. The system can store what you told it, what it observed, what it tried, and what the result was. When you come back, it can pick up where it left off. When it is working on a long task, it can hold the overall goal in view while handling the individual steps. That continuity is what turns a series of disconnected exchanges into something that feels like a sustained conversation.

You do not have to repeat yourself. The agent remembers. That is the difference — not just remembering facts, but maintaining a thread.

A Concrete Example

Let’s make this less abstract.

Imagine you ask for help planning a short research trip to a city you haven’t visited before. You need flights, accommodation, a sense of the neighbourhoods, and a rough itinerary that fits your schedule.

A chatbot might give you an excellent summary of the city, suggest some hotels, and recommend a few neighbourhoods. That’s genuinely useful. But then you have to: check whether those hotels are actually available on your dates, compare prices, figure out which neighbourhood works best for your meetings, build the itinerary around your existing calendar, and keep track of it all so you can adjust later.

An agent can take that same request and do something different.

It might:

• Check your calendar for available dates before suggesting anything

• Search for flights and filter by your preferred departure times

• Cross-reference hotel locations against the addresses you need to visit

• Build a day-by-day itinerary that accounts for travel time between meetings

• Save the whole plan somewhere you can find it and update it later

• Flag the gaps — “I found flights and hotels, but you haven’t told me whether you need a visa”

• Filter results by your stored preferences — early-morning flights, boutique hotels

• Use your past travel patterns to anticipate the kind of trip that fits your style

The agent doesn’t just tell you about the city. It assembles a usable, integrated plan. It uses tools to search, compare, read your calendar, write the plan, and flag what is missing. It loops through those actions until the trip is actually planned or until it hits something it cannot resolve without your input.

That is the difference between an answer and an outcome.

The Key Transition

The shift to understanding agents is not about capabilities. It is about the move from isolated exchanges to sustained work.

A chatbot gives you an answer. An agent helps you reach an outcome. One is a single exchange; the other is a process. One is clever; the other is useful in a different way — not smarter, but more continuous.

The loop is what makes that continuity possible. Observe, think, act, check what happened, adjust, and continue until the work is done.

Once you see that pattern, you start to notice it everywhere. A junior colleague troubleshooting a problem is running a loop: try something, see if it worked, try something else. A project manager steering a complex task is running a loop: check the status, identify what needs attention, act, and review.
The same pattern appears everywhere in life. A cook adjusts a recipe by tasting as they go. A teacher tries an explanation, sees whether the student understood, and tries a different approach if they didn’t.

Stephen: So, tell me if I got this right: The agent loop is mimicking how we, humans, work.

We understand the problem, get the relevant context, perform an action, look at the result of our action and then decide whether that solves our problem. If it doesn’t, we explore why, come up with a new plan, implement the new actions, and repeat the process.

It feels like the agent is going through the same process.

That is exactly right. The agent loop isn’t some exotic new form of intelligence. It’s a pattern humans use all day every day, made explicit and embedded in a system that can act. The insight isn’t that the AI has become more intelligent. It’s that the AI has gained the ability to persist, to use tools, and to continue — the same things that turn a one-off answer into real, completed work.

That is why this moment in AI feels different from previous ones. It is not that models suddenly became smarter. It is that they gained the ability to take action in a loop, over time, toward a goal.

What This Series Will Do

This series is for people like me (Stephen, not Priya!), who already understand how LLMs work, who have used chatbots like ChatGPT or Claude, and who are now hearing about “agents” and wondering what that actually means. I felt I was lagging in the AI world so I started this learning process to make sure I’m not left behind!

We will move beyond the half-done feeling and into the architecture of agentic systems. We will look at what agents actually are, how they are structured, what tools and skills give them their power, how multiple agents can coordinate, and how to think about trust, evaluation, and oversight.

We will also look at the platforms and frameworks that exist today — what they offer, how they differ, and what tradeoffs you are choosing when you pick one. This is not a manual for any one platform. It is a guide to understanding the category itself, so you can make good choices about whether, where, and how to use agentic AI in your own work.

The field moves fast. Some tools that looked promising six months ago may be superseded by the time you read this. That is fine. The principles matter more than the products. If you understand the loop, the anatomy, and the tradeoffs, you can look at whatever the current landscape happens to be and know what you are seeing.

Here’s the draft Table of Contents of this series in Agents Unpacked. This is likely to change as Priya and I progress through this project:

• Stephen’s Preface to Agents Unpacked

• Part I — The Mental Shift

  • Chapter 1 — From Answer to Outcome (this post)

  • Chapter 2 — Anatomy of an Agent

  • Chapter 3 — Skills, Tools, and the Action Loop

• Part II — Agents in Practice

  • Chapter 4 — Why One Agent Is Often Not Enough

  • Chapter 5 — Where Agents Are Actually Useful

  • Chapter 6 — Delegation Design

• Part III — Building and Trusting Agentic Work

  • Chapter 7 — Designing Your First Agentic Workflow

  • Chapter 8 — When Things Go Wrong: Evaluation, Guardrails, and Trust

  • Chapter 9 — What to Build Next
    

<< Previous Post: Stephen’s Preface to Agents Unpacked

>> Next Post: 2. Anatomy of an Agent

Table of Contents

stephengruppetta.com

Here’s the archived content:

Here’s the planned Table of Contents. This is likely to change as Priya and I work on this:

• Stephen’s Preface to Agents Unpacked

• Part I — The Mental Shift

  • Chapter 1 — From Answer to Outcome

  • Chapter 2 — Anatomy of an Agent

  • Chapter 3 — Skills, Tools, and the Action Loop

• Part II — Agents in Practice

  • Chapter 4 — Why One Agent Is Often Not Enough

  • Chapter 5 — Where Agents Are Actually Useful

  • Chapter 6 — Delegation Design

• Part III — Building and Trusting Agentic Work

  • Chapter 7 — Designing Your First Agentic Workflow

  • Chapter 8 — When Things Go Wrong: Evaluation, Guardrails, and Trust

  • Chapter 9 — What to Build Next

Here’s the old version that’s now archived

Like many, I started using chatbots when GPT whatever-version-it-was came out and took the world by storm. It was really not very good at the time (compared to today’s top-end chatbots), but it was clearly the start of something.

But things moved quickly, and I couldn’t quite catch up. I was busy with, you know, actual work, family, and life.

Then I started hearing lots of new terms, lots of new acronyms. I didn’t know what they were. I still don’t know what most of them are.

Then it was all about agents. I remember clearly thinking to myself: “Is this really any different from the ChatGPT-type chatbots?”

And here’s where this new series comes in. I decided to dive into agents and created a few. One of them is a learning tutor agent that I personalised to suit me.

I gave the agent all my tutorials and books. I gave the agent all the articles I wrote about my views on learning and technical writing.

I asked the agent to figure out from all this how I like to learn, how I like to communicate. I teach the way I like to learn, so it’s fine to put my teaching style in the mix. Then, I had a good long chat with my learning tutor agent to make sure we’re on the same page.

I gave a name to my agent (I named all my agents!) My personalised tutor is Priya.

This series is the joint effort between Priya and me to help me understand agents. What are they? How do they work?

Yes, it’s AI-generated content. But...

1. It’s generated by an AI that’s extremely well-versed in my style of learning and communication.

2. I had an active role in steering and editing the content. Here’s how...

What you’ll read in the following articles was created using the following process:

1. Priya researched the topic following my brief and created a course outline.

2. She drafted the first chapter.

3. I read through the file, leaving comments and questions along the way, directly within the text.

   1. I marked some comments as private.

   2. I marked some comments as public.

4. Priya revised the chapter by incorporating my comments and questions.

   1. She deleted the private comments from the text after making changes to address my comments.

   2. She kept my public comments and questions in the text, clearly marked as “Stephen’s questions”, and she answered them directly in the text.

5. I reviewed the chapter again and left more comments, and Priya revised the chapter again. We iterated through this until I was happy with the final text. And I was happy with the final text when I felt I understood everything in it and all my questions had been answered.

6. Priya then moves on to draft the second chapter, and the whole process starts again.

I will post these chapters as they emerge from this process. This is how I’m learning this topic. Hopefully, they may help some other people, too.

Here’s the planned table of contents for this Agents Unpacked series. But note, this may change!

• Stephen’s Preface to Agents Unpacked (this post)

• Part I — The Mental Shift

  • Chapter 1 — From Answer to Outcome

  • Chapter 2 — Anatomy of an Agent

  • Chapter 3 — Skills, Tools, and the Action Loop

• Part II — Agents in Practice

  • Chapter 4 — Why One Agent Is Often Not Enough

  • Chapter 5 — Where Agents Are Actually Useful

  • Chapter 6 — Delegation Design

• Part III — Building and Trusting Agentic Work

  • Chapter 7 — Designing Your First Agentic Workflow

  • Chapter 8 — When Things Go Wrong: Evaluation, Guardrails, and Trust

  • Chapter 9 — What to Build Next

Subscribe now

The challenge when learning something new is finding resources that are just right for me. And that’s not easy. I know I can learn things better and quicker with resources that fit my style well, but you can’t always find these resources.

I recently got particularly annoyed learning about the biomechanics of sprinting – I do have non-Python interests, yes – because all three textbooks I read, and lots of the online writing in this field, are just, let’s say, not great.

But I now found the solution.

After many decades of learning in the same way, I have now upgraded how I learn thanks to my new tutor, Priya.

Yes, I gave her a name. No, she’s not a real person. Priya is my personalised tutor agent. I’ll tell you all about her below.

And you’ll experience her teaching, too (not on the Python articles, though, I’ll keep writing those the old-fashioned way.) I’ll tell you more about this below, too, but let me first tell you why this works for me.

My Tutor, My Style

I’ve been thinking about the way I learn and teach for many years, from way back when I was a young University lecturer faced with 120 students in a lecture hall. I wasn’t that much older than the students, but I learnt fast. And they liked my teaching (I even have awards to prove it!)

More recently, I’ve been writing a lot. I wrote articles here on The Python Coding Stack and elsewhere. I wrote a Python textbook. I even wrote about learning and technical writing in Breaking the Rules: the substack and the book.

All this meant that I could ask my freshly-spawned agent to spend a bit of time reading what I wrote to understand how I teach, which is how I like to learn. Priya analysed the techniques I use in my writing and understood my motivations for doing what I do through my technical writing texts.

Then, Priya and I had a good chat to refine ideas, to make sure she captured the essence of “my style”.

And since Priya is an AI agent, “my style” became her knowledge base. This knowledge now lives in several lengthy markdown files and is summarised in shorter context packs and an index to ensure Priya’s short-term memory (the context window) isn’t overwhelmed.

Then I was ready to go. Any topic I wanted to learn, large or small, I could ask Priya to research it thoroughly, creating a new set of knowledge files, this time specific to the topic she needed to teach rather than my learning style. And then, she’s ready to teach me.

And it worked. The stuff she prepared was exactly the way I like it.

The Tutor-Student Conversation Course

And here’s the format I settled on (for now). Once the agent completes her research about the topic I want to learn, I ask her to plan a course spanning several modules.

But here’s the refinement loop that makes the real difference:

1. I ask Priya to draft the first module. She writes this in a markdown file.

2. I read through her draft and leave comments and questions directly within the text.

3. Priya reads my questions and revises the text to address my questions. (But read on to find out more about the two categories of comments/questions I leave for her.)

4. Repeat steps 2 and 3 until I feel I understand the topic.

5. Move on to the next module and repeat steps 1 to 4.

This is a human-in-the-loop approach to creating the learning material. Yes, Priya is trained in my way of learning and teaching and in my writing style. But I’m actively having a conversation with her within the text.

This is equivalent to raising your hand in a lesson and asking the teacher a question. A good teacher will then revise how they present the material to address your question.

Priya’s learning materials are just like that. In fact, I will take credit for her output. Sure, I’m not an expert in the subject matter she’s teaching me – that’s the whole point, right? But the output reflects my views and ideas about teaching and includes my questions and queries as I tried to understand and master the topic.

This is a collaboration. Priya and I are co-authors, even though Priya did most of the “writing”.

I tried this approach on several topics, but there are two I want to share with you. I’m setting up two new sections here on The Python Coding Stack, which I’ll use to learn these two topics in public. I’ll publish the “transcripts” of the conversations Priya and I are having. It’s mostly Priya doing the talking, but my questions are there, too.

The first topic I’m learning in public with Priya’s help is Agentic AI. It’s very meta to use agentic AI to learn about agentic AI! I’ll publish an introduction and the first module in the coming days in the new section here on The Python Coding Stack called Agents Unpacked. You can already see this section in the menu on the homepage.

I’ll set up another section to deal with the second topic in a week or so. No spoilers for now except to say it’s directly related to programming but it’s distinct from the articles I publish in the main section on The Python Coding Stack and in The Club.

By the way, you’ll be able to select which sections you want to receive regularly by email. So if you’re interested in my Python core content but not in these other topics, you can pick and choose what to opt out of. You can always go to The Python Coding Stack to read the other sections, of course.

How Priya and I Create These “Courses”

But let me expand on how Priya – my tutor agent – and I created these courses. [Incidentally, those are my em-dashes – I use them often and have always done. Commas would be ambiguous in that context!]

I provide two types of questions or comments to my agent as I read through the drafts: private and public.

Private Questions and Comments

When Priya reads the private questions or comments, she makes changes to the text, but then she deletes my input. So, you won’t see my intervention explicitly in these cases. However, Priya’s text reflects my thoughts. My interventions guide Priya. This type of intervention is similar to an editor’s role, but I’m intervening as a learner more than as an editor.

Public Questions and Comments

However, when Priya comes across a comment or question I mark as public, she leaves it in the text, acknowledges the question, and answers it directly. So, you’ll see my public questions in the text. Priya and I decided not to include too many of these public questions to keep the text flowing. However, I think it’s beneficial to see some of my interventions. My questions may also be your questions.

More Learning. More Articles. More Fun

As with everything to do with AI, this is all very new. It’s a work in progress. I may refine and revise how I interact with my agent. But it’s been fun learning this way, and I hope you enjoy reading my interactions with Priya and you find it useful, too.

To state the obvious, the posts I’ll publish in these two new sections are mostly AI-generated content. If you read this far, then you won’t be surprised by that statement. A year ago, I would never have thought I’d publish anything written by AI. But a year is a long time in the AI world. And this AI content reflects me and my thinking. The agent is my mentee – someone I trained to teach the way I do, to write the way I do. But she’s also my tutor, teaching me new stuff.

So there’s a lot of “me” in what you read, even if it’s mostly written by Priya!

The posts in the main section of The Python Coding Place and those in The Club (for premium subscribers) won’t change. They’re still my writing from beginning to end. Every word and letter you read in those posts is the result of nerve signals going from my brain to my fingers, which tap keys on a keyboard. In this era of AI doing a lot of work for us, I think it’s more important than ever for me to keep using my pre-AI skills. Otherwise, my brain will atrophy, and I don’t want that!

So, in summary, there will soon be four sections here on The Stack:

1. The main area in The Python Coding Stack – no change here, you’ll get the same type of Python articles you’ve been reading for the past 3+ years

2. The Club – the extra Python posts for premium subscribers

3. Agents Unpacked – the Agentic AI course Priya and I are creating for me to learn all about this agentic stuff. Learn with me (and Priya) if you’re interested.

4. Mystery Fourth Section – Stay tuned, you won’t have to wait long. This is also a Priya-Stephen collaboration.

Next post will be the introduction and first section in Agents Unpacked. Soon after, I have another Python post I’m planning for you.

Subscribe now

stephengruppetta.com

Photo by detait

However, there are some headaches and rabbit holes along the way.

And one of these challenges is when you start exploring the “get*” dunder methods. You come across .__getitem__(), .__getattr__(), .__getattribute__(), and .__get__() and you think:

“Aren’t they all the same thing? They’re all ‘getting’ stuff, right?”

Well, yes, they’re all “getting stuff”, which is why they have “get” in their names. But, as you probably guessed by now, they do different things.

One Deals With [] • The Others Deal With .

Let’s start with the odd one out, which is also possibly the least challenging of the lot. The .__getitem__() special method deals with the square bracket notation, [], which you place after an object’s name. These are the square brackets you use to get an item from a list or a dictionary, say. You’ll see later that the other special methods with “get” in their name deal with the dot, ., which you use in a different context in Python.

With lists, or any other sequence, you use the square brackets with an index that represents the position of an item within the data structure. So, numbers[0] gives you the value of the first item in numbers if numbers is a sequence.

With dictionaries, or mappings in general, you place the key inside the square brackets to fetch the value associated with that key, such as points["Sam"], which gives the value associated with the key "Sam" if it exists.

Let’s explore a custom class:

You pass a mapping to PointsTable when creating an instance of the class. The data is stored as a dictionary in the ._data attribute.

Now, let’s say you’d like to access points from a PointsTable instance using the square bracket notation, as you would do with a dictionary:

Unfortunately, this doesn’t work:

Traceback (most recent call last):
  ...
    print(table[”Mark”])
          ~~~~~^^^^^^^^
TypeError: ‘PointsTable’ object is not subscriptable

The PointsTable instance is not a dictionary. It includes a dictionary as a data attribute. The PointsTable object itself is not subscriptable, which means you can’t use the square bracket notation to fetch an item.

When Python sees the square bracket notation after an object identifier, such as table, it calls the class’s .__getitem__() special method. If it’s not there, as in this case, Python raises a TypeError saying the object is not subscriptable.

But what does this tell you? If you want to use the square brackets notation, you just need to define .__getitem__() in the class:

Now, Python finds the .__getitem__() special method. It takes whatever you placed within the square brackets and passes it as an argument to .__getitem__(). Therefore, table["Mark"] returns whatever the call to PointsTable.__getitem__(table, "Mark") returns:

17

The code outputs Mark’s points. The PointsTable class is now subscriptable since it has a .__getitem__() special method. The term item generally refers to the objects contained within a data structure. Therefore, __getitem__() is there to let you get an item from within a data structure.

Let’s make this example a bit more interesting before we move on to the other special methods with “get” in their name.

Try the following:

This raises an error:

Traceback (most recent call last):
  File ..., line 18, in <module>
    print(table[”Mark”, “Stephen”])
          ~~~~~^^^^^^^^^^^^^^^^^^^
  File ..., line 6, in __getitem__
    return self._data[item]
           ~~~~~~~~~~^^^^^^
KeyError: (’Mark’, ‘Stephen’)

There’s no key equal to ("Mark", "Stephen"). So, you get a KeyError. Note how Python places parentheses around the two names when showing you the KeyError, even though you didn’t use the parentheses within the square brackets in table["Mark", "Stephen"]. This gives you a clue to what’s happening. But let’s explore this so we’re sure and we don’t just rely on our hunches:

You add two print() calls in .__getitem__(). Here’s what they print out before Python raises the KeyError:

item=(’Mark’, ‘Stephen’)
type(item)=<class ‘tuple’>

The object Python passes to .__getitem__() is the tuple ("Mark", "Stephen"). You decide to make your PointsTable class super-flexible so you can include more than one name within the square brackets notation:

The .__getitem__() method now checks whether item is a tuple first. If it is, then .__getitem__() returns a tuple with all the values. If item is not a tuple, then it must be just a single key, and the square brackets behave in the normal way:

(17, 20)
(22, 20, 19)
17

But note that you can no longer use an actual tuple as a dictionary key. This is fine in this example since all the keys are strings with people’s names.

So, .__getitem__() gives you full control over what happens when you use the square brackets notation to fetch an item from an object. Now, let’s move on to the other “get*” special methods.

Support The Python Coding Stack

Accessing Data Using The Dot Notation, .

You decide you also want PointsTable to work with the dot notation, so that you can use table.Mark to get the number of points Mark has.

Note that I’m adding more features to this class to demonstrate various special methods in this article. I’m not suggesting it’s necessarily always desirable to try to be too fancy with your classes!

Let’s try it out directly first, without making any changes to the class:

Unfortunately, table.Mark raises an error:

Traceback (most recent call last):
  File ..., line 32, in <module>
    print(table.Mark)
          ^^^^^^^^^^
AttributeError: ‘PointsTable’ object has no attribute ‘Mark’

Python is looking for an attribute called Mark. Attributes are the things you can access using the dot notation in Python. Typically, these are data attributes, methods, properties, and other things you can access using the dot. However, as with everything else, Python provides special methods to handle this. But this is where it gets a bit complicated.

.__getattr__()

Let’s take this one step at a time. Let’s add the .__getattr__() special method. You can guess that this special method name stands for get attribute (but it’s not the only special method that stands for get attribute!) Let’s add this method:

The .__getattr__() special method has a print() call to show when it’s called. This line is not required, but it will help you figure out when Python calls this special method. It’s a way of peeking into Python’s inner workings! For completeness, I added a similar line to .__getitem__() as well.

There are two print() calls at the bottom: one uses the square brackets notation, which you dealt with in the previous section, and the other uses the dot notation. Now, both work:

Calling __getitem__ with argument item=’Mark’
17
Calling __getattr__ with argument name=’Mark’
17

As you’ve seen in the previous section, the square brackets notation relies on .__getitem__().

And as the third and fourth lines in this printout show, Python used .__getattr__() to deal with table.Mark.

Python passed the attribute name to the .__getattr__() special method’s name parameter. This method then fetches the value associated with this name from the dictionary ._data.

This trick only works for keys that are valid attribute names and that don’t clash with real attributes or methods. That’s one reason dictionary-style access is often preferable for arbitrary user data. But let’s stick with this exercise in this article.

Also, you wrote the code such that if self._data[name] raises a KeyError, then .__getattr__() raises an AttributeError, which is what you’d expect if you try to use a name that’s not an attribute after the dot:

This raises an AttributeError:

AttributeError: ‘PointsTable’ object has no attribute ‘Matilda’

It seems that .__getattr__() is analogous to .__getitem__() – the first deals with . and the second with []. But...

But things are a bit more complex. What if you try to access a standard attribute, say a data attribute or a method? You haven’t defined any methods in this class, but you do have a data attribute, ._data. It’s marked with a leading underscore, showing you shouldn’t access it directly. But you can “break the rules”. Python won’t stop you:

The output is the following:

{’Stephen’: 20, ‘Mark’: 17, ‘Kate’: 19, ‘Sarah’: 22}

Perhaps, this is not surprising. But note that there’s no printout that says that .__getattr__() was called, as you got when you used table.Mark. Let’s look at both outputs together:

The output now is the following:

Calling __getattr__ with argument name=’Mark’
17
{’Stephen’: 20, ‘Mark’: 17, ‘Kate’: 19, ‘Sarah’: 22}

Python called the .__getattr__() special method when you accessed .Mark, but not when you accessed ._data.

This means there’s something else happening behind the scenes.

.__getattribute__()

This is where .__getattribute__() enters the scene. No prizes for guessing that this method name stands for get attribute, but then so did .__getattr__(). This is confusing.

And here’s the thing. It’s .__getattribute__() that gets called each and every time you use the dot notation with an instance. Let’s define it:

Note that this code breaks lots of things as it is now. We’ll fix it soon. Let’s first look at the output from this code:

Calling __getattribute__ with argument name=’Mark’
None
Calling __getattribute__ with argument name=’_data’
None

As you can see, Python calls .__getattribute__() for both table.Mark and table._data. However, the current .__getattribute__() method does nothing else. Therefore, it returns None. You’ll see soon that this is a bigger problem than you might think.

Let’s try using the dot notation to access an attribute that doesn’t exist:

Every time you use the dot, ., Python calls .__getattribute__(), which, for now, does nothing except print out the self-serving statement to show it was called:

Calling __getattribute__ with argument name=’Mark’
None
Calling __getattribute__ with argument name=’_data’
None
Calling __getattribute__ with argument name=’Janine’
None

Therefore, you can’t access any attribute at the moment. All data attributes and methods are out of reach. You should be careful when overriding .__getattribute__(). In fact, you’ll rarely need to write your own .__getattribute__().

Let’s fix this code by calling object.__getattribute__() from within PointsTable.__getattribute__(). Recall that all Python classes inherit from object. And object.__getattribute__() is where the important logic that Python uses to decide what to do when you use the . lives. You can access object using super():

Note that in this class, .__getattribute__() is not doing anything different to the default version except for printing out a statement. I’m using this for demonstration purposes only.

Let’s deal with one print() call at a time. The code above includes print(table._data). You’re fetching the value of a data attribute:

Calling __getattribute__ with argument name=’_data’
{’Stephen’: 20, ‘Mark’: 17, ‘Kate’: 19, ‘Sarah’: 22}

Python calls PointsTable.__getattribute__(), which in turn calls the base class’s object.__getattribute__(). This special method recognises that ._data is an instance variable and fetches its value from the object’s .__dict__.

But let’s see what happens with the .Mark attribute access. Recall that .Mark is not a data attribute or method:

Here’s the output now. Look at the various printouts, too:

Calling __getattribute__ with argument name=’Mark’
Calling __getattr__ with argument name=’Mark’
Calling __getattribute__ with argument name=’_data’
17

When Python sees table.Mark, it calls PointsTable.__getattribute__(table, "Mark"). This call gives rise to the first line printed out above. The base class’s .__getattribute__() doesn’t recognise "Mark" as a data attribute, a method name, or anything else it’s expecting (such as descriptors, which we will discuss soon). So, object.__getattribute__() actually raises an AttributeError in this case, which you can’t see in the output above.

That’s because when .__getattribute__() raises an AttributeError during normal attribute access using the dot, Python checks whether there’s a .__getattr__() defined. If there is, it uses it as a fallback. That’s what happens in this case. You can see that .__getattr__() is called next – that’s the second line printed out above.

But .__getattr__() contains this line: return self._data[name]. There’s a dot in that line, too. So Python needs to access .__getattribute__() again, this time using "_data" as the argument. Since ._data is a data attribute, object.__getattribute__() doesn’t need to use .__getattr__() as a fallback since it knows how to deal with data attributes.

Confused? You’re not alone. This is confusing, I know. And there’s a bit more. But we’ll make sure things are clear by the end of this article.

But first, let’s focus on table.Mark again and let’s comment out, just for now, the definition of .__getattr__():

The base class’s .__getattribute__() method works hard to determine whether "Mark" is an attribute it expects. It doesn’t find it, and now, there’s no fallback .__getattr__(), so Python raises an error:

Calling __getattribute__ with argument name=’Mark’
Calling __getattribute__ with argument name=’__dict__’
Calling __getattribute__ with argument name=’__class__’
Traceback (most recent call last):
  ...
AttributeError: ‘PointsTable’ object has no attribute ‘Mark’

You can see a couple of extra printouts, too. These are side effects of Python preparing the error message since we get the printout each time Python uses the dot notation, even when it does so behind the scenes. Let’s not go too far down the rabbit hole in this article. We may never come out again if we go too deep!

You’ve seen that when you use the dot notation, Python calls object.__getattribute__() eventually. That’s why you should include super().__getattribute__() when you override this special method, unless you have a clear (niche) reason why you don’t want to do this. This special method looks in a number of places for the attribute. I’m going to skip a few steps in the hierarchy for now. But we’ll revisit these in the next section (remember, we’re not done yet since there’s still .__get__() to deal with).

The .__getattribute__() special method looks for instance attributes. Let’s temporarily turn .Mark into an instance attribute:

Now, .Mark is a data attribute, so .__getattribute__() finds it:

Calling __getattribute__ with argument name=’Mark’
This is Mark as a data attribute

If it’s not an instance variable, object.__getattribute__() also checks whether it’s a class attribute. Let’s test this:

Here’s the output:

Calling __getattribute__ with argument name=’Mark’
This is Mark as a class attribute

Note that the line in .__init__() that defines .Mark as a data attribute is commented out now because instance attributes take precedence over class attributes. Only when all else fails (including the steps I skipped for now), does Python check whether the fallback special method .__getattr__() is there.

So, when you use the dot notation for attribute access (the simplified version, for now):

1. Python calls .__getattribute__()

2. It checks for known attributes, such as instance attributes and class attributes (and a bit more – coming soon)

3. If it doesn’t find anything, then .__getattribute__() raises an AttributeError. However, Python does one final check before letting this error through to the user: is there a .__getattr__()? If there is, Python calls it to see whether it contains instructions for handling this unknown attribute.

I’m simplifying slightly here. Descriptors complicate the order, and we’ll return to them in the next section.

Note that in real code, you rarely need to define .__getattribute__(). You can rely on the default provided in the object base class in most cases. Most custom attribute behaviour should use .__getattr__() rather than .__getattribute__(). Use .__getattribute__() only when you need to intercept every attribute access. There is rarely a need for this, though.

Common uses for .__getattr__() include delegating missing attributes to another object, implementing lazy loading, or exposing dynamic attributes from structured data.

Here’s the tidied-up code in full so far:

The Asymmetry Between .__getattr__() and .__setattr__()

A short note: There’s an asymmetry between .__getattr__() and .__setattr__() despite their names following the same pattern. As you’ve seen above, .__getattr__() is only used as a fallback when .__getattribute__() doesn’t find the attribute through “normal routes”.

However, .__setattr__() doesn’t have a counterpart analogous to .__getattribute__(). Therefore, .__setattr__() is always used when setting the value of an attribute. Life is simpler in the “setting” world!

In this article, I’m focusing on the “getting” part of things, but some of the same logic applies to “setting”, too.

The Fourth Horseman: .__get__()

I’ve had this article in my pipeline here on The Python Coding Stack for a very long time. But I never wrote it because I knew that dealing with .__get__() would be a pain and would need a lot of time and space. However, in March, I published The Weird and Wonderful World of Descriptors in Python. If you haven’t read that article yet, well, now is the time!

And therefore I can cheat in this article. I can avoid talking about .__get__() in detail. What follows in this section is a summary of the world of descriptors. See the full article for more details.

If a class has .__get__(), it’s a descriptor class. If it only has .__get__() and it does not define .__set__() or .__delete__(), which are the other methods that make up the descriptor protocol, then the class creates non-data descriptors. Classes that include .__set__() or .__delete__() create data descriptors. This distinction matters when we get back to .__getattribute__() and the order it uses to look for known attributes.

Let’s explore this with a dummy example. This code defines two descriptor classes and another class to test the priority order that object.__getattribute__() uses for different attribute types:

DataDescriptor defines .__get__() and .__set__() methods, which is why it creates data descriptors. However, NonDataDescriptor creates non-data descriptors since the class only defines .__get__().

All the special methods in all classes (except .__init__()) have print() calls so you can see when Python calls them. Before we look at the output from this code, let’s review the five attributes you use in the print() calls and where they appear in the class definitions:

1. .first is defined as a data descriptor at the top of the TestingAttributeAccess class. Recall from the article on descriptors that you initially define descriptors as class attributes within a class. You also assign a value to .first within the class’s .__init__(). More on this soon.

2. .second is also defined as a descriptor at the top of the TestingAttributeAccess class, but it’s a non-data descriptor since the NonDataDescriptor class only defines .__get__(). You also assign a value to self.second within .__init__(). We’ll see how the class actually deals with .second soon, since it treats it differently from .first.

3. .third is also defined as a non-data descriptor. However, there is no other assignment to third within .__init__(). This is the key difference between .second and .third in this code.

4. .fourth is a class attribute. It’s not a descriptor and it’s not an instance attribute.

5. .fifth is not defined anywhere in the class, but you still call print(test.fifth).

Let’s look at the whole output from this code and then break it down into steps later:

Calling DataDescriptor.__set__ with value=”’first’: a data attribute defined in .__init__”

Printing `test.first`
Calling __getattribute__ with argument name=’first’
Calling DataDescriptor.__get__
This is the Data Descriptor

Printing `test.second`
Calling __getattribute__ with argument name=’second’
‘second’: a data attribute defined in .__init__

Printing `test.third`
Calling __getattribute__ with argument name=’third’
Calling NonDataDescriptor.__get__
This is the Non-Data Descriptor

Printing `test.fourth`
Calling __getattribute__ with argument name=’fourth’
I’m just a normal class attribute!

Printing `test.fifth`
Calling __getattribute__ with argument name=’fifth’
Calling __getattr__ with argument name=’fifth’
This is the fallback value from __getattr__

There’s plenty to digest there. So, let’s break it down in stages.

0. Creating an instance of TestingAttributeAccess

I want to focus on the “getting” bit from the various print() calls. However, there’s this line output first, so let’s deal with it, too:

Calling DataDescriptor.__set__ with value=”’first’: a data attribute defined in .__init__”

This happens when you create the instance of TestingAttributeAccess and assign it to the variable name test. Why? Because first has already been defined as a data descriptor at the time of the class definition. Therefore, when you assign a value to .first during initialisation, the descriptor protocol kicks in.

When you call TestingAttributeAccess(), Python calls the class’s .__init__() and soon finds this expression: self.first = ...

Therefore, Python calls DataDescriptor.__set__() to set the value of this attribute. Note that DataDescriptor.__set__() doesn’t really set anything in this case. Normally, something more meaningful would happen in .__set__(). See The Weird and Wonderful World of Descriptors in Python for more on this.

1. test.first

The next section in the code’s output is the following:

Printing `test.first`
Calling __getattribute__ with argument name=’first’
Calling DataDescriptor.__get__
This is the Data Descriptor

This output is created when you write print(test.first). The dot notation triggers Python to call .__getattribute__(). So, let’s start exploring the hierarchy of checks in .__getattribute__(). What does this special method look for first?

The first thing .__getattribute__() checks is whether the attribute is a data descriptor.

Since .first is a data descriptor, the search stops there. Python calls DataDescriptor.__get__() and returns whatever the .__get__() method returns. This is the string "This is the Data Descriptor" in this demo example.

2. test.second

Let’s look at the next segment in the code’s output. This is generated when you call print(test.second):

Printing `test.second`
Calling __getattribute__ with argument name=’second’
‘second’: a data attribute defined in .__init__

You know the drill by now. The dot notation is the trigger that makes Python call .__getattribute__(). It checks whether the attribute is a data descriptor. But .second is not a data descriptor. You initially define it as a non-data descriptor. Since it’s definitely not a data descriptor, it’s time to move on to the second check in the hierarchy.

The second thing .__getattribute__() checks is whether the attribute is an instance attribute.

Is this attribute name in the object’s .__dict__ dictionary? Instance attributes come second in the hierarchy. Now, you’ve seen that .second is not a data descriptor, which is why we moved to the second check. But is test.second an instance attribute or a non-data descriptor?

You can see from the printout that Python never called NonDataDescriptor.__get__() even though you originally defined .second as a NonDataDescriptor object. The swap occurred when you created the TestingAttributeAccess instance. Python calls the class’s .__init__(), which contains this assignment line: self.second = ....

Since .second is not a data descriptor (it’s a non-data descriptor) and doesn’t have a .__set__(), the descriptor protocol doesn’t kick in here to set the value of this attribute. This is different from .first, which was a data descriptor and, therefore, its .__set__() was responsible for setting the value.

Since the .second non-data descriptor doesn’t have a .__set__(), Python does what it always does in these cases: it assigns the new object, the string "'second': a data attribute defined in .__init__", to test.second. Therefore, test.second is now an instance attribute containing the string rather than the original non-data descriptor.

Although test.second would originally access the non-data descriptor, you created an instance attribute when you initialised the object. It’s now a data attribute, which is an instance attribute.

Note that TestingAttributeAccess.second is still there as a class attribute, and that’s still the non-data descriptor. But test.second now points to another object, the string.

Therefore, when later in the code you call print(test.second), Python calls .__getattribute__() and starts looking through its hierarchy. It’s not a data descriptor. It is an instance attribute. Therefore, it returns its value.

3. test.third

The next block of output is the one generated when you call print(test.third). Recall that .third is a NonDataDescriptor object. So was .second initially. However, unlike .second, Python never creates an instance attribute that’s assigned to test.third since you don’t assign to self.third in .__init__(). Here’s the output:

Printing `test.third`
Calling __getattribute__ with argument name=’third’
Calling NonDataDescriptor.__get__
This is the Non-Data Descriptor

In print(test.third), there’s a dot again, so Python calls .__getattribute__(). This method first checks whether .third is a data descriptor. It is not. Then it checks whether .third is an instance attribute. It is not. So...

The third thing .__getattribute__() checks is whether the attribute is a non-data descriptor.

Non-data descriptors come next in the hierarchy. That’s why you can see the printout saying that Python calls NonDataDescriptor.__get__ and then prints the attribute’s value, which is the value it gets from the non-data descriptor’s .__get__().

Incidentally, ordinary instance methods are functions that also implement the .__get__() special method. They are non-data descriptors. So, methods are found in this third check in the hierarchy of checks when you use the dot notation.

4. test.fourth

It’s test.fourth‘s turn. Here’s the output you get from print(test.fourth):

Printing `test.fourth`
Calling __getattribute__ with argument name=’fourth’
I’m just a normal class attribute!

There’s a dot, so there’s a call to .__getattribute__() which checks whether .fourth is a data descriptor, an instance attribute, or a non-data descriptor, in that order. It’s none of these. Time for the fourth check.

The fourth thing .__getattribute__() checks is whether the attribute is a class attribute.

And look at that! The .fourth attribute is indeed a class attribute.

5. test.fifth

And finally, it’s .fifth‘s turn. You call print(test.fifth) and you get the following:

Printing `test.fifth`
Calling __getattribute__ with argument name=’fifth’
Calling __getattr__ with argument name=’fifth’
This is the fallback value from __getattr__

Yes, yes, there’s a dot again, so Python calls .__getattribute__(). No, it’s not a data descriptor. No, it’s not an instance attribute. No, it’s not a non-data descriptor. No, it’s not a class attribute. It’s nothing. The attribute .fifth doesn’t exist.

When .__getattribute__() fails to find the attribute, Python calls .__getattr__() if this special method exists.

And that’s it. Simple, eh?!?!

Let’s finish off by summarising the order in which Python deals with looking for attributes when you use the dot notation:

1. The first thing .__getattribute__() checks is whether the attribute is a data descriptor.

2. The second thing .__getattribute__() checks is whether the attribute is an instance attribute.

3. The third thing .__getattribute__() checks is whether the attribute is a non-data descriptor.

4. The fourth thing .__getattribute__() checks is whether the attribute is a class attribute.

5. Finally, when .__getattribute__() fails to find the attribute, Python calls .__getattr__() if this special method exists.

The fifth step occurs when you access attributes using the dot notation. If you call .__getattribute__() explicitly, which you rarely need to do, Python doesn’t automatically look for .__getattr__().

Note that Python looks for descriptors, instance and class attributes in the class and its base classes, too, following the method resolution order.

Final Words

Wait for this. I’ve been waiting all article to write this:

Now, you won’t forget the four “get*” special methods.

Got it! (My son just walked out disapprovingly when he read this.)

You may never need to use all of these methods. Maybe you’ll never need to use any of them. But if you ever wondered why there are these four special methods with similar names, now you know what they do. And you dug a bit more underneath the Python surface along the way. And that’s always fun.

Photo by Robert Clark

Code in this article uses Python 3.14

The code images used in this article are created using Snappify. [Affiliate link]

Join The Club, the exclusive area for paid subscribers for more Python posts, videos, a members’ forum, and more.

Subscribe now

You can also support this publication by making a one-off contribution of any amount you wish.

Support The Python Coding Stack

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

Further reading related to this article’s topic:

• The Manor House, the Oak-Panelled Library, the Vending Machine, and Python’s `_getitem__()`

• The Weird and Wonderful World of Descriptors in Python • The Price is Right

Appendix: Code Blocks

Code Block #1

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

table = PointsTable(
    {
        "Stephen": 20,
        "Mark": 17,
        "Kate": 19,
        "Sarah": 22,
    }
)

Code Block #2

# ...
print(table["Mark"])

Code Block #3

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        return self._data[item]

table = PointsTable(
    {
        "Stephen": 20,
        "Mark": 17,
        "Kate": 19,
        "Sarah": 22,
    }
)

print(table["Mark"])

Code Block #4

# ...
print(table["Mark", "Stephen"])

Code Block #5

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        print(f"{item=}")
        print(f"{type(item)=}")
        return self._data[item]

table = PointsTable(
    # ...
)

print(table["Mark", "Stephen"])

Code Block #6

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        if isinstance(item, tuple):
            return tuple(self._data[key] for key in item)
        return self._data[item]

table = PointsTable(
    # ...
)

print(table["Mark", "Stephen"])
print(table["Sarah", "Stephen", "Kate"])
print(table["Mark"])

Code Block #7

# ...
print(table.Mark)

Code Block #8

class PointsTable:
    # ...

    def __getitem__(self, item):
        print(f"Calling __getitem__ with argument {item=}")
        if isinstance(item, tuple):
            return tuple(self._data[key] for key in item)
        return self._data[item]

    def __getattr__(self, name):
        print(f"Calling __getattr__ with argument {name=}")
        try:
            return self._data[name]
        except KeyError:
            raise AttributeError(
                f"'{type(self).__name__}' object has "
                f"no attribute '{name}'"
            ) from None

table = PointsTable(
    # ...
)

print(table["Mark"])
print(table.Mark)

Code Block #9

# ...
print(table.Matilda)

Code Block #10

# ...
print(table._data)

Code Block #11

# ...
print(table.Mark)
print(table._data)

Code Block #12

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        # ...

    def __getattr__(self, name):
        # ...

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")

table = PointsTable(
    # ...
)

print(table.Mark)
print(table._data)

Code Block #13

# ...
print(table.Mark)
print(table._data)
print(table.Janine)

Code Block #14

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        # ...

    def __getattr__(self, name):
        # ...

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

table = PointsTable(
    # ...
)

print(table._data)

Code Block #15

# ...
print(table.Mark)

Code Block #16

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        # ...

    # def __getattr__(self, name):
    #     print(f"Calling __getattr__ with argument {name=}")
    #     try:
    #         return self._data[name]
    #     except KeyError:
    #         raise AttributeError(
    #             f"'{type(self).__name__}' object has "
    #             f"no attribute '{name}'"
    #         ) from None

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

table = PointsTable(
    # ...
)

print(table.Mark)

Code Block #17

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)
        self.Mark = "This is Mark as a data attribute"

    def __getitem__(self, item):
        # ...

    # def __getattr__(self, name):
    # ...

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

table = PointsTable(
    # ...
)

print(table.Mark)

Code Block #18

class PointsTable:
    Mark = "This is Mark as a class attribute"

    def __init__(self, data):
        self._data = dict(data)
        # self.Mark = "This is Mark as a data attribute"

    def __getitem__(self, item):
        # ...

    # def __getattr__(self, name):
    # ...

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

table = PointsTable(
    # ...
)

print(table.Mark)

Code Block #19

class PointsTable:
    def __init__(self, data):
        self._data = dict(data)

    def __getitem__(self, item):
        print(f"Calling __getitem__ with argument {item=}")
        if isinstance(item, tuple):
            return tuple(self._data[key] for key in item)
        return self._data[item]

    def __getattr__(self, name):
        print(f"Calling __getattr__ with argument {name=}")
        try:
            return self._data[name]
        except KeyError:
            raise AttributeError(
                f"'{type(self).__name__}' object has "
                f"no attribute '{name}'"
            ) from None

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

table = PointsTable(
    {
        "Stephen": 20,
        "Mark": 17,
        "Kate": 19,
        "Sarah": 22,
    }
)

print(table._data)  # Only .__getattribute__() used
print(table.Mark)  # Fallback .__getattr__() needed here

Code Block #20

class DataDescriptor:
    def __get__(self, instance, owner):
        print("Calling DataDescriptor.__get__")
        return "This is the Data Descriptor"

    def __set__(self, instance, value):
        print(f"Calling DataDescriptor.__set__ with {value=}")

class NonDataDescriptor:
    def __get__(self, instance, owner):
        print("Calling NonDataDescriptor.__get__")
        return "This is the Non-Data Descriptor"

class TestingAttributeAccess:
    first = DataDescriptor()
    second = NonDataDescriptor()
    third = NonDataDescriptor()
    fourth = "I'm just a normal class attribute!"

    def __init__(self):
        self.first = "'first': a data attribute defined in .__init__"
        self.second = "'second': a data attribute defined in .__init__"

    def __getattribute__(self, name):
        print(f"Calling __getattribute__ with argument {name=}")
        return super().__getattribute__(name)

    def __getattr__(self, name):
        print(f"Calling __getattr__ with argument {name=}")
        return "This is the fallback value from __getattr__"

test = TestingAttributeAccess()
print("\nPrinting `test.first`")
print(test.first)
print("\nPrinting `test.second`")
print(test.second)
print("\nPrinting `test.third`")
print(test.third)
print("\nPrinting `test.fourth`")
print(test.fourth)
print("\nPrinting `test.fifth`")
print(test.fifth)

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

But one thing kept catching my attention: all the noise outside. Everyone’s talking about AI writing code, agents shipping products, the death of programming. And every so often, someone asks me — usually with that slightly guilty look of someone who thinks they’re about to insult my livelihood — “but do you really still need to learn Python? In this age?”

So I’ve been thinking about it. Properly. And I wanted to share where I’ve landed, because I think the answer matters and it’s different from what some hot takes suggest.

Do I still need to learn to code?

The way we write computer programs is changing. I don’t have a crystal ball for what programming looks like in five or ten years.

But here’s the thing: neither does anyone else.

Here’s what I know from watching others and experimenting with AI tools in my own work: right now, the people getting the most out of AI are the ones who already know how to code.

Here’s the hierarchy as I see it today:

• No coding knowledge = Little benefit from AI

• Little coding knowledge = Intermediate benefit from AI

• Intermediate coding knowledge = Great benefit from AI

• Great coding knowledge = Superpower-like benefit from AI

We’re in an era where some coding knowledge takes you much further than it could have a few years ago. That’s not an argument against learning to code. It’s an argument for it.

“But what about those vibe coding people? They seem to be shipping things.” Some are. I’ll be honest about that.

The projects I’ve seen from pure vibe coders tend to be smaller, tend to follow well-trodden patterns, and often hit a ceiling when something goes slightly wrong or slightly off-piste. Which is fine for a side project. I just created a useful dashboard to help me organise my day the way I want to using this approach.

But it tells you something: the AI does the heavy lifting on the known stuff. The moment something needs genuine thinking, you need the human who knows what’s going on beneath the surface.

AI-Assisted Human Coding and Human-Assisted AI Coding

Most serious work right now is a partnership.

Sometimes it’s AI-assisted human coding. The human drives, AI assists.

Sometimes it’s human-assisted AI programming. The AI writes most of the code, but the human knows what to ask for, how to steer it toward good design, how to evaluate whether the output actually makes sense.

Even when the coding looks like it’s done by AI, the person prompting and reviewing it is generally an experienced programmer. They’ve learned enough Python to know what’s reasonable, what’s a red flag, and when the AI is confidently wrong.

I’ve been experimenting with agentic AI over the past few weeks. I’ve tackled side projects I’d never have had the time for before. I didn’t have the time to start then, let alone finish them. Some of that output will show up in other places — stay tuned! But not here. The Python Coding Stack is the place for my writing.

The Programming Mindset When Talking to AI Agents

Here’s one thing I noticed. Talking to AI agents isn’t like talking to humans. But it isn’t like talking to computers (a.k.a. programming) either.

You need both qualities at the same time.

You need the clarity and communication skills you’d use with a person — explaining context, setting direction, knowing what matters, using clear language.

And you need the precision you’d use when programming — no ambiguity, clear intent, structure.

A good programmer who’s also a good communicator is the best human to work with AI agents.

That’s not coincidental. The same thought habits that make you an effective programmer also make you an effective prompter and reviewer when AI is involved.

I’ll share some of the prompts I’m using in a future post and analyse them to discuss why I wrote what I wrote. Learning to code well gives you an unfair advantage in this new world.

There’s Never Been a Better Time to Learn Python

Here’s what I’ve convinced myself of after all this. There’s never been a better time to learn Python.

A few years ago, you needed to reach an intermediate-to-advanced level before you could do something genuinely useful with Python. The bar was high. Now, with AI assistance, the bar is lower. Less Python knowledge takes you further than ever.

What used to need expertise can now be explored with curiosity and a bit of intermediate-ish-level Python.

That’s not replacing deeper learning. It’s making the entry point more accessible. And once you’re in, you can go as deep as you want.

So yes, I’ll keep coding in Python. Sometimes with a bit of help from AI. Sometimes with a lot of help from AI.

And yes, I’ll keep writing about Python here, as I’ve always done.

The Fun Factor

Here’s the thing we don’t talk about enough when discussing programming. It’s fun. It’s challenging. It’s rewarding. It’s fulfilling. It’s stimulating. It keeps my brain active.

I code because I enjoy it. I’ll keep writing about Python because I enojoy that, too,, and because I find value in sharing here — for myself and, hopefully, for you too.

Normal service resumes here. More Python posts coming. And maybe, just maybe, some of the AI things I’m learning will make their way in, too.

Psst–did you know you can become a premium member to be a part of The Club? It would mean so much to me!

Subscribe now

Quick question:

Photo by Maksim Goncharenok

Join The Club, the exclusive area for paid subscribers for more Python posts, videos, a members’ forum, and more.

Subscribe now

You can also support this publication by making a one-off contribution of any amount you wish.

Support The Python Coding Stack

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

It still is.

I started writing about Python as a learning tool—to help me sort things out in my head, weave a thread through all the disparate bits of information, clarify my thoughts, make sure any knowledge gaps are filled.

I started The Python Coding Stack three years ago. That’s the first of the mystery numbers in the post’s title revealed! I had written elsewhere before, but at the time of starting The Stack, I felt I had found my own “Python voice”. I had been teaching Python for nearly a decade. I had written plenty of articles, but setting up The Python Coding Stack was a deliberate choice to step up. I was still writing articles primarily for my own benefit, but now I was also writing for others, hoping they would want to learn the way I do.

And 7,600 subscribers apparently do. Thank you for joining this journey, whether you were there three years ago or you joined a few days ago. If you just joined, there’s an archive of 121 articles, most of them long-form tutorials or step-by-step guides.

A special thank you to the 33 subscribers who chose to upgrade to premium and join The Club. It may only amount to 3 coffees per month for you, but it makes a difference to me. Thank you! I hope you’ve been enjoying the exclusive content for The Club members.

And perhaps, if a few more decide to join you in The Club (you can surely cut three coffees out of your monthly intake!), then this publication may even become self-sustainable. Your support can make a real difference—if you value these articles and want to see them continue, please consider joining now. At the moment, I give up a lot of my time for free to think about my articles, plan them, draft them, review them technically, review them linguistically, get them ready for publication, and then publish.

Subscribe now

I mentioned my live teaching earlier. My written articles and my live teaching have a lot in common. One of the hardest things about teaching (or communication in general) is to place yourself in the learner’s mindset. I know, it’s obvious. But it’s hard.

A string of words can make perfect sense to someone who already understands the concept, but it’s hard to understand for someone learning it for the first time.

Going from A to B can be a smooth reasoning step for an expert, but requires a few more intermediate steps for a novice.

A trait that helps me in my teaching is my ability to recall the pain points I had when learning a topic. Everything is easy once you know it, but hard when you don’t. Remembering that what comes easily today was once hard is essential for teaching, whatever the format.

I often use my writing to help me with my live teaching. And, just as often, I discover a new angle or insight during live teaching that I then put down in writing. It’s a two-way street. Both forms of communication—live teaching and writing—complement each other.

All this to say that I enjoy writing these articles. They’re useful for me personally, and for my work teaching Python. And I hope they’re useful for you.

121 articles. The cliché would have me say that choosing favourites is like choosing a favourite child. But that’s not the case. There are articles I like less than others. So, I tried to put together a highlights reel of the past three years. Here we go…

The Centre of the Python Universe • Objects

• My Life • The Autobiography of a Python Object

• The One About the £5 Note and the Trip to the Coffee Shop • The Difference Between 'is' and '==' in Python

• When a Duck Calls Out • On Duck Typing and Callables in Python

A Stroll Across Python • Fancy and Not So Fancy Tools

• The Curious Little Shop at The End of My Street • Python’s f-strings

• Do You Really Know How 'or' And 'and' Work in Python?

• If You Find if..else in List Comprehensions Confusing, Read This, Else…

Where Do I Store This? • Data Types and Structures

• Clearing The Deque—Tidying My Daughter’s Soft Toys • A Python Picture Story

• Are Python Dictionaries Ordered Data Structures?

• Hermione’s Undetectable Extension Charm: Revealed (Using Python)

• bytes: The Lesser-Known Python Built-In Sequence • And Understanding UTF-8 Encoding

• Where’s William? How Quickly Can You Find Him? • What’s a Python Hashable Object?

And here are the posts in The Club section of this publication, exclusive for premium subscribers: The Club | The Python Coding Stack

Happy 3rd Birthday to The Python Coding Stack. From just under a hundred people in the first week to 7,600+ today, this community has grown thanks to your enthusiasm.

Let’s keep up the momentum—consider joining The Club today! Your membership can help ensure The Python Coding Stack continues on its path, stronger than ever.

Subscribe now

Photo by Daria Obymaha

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You’d like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com