Machine Learning Mastery showed how to build AI agents in Python with Pydantic AI

Machine Learning Mastery published on April 29, 2026 a detailed breakdown of Pydantic AI — a Python framework for building AI agents with type-hinting, validation, and built-in tools. The material shows how to transform work with LLMs from a set of fragile strings and parsers into a more predictable production process.

Why

This Matters The article's main idea is simple: most agent scaffolding still resembles glue code. A model returns a string, a developer hopes there will be valid JSON, then manually parses the response, catches errors, and adds exception handling at every step. Pydantic AI offers a different path.

Instead of unstructured responses, it builds workflows around Pydantic models, schemas, type checking, and automatic retries if the model output doesn't match the expected structure. For Python developers, this means less magic and more code that can be tested, read, and maintained. The article demonstrates this with the most basic example: an agent is created in just a few lines, and the model is specified via a string format provider:model-name.

The author uses openai:gpt-4o-mini, but separately emphasizes that the same template works with other providers, including Anthropic and Gemini. Agent instructions are set once, after which you can run either a synchronous scenario via run_sync or an asynchronous variant with the same API. This keeps the barrier to entry low and prevents the architecture from falling apart at the first sign of logic complexity.

What the

Approach Consists Of The most useful part of the material is the breakdown of four mechanisms that underpin practical agent workflow in Pydantic AI. The author doesn't retreat into abstraction or describe the framework at the level of promises: each block is accompanied by a short code example and an explanation of how it solves a specific production development pain point, without unnecessary theory. The result is an article that reads like a map of the minimal set of solutions for a first working agent in Python.

output_type forces the model to return data in the form of a validated Python object rather than arbitrary text. @agent.tool_plain turns an ordinary Python function into a tool that the agent can call during reasoning.

deps_type and RunContext provide dependency injection without global state and hidden dependencies. capabilities connect additional features like WebSearch and Thinking without overloading the constructor. The author separately shows how this looks in the example of extracting data from a job posting.

The developer describes a JobPosting model with fields like position, company, list of skills, seniority level, and remote-work indicator, and the agent returns a ready-made object instead of raw text. If a field is missing or the type doesn't match, the framework validates the response and tries again before the error propagates further into the application. This removes the typical pain of all systems where an LLM must output data suitable for immediate use in code.

How This Leads to Production The second major example in the article is devoted to tool calling.

The author takes a simple nutrition database and registers a function that returns calories, proteins, carbohydrates, and fats per 100 grams for an ingredient name. Then the agent receives a request like analyzing a dish, calls the tool for each ingredient itself, sums the values, and delivers the result in the form of a MealSummary model. The output is not a chat response in free form, but a structured summary with total figures, a verdict on composition, and a recommendation.

An important detail: the docstring of the function here is not cosmetic, but part of the contract by which the model understands when and why to call the tool. Even more important is the section on dependency injection. Instead of a hard-coded dictionary base, the author wraps the data source in a NutritionService class, and then passes it to the agent via deps and a typed RunContext.

This makes the code much closer to real-world operation: the dictionary can be replaced by a database, an API client, a user session, or any other runtime dependency. Plus, proper testability appears. In the example, the service is easily substituted with a mock, and the agent continues to work without changes to its core logic.

The final layer is built-in capabilities. The article covers at least two: WebSearch for access to current data from the internet and Thinking for deeper step-by-step reasoning on complex tasks. They can be combined in one agent, for example for a research assistant that itself decides what to search for, then gets fresh results and only then formulates an answer.

At the end, the author separately mentions integration with Logfire for observability: you can see model calls, tool triggers, and validation retry attempts.

What

This Means Machine Learning Mastery's material is useful because it shifts the conversation about AI agents from demo mode to engineering practice mode. Pydantic AI is shown here not as another wrapper over an LLM, but as a way to impose discipline in types, dependencies, and tools. For Python teams, this is a good signal: agents can be built without a heavy orchestrator if they rely from the start on validated schemas, explicit contracts, and testable runtime components.