DocsGPT already had individual agents. The next step was letting people connect them into a workflow they could build and run from the same product.
I worked on the visual builder and its Python execution engine while at Arc53. The initial version merged in February 2026. This note covers that contribution and a follow-up that added conditional routing.
From a canvas to a running workflow
My work covered the canvas, workflow APIs, data models, and execution engine. The first version supported agent, note, and state nodes, along with start and end points. The frontend stored the workflow as connected nodes; the engine used that definition to run the steps.
Each step could read or update shared state. As a run progressed, the engine streamed updates to the interface so the user could follow execution. The run log kept step status, timestamps, state snapshots, and errors.
Keeping the first version small
The initial scope excluded complex triggers and loops. Execution stopped when a node failed, and a fixed step limit bounded a run. Those limits were part of the first implementation, alongside the basic node types and progress events.
The useful unit was a complete path through the product: configure a workflow, run it, and see what happened at each step. That meant the canvas, API, engine, and run history all had to agree on the workflow’s state.
Adding branches
A separate follow-up contribution added conditional branches and CEL expressions for state updates and routing. That expanded what a workflow could do beyond a simple sequence of steps.
The initial builder and execution engine are in PR #2264. Conditional routing came later in PR #2280.
The surrounding work
Workflows were one part of my two years on DocsGPT. I also worked on model selection across providers, authenticated remote MCP tools, splitting up the user API, and automated tests for agents and tools.
The linked pull requests include the implementation and review. They’re the best place to dig into the details beyond this note.