A visual builder for AI workflows that pause for human approval and pick up again from saved state.
A human in the loop AI workflow pauses to let a person decide. In this case study, an automated run reaches an approval step and stops, waiting there until someone decides what happens next. We built that pause inside the visual editor that already holds its model calls, document search and business tools.
A finished flow can go live as an application or an API. The reviewer is free to close the browser and return to the pending decision later.
The challenge
The connection often closes well before the approval arrives. Waiting for a person is hard to manage inside a single web request, where the socket will not stay open that long. Saving the model's last answer would not be enough either. The run also needs its variables, its current step and a record of what it has already sent back.
What we built
Teams join steps on a canvas, inspect variables and test a single step before it goes live. A schedule, a webhook or a plugin event can start the work. When a run reaches an approval, a form collects the response needed to continue.
The server first checks that the form is still open and that the chosen action is valid. Expired or already handled requests are rejected. A request that passes is queued as a saved run, ready for a worker to take up again.
Document workflows take their own route. They pull the text from a file, then split it into smaller sections that a search can reach. Keyword and semantic retrieval pick the passages that support an answer. Administrators keep control through roles, usage limits and run logs.
Technical approach
Celery workers run each workflow on their own, apart from the request that started it. The API first subscribes to the run's Redis event channel. It then queues the job, with a listener already in place for the progress that begins to arrive.
At a pause, the platform saves the run's state and notes which response events it has already delivered. Resumption brings the saved state and that record back together. Only one pause record is allowed for each run, held in place by a database rule.
Event transport runs in one of two modes. It can use live pub/sub, or it can read back from stored Redis Streams. A late subscriber cannot rebuild every earlier event from a live-only channel, so the deployment choice has to plan for that gap.
Document processing stays on a separate path of its own. It keeps its own extraction and indexing stages, its own retry points and a concurrency limit for each tenant. Model-provider plugins run inside a separate authenticated service, and code execution goes out to a remote sandbox.
Project success
The workflow can now wait on a review without holding any request open and without throwing finished work away. Run logs show each step that ran. A valid approval returns the run straight to its saved context, and document jobs keep their own recovery points for later retries. One interruption no longer has to turn into a brand new workflow.
Technology stack
Interface
Next.js, React, React Flow
Backend
Python, Flask, SQLAlchemy
Background execution
Celery, Redis
Storage
PostgreSQL or MySQL, vector-store adapters
Extensions
Separate plugin service, remote execution sandbox
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
