How it works
A language model understands people. A small logic program decides what is true. Code in between makes sure the two never get confused.
Who decides what
| Who | What it does | What it never does |
|---|---|---|
| The client (a person or another agent) | Describes its situation in its own words, confirms or corrects what the agent understood, asks questions. | Nothing it says is executed: it is treated as data, never as an order. |
| The language model | Translates the client's words into a draft in a fixed form; phrases the final answer. | Does not write Prolog or queries, and does not decide what is valid or true. |
| The validator (ordinary code) | Checks the draft against closed lists of names, types and conditions, and against size limits. Rejects with a reason. | Checks the form, not the meaning (see the limits on the Evidence page). |
| The Prolog core | Decides what is true and why, from rules and facts. Its conclusion is the answer. | Does not read free text. |
| The agent's confirmation | Repeats in words what it understood, generated from the already validated model, not from what the language model says it understood. What the client confirms is what gets loaded. | Loads nothing before the client says yes. |
A real conversation
The first system built this way is an electrical-circuit agent: a client describes lights, switches and fuses, and the agent says what is lit, why, and why not. The client in these tests was itself a language model. Below is an excerpt (turns 6 and 8 of 8) of the real garage conversation, run on 3 November 2026. The original was in Spanish; it is translated here as faithfully as possible. Identifiers such as luz_em (emergency light) are the system's own and are not translated. The first part of the conversation, in which the client describes the whole garage and confirms it, is left out.
Client (a language model)
Ok, that fits. Now: why is luz_em not lit after event 5, when f_em blows?
Logitration agent
luz_em is not lit after event 5 (f_em blows) because no current reaches it, and that is because neither of its two supply paths is operative. Fixing either one is enough (or):
- Battery path (
luz_em←cable_em←bateria_em):f_emwould have to be in good condition, but it has been blown since event 5. - Garage mains path (
luz_em←cable_em←cable_gar←red_garaje):i_testwould have to be up, but it has been down since the assembly.
That is: the blown fuse cuts the battery path, and i_test being down cuts the garage mains path.
Client
Ok, that fits. Now I want to extend the circuit with a new event, number 7: after everything above, I lower i_test. With that, why is luz_em not lit at the end?
Logitration agent
Noted in "garaje": event 7: i_test is lowered.
ATTENTION (version 2): the last moment changes. It used to be after event 6 (moment 32); now it is after event 7 (moment 33). [...]
After the new end: no light is lit.
Real, not staged: the agent's answers were checked afterwards against an independent simulator written in plain Python, and matched. This is one conversation of three; see Evidence for what that does and does not show.