Pydantic at the input, ontology at the result

Video segment: 17:46–18:46

The speaker's design rule is:

Pydantic at the door, ontology at the ledger.

This is a division of labor between two different checks. Pydantic checks the input that is about to enter a tool call. The ontology checks the result after the tool has run. The first check asks whether the request has the right shape and parameter types. The second asks whether the result makes sense in the domain.

Why check the input first?

The speaker recommends looking at Pydantic when coding with agents. His contrast uses Python: a variable can first receive a number and later receive a string. In his explanation, typed validation gives the program a way to specify what kind of value a parameter should contain and to flag a mismatch.

For example, imagine a tool that expects an order identifier in one particular form. The language model may produce a tool call with an argument that has the wrong type. Input validation can detect that problem before the tool receives the request.

LLM proposes tool arguments
          ↓
Pydantic checks parameter types and shape
          ↓
tool runs only if the input passes

Teaching context: This is like checking a form at a building's entrance. The check can confirm that required fields have the expected kinds of values. It does not decide whether the person's later actions are sensible in the wider organization.

Why is input validation not enough?

A request can be well-formed and still produce an unreasonable result. A tool may accept the parameters and return text or data that conflicts with the organization's domain rules. A type checker alone does not know all the meanings and relationships represented in an ontology.

That is why the ontology belongs at the ledger in the speaker's metaphor. The ledger represents what the system now says happened or what state it is about to propagate. Ontology-based validation can check that returned information against domain concepts, relationships, and constraints.

The complete pipeline is therefore:

model proposes parameters
          ↓
Pydantic validates the incoming tool request
          ↓
tool returns information
          ↓
ontology validates the result against domain rules
          ↓
accept, revise, or intervene before committing a change

Click to enlarge

Source visual: The slide directly depicts the architecture summary described by the speaker: Pydantic checks the input before the tool runs, the ontology checks the returned result against domain rules before propagation, and the agent is kept free of intermediate side effects.

Keep the agent free of side effects

The speaker also recommends agents with no side effects. A side effect is an external change caused by an operation, such as mutating a database. The proposed design avoids changing the database immediately while the agent's result is still waiting for ontology-based checking.

The reason is straightforward:

1. The agent proposes an action.
2. Pydantic checks the action's input parameters.
3. The tool produces a result.
4. The ontology checks whether that result fits the domain model.
5. Only then does the surrounding system decide whether the result may be propagated or committed.

If the agent changes the database before step 4, a later semantic failure may arrive after the damage has already been done. A side-effect-free design keeps the proposal or result inspectable until the domain check is complete.

Teaching context: “No side effects” does not mean that the agent can never cause a change. It means that the design places the change after the validation boundary, so the system has an opportunity to reject or revise the proposal first.

The two validators answer different questions

Stage	Main question	Typical failure it targets
Pydantic at the input	Are these tool arguments shaped and typed as expected?	A parameter has the wrong kind of value
Ontology at the result	Does the returned information fit the domain's meanings and rules?	A result conflicts with a relationship, type, or constraint

These checks should not be treated as interchangeable. Pydantic can help prevent a malformed call. It does not, by itself, establish that a successful tool result is semantically correct. The ontology supplies the domain-aware guardrail that the previous chapter placed around the tool-result loop.

Takeaway

The speaker's recommendation is a staged safety boundary for an agent:

• At the door: use Pydantic to check the parameters entering the tool.
• At the ledger: use the ontology to check what the tool result means in the domain.
• Before committing: keep the agent free of side effects so an invalid result does not immediately change the database.

The model remains flexible and probabilistic, but its proposed inputs and resulting information pass through different kinds of checks. This is how the talk's ontology becomes an operational guardrail rather than only a description of the domain.