What is the point of Prolog Agent / Emacs Situated Agent?

It is a system where the FRDCSA (through Prolog/ELisp/Perl)
controls an Emacs session to achieve things.  For instance, it
can run shell commands inside Emacs, and soon will be able to
parse their results.  Well immediately one might ask why is this
necessary, we already have wrappers for shell commands (for
instance in Prolog there is directory_files/2, we already have
the Expect library, etc etc).  Well it is true that there are
already such things, which I do already use extensively in the
FRDCSA project, but the end result we are aiming for is not
*only* to have such abilities.  I said that we are trying to make
an intelligent agent out of Emacs.  This is because Emacs already
works quite like a blackboard, in which you can write to and from
it in several contexts.  Put in a silly way, we are trying to
make Emacs artificially intelligent.  So, there are a couple
reasons, I have already mentioned the blackboard capability, we
are also interested in having Emacs learn from the user, to
observe and understand what the user is doing, and to do
programming by demonstration style learning.  That is what was
originally the goal of the BrainLeach program, and accomplished
somewhat in the Manager project, with screen session recording.
The idea is, if Prolog-Agent/Emacs-Situated-Agent understands
enough of what we are doing, it will be able to emulate it.
Various learning technologies are employed.  For instance, I have
extended Emacs Command Log mode to display in an untouched buffer
the commands that the user is running.  This is very much like
OpenAI's Gym (and predates the announced release of it), but for
Emacs.  One might think of trying deep learning on this.  Another
thing to consider is that we want the agent to be able to more
easily parse existing data, to make sense of it.  If we are
relying on handcrafted library calls, there is less of an
opportunity to develop a fault-tolerant parser.  This relates
heavily to the IAEC system, and to a lesser extent the
API-Learner system.  These systems try to learn by memoizing
function invocations, and learning relationships between data
nodes with function invocations as edges.  Another purpose of
Emacs Situated Agent (ESA) is to accelerate the utility of Emacs,
by having the program extend the kinds of analyses you can do in
Emacs.  For instance, one can imagine richer access to NLP
analysis of text buffers etc, as we have done in the NLU and
Emacs-NLP projects.  We cannot train the system to make sense of
out arbitrary outputs if it doesn't have access to them.  We also
want the system to gain familiarity with working in multiple
contexts simultaneously, and to understand, via PDDL-ization,
what is going on.  There should be predicates relating to buffers
and their relationships and so on.  We wish to parse ELisp code
and do some rudimentary static and dynamic analysis on it.
Additionally we want to control other tools through things like
xdotool etc.  Our aim is to make an agent that can comport itself
in a variety of Linux settings.  Now, we don't expect to make
something which will be enterprise-ready, this is more of an
experiment.  We know that it won't be able to successfully parse
everything that comes out of STDOUT, but we are hoping to have it
learn increasinly how to do so.  If we don't attempt to do it
this way, it will never learn successfully how to deal with
unknown output.  As well as reading and sense making from man
pages, and other documentation.  The idea is similar to embodied
cognition, as an environment where the agent can roam around and
do things and learn the results.  For instance, we have set up a
VM in which the Emacs program which is controlled from a separate
machine runs, it can proceed to thrash the system, and to learn
what happens as a result.  Now to get it to behave rationally
from trial and error is probably too great a leap, so we
additionally write methods and procedures to give it a head
start.  Ideally we will eventually integrate program synthesis
techniques, so it can generate plans.  I forgot to mention the
planning component.  We are using PDDL planners to represent the
environment, we model the output of programs and the state of
Emacs as PDDL fluents and then write or derive action
definitions.  This way the system can plan, and act as a testbed
for metaplanning.  Basic things like adding goals to the planner
while planning are not supported in PDDL, without having multiple
invocations of the planner.  Or to do things like have a goal to
find a file, and then do something with that file.  These things
are hard if not impossible to express with PDDL.  So this is a
great opportunity for us to work out the kinks with planning with
imperfect information and test various planners.  We are
codifying things not only into PDDL but into CycL so the system
has a higher level understanding and can reason more completely
with the outputs.  This is expected to have benefits all around.
So that is a summary of the motivations and intentions for the
Prolog-Agent (PA) and Emacs Situated Agent (ESA) projects.