[x] Make Agent be Observable. Plan execution can be a long process. Right now, the process either fails or succeeds and there is no visibility of the changes happening with the system state. Making the Agent be an observable would allow other threads in the code to follow changes and operate on the updated state (for instance for reporting to an API) as the Agent is running.
[x] Allow Action tasks to return an Observable as well as a state. Similarly to the case above, the action in an ActionTask may take a long time to complete. Allowing the action to return an observable would allow the agent (and Agent subscribers) to receive updates of the progress of the action (e.g. for a long download).
[x] Implement "parallel" methods. Plans returned by the planner right now are linear. This means that plan execution may take a long time running tasks in sequence. This is a big change (I'm still not sure how to implement it) that would introduce "parallel" methods. A parallel methods returns a list of actions or methods that should be executed in parallel. This means the planner output would go from a list to a DAG. One of the main difficulties with this is to ensure that no conflicts can happen when executing parallel branches in the graph (e.g. what if two branches modify the same state?) to avoid non-determinism. The main idea on how to solve this right now is to implement a development mode in the planner that would perform the following.
Give a copy of the state to each of the branches to be executed in parallel
After converging, if any two branches made changes to the same piece of state (with respect to the state at the branching point), then interrupt the plan
To compare, we would probably use an implementation of RFC6902 (probably this one) and see if the changes in any two branches intersect.
Wishlist / Stretch goals
[ ] Improve algorithm to ensure the shortest path is found. Currently if multiple paths can lead to the same target, the planner will chose the first path it finds given the order of tasks provided when creating the Planner object. This is not ideal and it would be better if we could ensure that the planner is returning the shortest path. This is a desired improvement although workarounds can be found by tightening conditions or using methods.
[ ] Add action runtime metadata to the task functions. This would add a third argument meta to the tasks methods. This argument contains metadata about previous runs of the task by the agent. This would allow the knowledge base to chose a different path if a given task has been failing too much or if a known error with unclear source happens, so the planner can return a workaround.
[ ] Tasks transformations. Task state manipulation can get pretty complicated if the state object is too large. Having some type of domain transformation would help this
[x] Improve logging. Use structured logging with a pre-defined schema to communicate the progress in the agent/planner execution. Ideally logging from trace could be used to visualize the decision process when planning.
Roadmap to minimal usable version
Agent
be Observable. Plan execution can be a long process. Right now, the process either fails or succeeds and there is no visibility of the changes happening with the system state. Making the Agent be an observable would allow other threads in the code to follow changes and operate on the updated state (for instance for reporting to an API) as the Agent is running.action
in anActionTask
may take a long time to complete. Allowing the action to return an observable would allow the agent (and Agent subscribers) to receive updates of the progress of the action (e.g. for a long download)."parallel"
methods. Plans returned by the planner right now are linear. This means that plan execution may take a long time running tasks in sequence. This is a big change (I'm still not sure how to implement it) that would introduce "parallel" methods. A parallel methods returns a list of actions or methods that should be executed in parallel. This means the planner output would go from a list to a DAG. One of the main difficulties with this is to ensure that no conflicts can happen when executing parallel branches in the graph (e.g. what if two branches modify the same state?) to avoid non-determinism. The main idea on how to solve this right now is to implement adevelopment
mode in the planner that would perform the following.Wishlist / Stretch goals
meta
to the tasks methods. This argument contains metadata about previous runs of the task by the agent. This would allow the knowledge base to chose a different path if a given task has been failing too much or if a known error with unclear source happens, so the planner can return a workaround.