feat: Async execution API workflow #2
Labels
enhancement
New feature or request
Comments
This was referenced Dec 7, 2024
Closed
grabbou
added a commit
that referenced
this issue
Dec 9, 2024
…rs are provided (#49) This implements #2 and #9 (please confirm) Updated server to use latest API Workflow now runs on the server in the background until it requests a tool or finishes Removed saving/loading from file as we want to keep state in memory and run its updates in background. Previous example required calling "iterate" endpoint each time to advance it. We can always add it back, but I think this one is much better Will automatically resume when all answers are provided Logger UI  Once this gets accepted, I will go ahead and create reusable functions to reduce this boilerplate and hide abstraction. --------- Co-authored-by: Piotr Karwatka <[email protected]>
|
Closed with #49 |
|
|
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Somewhat related to #1 - we need persistence layer to implement async execution.
Right now the only way to exec the flows is the CLI - which is great. But with a long-running, async flows - like waiting for an email etc. an event based architecture would be way better.
I think it would be ideal if we can define the simple API per Team (maybe let's give a way to define the endpoints while defining a Team @grabbou ?) - the default endpoints that came to my mind are:
team/kickoff- to start a new task for the team - returns the uniqueworkflowId(used within the persistence layer to store the context)team/[workflowId]/step- execute a next stepteam/[workflowId]/status- get the statusteam/[workflowId]/callstack- get the debug information (JSON logs - what steps were executed by which agents)The text was updated successfully, but these errors were encountered: