> I suspect that the next big AI breakthrough will result at least in part from constraining LLM decisions with old AI approaches. Frank Coyle presented the idea of ontologies constraining LLM output about a month ago: https://www.youtube.com/watch?v=Sir59K8ZDPU
Interesting, thanks for sharing!
I plan to give it my own shot with vibing my own harness; I plan to use https://glean.software/ as the central database for everything code, then for documentation. After that, it could be used for bookkeeping for reasoning in a style similar to what you describe; after all, Angle, the query language of Glean, is a https://en.wikipedia.org/wiki/Datalog with some extras (I don't know which yet), so stuff like onthologies could be queried quite well, I would guess.
If you mean letting an LLM generate code for a Prolog planner from an English problem description, that has been done successfully already with last year's models eg [1].
[1]: https://quantumprolog.sgml.net
Appreciate the link! That is not what I had in mind though; for them, the Prolog Code is the goal, for me, Prolog is an interface language within a system I build. That code could be generated on the fly, but I lean more towards fixed templates that can be instantiated by input some variables by the LLM that is doing agentic code, rather than having that LLM reproducing that query code completely on the flow.
The reasoning behind it is that I want to put as much logic as possible into the harness where it is deterministic, controled and fast - My goal is to make agentic coding usable for my purposes even with small local LLM models. Those might botcher generating Prolog queries sometimes, but they might might be able to used my API/interface/whatever reliably (and then the harness does everything else under the hood, including instantiating the Prolog templates and running the queries)