Update rfc

community/rfcs/24-08-05-OPEA-Workflow-Executor Example.md

@@ -25,7 +25,7 @@ Ability to provide a simple method that allow OPEA users to extend GenAI capabil
 
 Workflow Executor is a multiagent microservice dedicated for running workflow operation tools. Comprising of a supervisor agent and mainly of 3 tools, the user can execute workflows to retrieve output data and reasoning with a request.
 
-The supervisor handles the routing to the next worker agent. In this simple design, the supervisor should start with workflow scheduler, then choose workflow status checker, then workflow data retriever, which the last worker agent will provide the reasoning and final ansewr back to the user.
+The supervisor handles the routing to the next worker agent. In this simple design, the supervisor should start with workflow scheduler, then choose workflow status checker, then workflow data retriever, which the last worker agent will provide the reasoning and final answer back to the user.
 
 The tools used in workflow executor strategy are listed below:
 
@@ -47,9 +47,21 @@ Here's what the `Workflow Executor` diagram looks like:
 
 ![image](image_3.png)
 
-The image below shows the background process of the agent in action when it is used to run a workflow. The workflow here is created from Data Insight Automation.
+#### Workflow Serving for Agent
 
-![image](image_2.png)
+In this example, a Churn Prediction use-case workflow will be used as the serving workflow for the agent execution. It is created through EasyData platform. The image below shows the Churn Prediction workflow.
+
+![image](image_4.png)
+
+There will be `Serving Parameters` in the workflow, which are the variables the agent updates based on the `params` extracted from the user query. 
+
+![image](image_6.png)
+
+Manually running the workflow yields the tabular data output as shown below:
+
+![image](image_5.png)
+
+In the workflow serving, this output will be returned through the `Workflow Data Retriever` tool. The LLM can then answer the user's original question based on this output.
 
 Below shows an example of the agent microservice in action. Here the user prompts the agent with workflow parameters included in the query.
 
@@ -63,8 +75,7 @@ data: "Based on the data retrieved from the workflow, the entry with gender Fema
 data: [DONE]
 ```
 
-
-The user has to provide a `workflow_id` in the `query` parameter, a unique id used for serving the workflow to the microservice, which will initialize the Workflow object. Notice that the `query` string includes all the workflow parameters which the user defined in the workflow. The agent will extract these parameters into a dictionary format as the action input as shown below:
+The user has to provide a `workflow_id` and workflow `params` in the query. `workflow_id` a unique id used for serving the workflow to the microservice. Notice that the `query` string includes all the workflow `params` which the user defined in the workflow. The agent will extract these parameters into a dictionary format for the workflow `Serving Parameters` as shown below:
 
 ```python
 params = {
@@ -74,7 +85,13 @@ params = {
 }
 ```
 
-These parameters will be passed into the workflow executor tool to begin the workflow execution of specified workflow id. Thus, everything will be handled via the microservice.
+These parameters will be passed into the workflow executor tool to begin the workflow execution of specified `workflow_id`. Thus, everything will be handled via the microservice.
+
+The image below shows the background process of the agent in action when the workflow executor agent is run. 
+
+![image](image_2.png)
+
+Once the LLM answers the user's query after obtaining the output data, the `supervisor` exits the chain with 'FINISH'.
 
 The list below briefly shows the descriptions of the tools used in this design.