The proposal: reason over the ontology, then let the agent act

The talk closes with a simple division of labor:

• The LLM agent proposes language, decisions, or tool parameters.
• A tool provides information or performs an operation.
• An ontology reasoner checks whether the proposal or result fits the domain.
• The surrounding program accepts the result, sends feedback back to the model, or involves a human.

The goal is not to remove the agent's flexibility. The goal is to place a formal check around that flexibility before the system continues.

The core idea

An LLM generates likely text. In an agent loop, that text can describe a tool call or the next step in a plan. The model is useful because it can interpret a problem and propose a path forward. However, a likely proposal is not automatically a reasonable one.

The speaker's proposal is to reason over a formal ontology before allowing the system to proceed. The ontology represents the domain's important concepts, relationships, types, and constraints. A reasoner uses that model to ask questions such as:

• Does this result use the right kinds of entities?
• Does it obey the relationships defined for the domain?
• Does it violate a constraint?
• Is the proposed result consistent with what the system already knows?

This check supplies the agent with guardrails. It does not make the LLM non-probabilistic, and it does not guarantee that every error disappears. It gives the surrounding software a domain-aware basis for detecting an unreasonable proposal.

What the reasoner contributes

The supporting technologies named by the speaker are RDFS and OWL. In the lesson's earlier examples, they add formal meaning beside the graph rather than merely storing more text.

RDFS can support type inference. For example, if a teaches relationship has Teacher as its domain, a subject in a teaches statement can be inferred to be a teacher. If the range is Student, the object can be inferred to be a student. These inferred types give the system more information to use during checking.

OWL can express property behavior and constraints. A relationship can be transitive, or a property can be limited to one value. Classes can also be disjoint, and a property can be restricted to an allowed set of values. These rules let a reasoner detect relationships that do not fit the domain model.

The important distinction is between generation and reasoning:

Part of the system	Main job
Probabilistic agent	Generate a proposal or select a possible next action
Tool	Return information or carry out an operation
Ontology and reasoner	Check types, relationships, and domain constraints
Agent loop or human operator	Decide what to do when the check succeeds or fails

The ontology is therefore not a replacement for the agent. It is the formal reference frame against which the agent's behavior can be evaluated.

The guarded action loop

The proposal can be understood as this sequence:

problem or current state
        ↓
LLM proposes a response or tool parameters
        ↓
tool provides information or performs the requested operation
        ↓
result is placed in a validator-readable form
        ↓
RDFS/OWL reasoner checks the result against the ontology
        ├─ reasonable → accept it and continue
        └─ unreasonable → send feedback to the LLM or involve a human

The exact implementation can vary, but the causal order matters. The system does not treat the model's output as trusted merely because it is fluent. It checks the output against the domain model, then allows the next step when the result is acceptable.

A small teaching illustration

Consider an agent that proposes a change to information in a domain graph. The LLM may produce valid-looking parameters. The tool may also return text successfully. Neither fact proves that the returned result makes sense in the domain.

The validator can instead inspect the result using the ontology. If the result gives an entity a type that conflicts with the model, uses a forbidden relationship, or supplies a value outside an allowed set, the surrounding loop can stop that path. It can ask the LLM to try again with feedback, or ask a person to decide.

This is a teaching illustration of the architecture, not a quotation or a specific additional example from the video.

Guardrails, not a guarantee

Keeping the LLM on track is best understood as a control-loop goal. The reasoner does not prevent the model from generating a bad idea. Instead, it helps the program notice when the idea conflicts with known domain rules.

That difference is important:

• Without a formal check, a fluent response may move directly into the next agent step.
• With a formal check, the response has to pass through the ontology-based constraints before it is accepted.

The quality of the guardrail depends on the ontology and the rules it contains. A reasoner can check what the domain model expresses. It cannot check an unstated rule simply because the model's output sounds suspicious. The speaker's claim is therefore a proposal for more dependable agent systems, not a promise of perfect behavior.

Returning to “only making”

The speaker ends by returning to the opening learning idea: there is “no win or fail, only making.” In this context, making means building the agent-and-ontology system, observing what it does, and using unexpected results to improve understanding and design.

The message connects experimentation with the architecture itself. An agent can propose. A tool can expose what happens. An ontology reasoner can reveal whether the result fits the domain. A retry or human review can then become part of the learning process rather than treating every failed attempt as the end of the work.

The contact and website information at the end are closing information. They are not additional technical evidence for how the agent, ontology, or reasoner works.