入力にはPydantic、結果にはオントロジー

In the previous chapter, we saw a flow in which the result is checked against an ontology after a tool is called. In this chapter, the speaker separates validation into two places. Pydantic checks the arguments received at the entrance, and the ontology checks the result returned by the tool.

First, check the input types at the entrance

The speaker recommends looking at Pydantic when writing code that uses agents. Pydantic can specify parameter types and validate whether received values match those types. Here, a type means the kind of value something should be, such as a number or a string. If the type does not match, the program can reject the input or report the problem before running the tool.

Example (made concrete from the speaker's contrast): Suppose a tool receives a customer ID as a number. If the agent passes a string for that argument, input validation finds the mismatch. This can stop an incorrectly shaped call instead of sending it directly to external processing.

The speaker uses an example in which Python first puts a number in a variable and later puts a string in it to explain the difference from weaker type checking. It is safest to treat this contrast as the speaker's explanation. The talk's materials do not establish Python's exact type rules or Pydantic's detailed behavior.

Check the meaning of the result with an ontology

Pydantic mainly checks the shape and types of input parameters. An ontology, by contrast, checks whether a result fits the meaning of the domain. It uses entities, relationships, properties, and constraints on those relationships. Therefore, even data that is grammatically valid may be rejected if the relationship is impossible in the domain.

The division between the “door” and the “ledger”

The speaker expresses this division with the metaphor “Pydantic at the door, ontology at the ledger.” The door is the input passed from the agent to the tool. Its type is checked there. The ledger is the information or state left after the tool runs. There, the system checks whether the result fits the domain's rules and relationships.

This idea connects to the agent loop from the previous chapter in the following order.

1. The agent proposes the tool arguments.
2. Pydantic validates the arguments' types and shape at the entrance.
3. If there is no problem, the program runs the tool.
4. The tool result is put into a form that the ontology can validate.
5. The ontology checks the result's meaning, relationships, and constraints.
6. The system accepts the result, sends it back to the LLM for another attempt, or asks a human to review it.

Figure: A three-column slide summarizing two validation gates and a side-effect-free agent design.

This visual summarizes the speaker's design in one place. Pydantic operates at the input gate before the tool runs. At the output gate, before the returned result is passed on, the ontology checks it against domain rules. The agent has no intermediate side effects, so the database is not changed before the result is checked.

The following link points to the point in the talk where this slide is shown.

Do not commit a change until the result has been checked

The speaker also recommends agents without side effects. A side effect is when a proposed operation immediately changes a database or something similar. If the change is committed before the agent's result is checked by the ontology, an incorrect result may remain in the system unchanged. It is easier to intervene if the system checks the proposal and result first and executes the change only after deciding that there is no problem.

Example (a flow made concrete by the teacher): Even if an agent proposes a database update, the system does not perform the real update at first. It checks the input type with Pydantic and the result returned by the tool with the ontology. If the result is unreasonable, it sends the problem back to the LLM for another attempt or passes it to a human. The system commits the change only when the result is accepted.

These two validations cannot replace each other. Pydantic is an entrance check of whether the value has the right shape. The ontology is a result check of whether the value or relationship fits the domain's meaning. A value can have the right type and still be wrong in meaning, such as sending a payment to the wrong party. Conversely, a meaningful proposal cannot safely call the tool if its argument type is broken.

Summary

The proposal in this chapter is to place different protections around the input and the result. Pydantic checks the arguments that the agent passes to the tool at the entrance. The ontology checks the tool's result against the domain's relationships and constraints. In addition, an agent without side effects prevents a database change before validation is complete. This is not a way to assume that an LLM's proposal is correct from the beginning. It is a way to add two checks—type and meaning—to a loop that proposes, checks, and sends the proposal back when necessary.