FlowBot: Multi-Domain Flow Systems

• FlowBot is a versatile term for a family of systems where 'flow'—whether of sensory data, motion, fluids, network traffic, or information—forms the central organizing principle.
• Each instantiation leverages a domain-specific methodology, from continuous perception–action loops in social robotics and dense per-point mapping in articulated manipulation to fluidic control and ML-driven botnet detection.
• FlowBot systems demonstrate practical performance in real-world evaluations with key metrics such as low normalized distance in manipulation, high botnet detection accuracy, and cost-effective optimization in LLM workflow induction.

Searching arXiv for the cited FlowBot-related papers to ground the article and verify metadata. FlowBot is a name used in multiple arXiv papers for technically distinct systems centered on the notion of “flow,” including continuous perception–action loops in social robotics, dense motion representations for articulated-object manipulation, recirculating-fluid control in soft robots, network-flow botnet detection, and bilevel induction of LLM workflows (Dhaussy et al., 2024, Zhang et al., 2023, Gepner et al., 2023, Issac et al., 2024, Yu et al., 29 Apr 2026). The term therefore does not denote a single standardized architecture. Instead, it identifies a family of domain-specific frameworks in which flow is treated as a core organizing abstraction: perceptual flow, articulation flow, fluid flow, network flow, or information flow.

1. Terminological scope and research uses

The main arXiv usages of the name can be summarized as follows.

Usage	Domain	Core idea
FlowAct / “FlowBot”	Human-robot interaction	Continuous multimodal perception-action loop
FlowBot++	Robotic manipulation	Dense per-point articulated motion and articulation projection
FlowBots	Soft robotics	Control embodied in recirculating fluid flow
FlowBot	Cybersecurity	Flow-based botnet detection with ML and GA tuning
FlowBot	LLM systems	Workflow induction via bilevel optimization and textual gradients

In the human-robot interaction usage, the query’s “FlowBot” corresponds to FlowAct, a proactive multimodal architecture for a social robot in a hospital-like waiting-room scenario (Dhaussy et al., 2024). In manipulation, FlowBot++ denotes a 3D vision system for zero-shot articulation of novel doors, drawers, and related objects from partial point clouds (Zhang et al., 2023). In soft robotics, “FlowBots” denotes monolithic fluidic robots whose control functionality is embedded in closed-loop flow recirculation rather than external valve-heavy routing (Gepner et al., 2023). In cybersecurity, FlowBot is a network-flow behavioral detector for botnet traffic, implemented as both an ML pipeline and a software product (Issac et al., 2024). In LLM systems, FlowBot is a framework for inducing the structure and prompts of multi-step LLM workflows through textual-gradient optimization (Yu et al., 29 Apr 2026).

A common misconception is that the name refers to one robotics platform. The literature instead uses it polysemously across several subfields. This suggests that “FlowBot” functions less as a canonical system name than as a reusable label for architectures that elevate some notion of flow to first-class status.

2. FlowBot as a continuous social-robot control architecture

In the social-robot usage, FlowBot refers to FlowAct, a proactive multimodal human-robot interaction architecture organized around an asynchronous, endless loop from robot sensors to actuators (Dhaussy et al., 2024). The architecture is structured by two controllers: Environment State Tracking (EST) and the Action Planner. EST continuously gathers raw sensor data and refined higher-level percepts, aligns them over time, links them to identities, and publishes an up-to-date representation of the environment. The Action Planner consumes that state and decides whether the robot should stay idle, return to a predefined observation position, engage a person, or maintain an ongoing interaction.

The perceptual stack is explicitly divided into raw perceptions and refined perceptions. Raw perceptions come from Pepper’s microphones, cameras, sonar, infrared sensors, lasers, IMU, odometry, and tactile/LED/tablet interfaces. Refinement modules produce higher-level signals including voice activity detection, person tracking, gaze tracking, speaker diarization, interaction acceptance belief estimation, speech recognition, and translation. In the reported implementation, person tracking combines YOLOv7 detections and body keypoints with DeepSORT; gaze tracking uses RT-GENE; speaker diarization uses an audio-visual fusion model; ASR and translation are performed through Google Speech-to-Text and DeepL when needed (Dhaussy et al., 2024).

A defining feature of EST is that it is not a single-frame detector but a persistent memory-like structure. It maintains identity over time through person re-identification and a perception assigner, and it supports associative memory such as linking a face to a known name or preserving user identity across asynchronous perceptual updates. The paper therefore distinguishes an environment state from a mere snapshot: the state stores identity, behavioral cues, and historical context.

The Action Planner is rule-based and state-based rather than a learned policy. It selects a global behavior, while action modules realize local behaviors. The implementation includes a Moving Module and a Speaking Module. The Moving Module either moves the robot toward a targeted person until it is within about 0.7 meters or returns it to its observation position; it tracks internal flags such as whether the robot is already at standby and whether it is currently navigating. The Speaking Module manages dialogue after engagement, uses a Vicuna-based conversational assistant, and terminates dialogue when certain keywords are detected or after user disengagement, including a 10-second timeout of no response. The planner uses the modules’ internal states, such as “is speaking” and “in a conversation,” to maintain behavioral consistency.

The evaluation was conducted on a SoftBank Pepper running NAOqi 2.5.5 with ROS integration in a simulated hospital waiting room. The study involved 20 participants, 14 men and 6 women, aged 22 to 52, with only three having prior robotics experience. Participants enacted behaviors such as talking with nearby people, using a mobile device, waiting passively, showing interest in the robot, or actively requesting help, information, or guidance. The main evaluation instrument was UMUX, with mean scores of 5.56, 3.25, 6.13, and 3.13 across the four questions. The system succeeded in engaging and interacting with all participants, and in two cases it initiated interaction before the user explicitly signaled readiness. The principal weakness reported by participants was response latency, typically 5–10 seconds, attributed to the computational cost of the LLM-based dialogue system (Dhaussy et al., 2024).

The significance of this usage lies less in any single perception algorithm than in the orchestration of perception, representation, memory, and modular action under continuous asynchronous operation. The limitations are equally clear: the control logic is largely rule-based, the evaluation is small-scale and scenario-specific, and the paper does not provide ablation studies or formal quantitative comparisons against alternative architectures.

3. FlowBot++ and dense articulated-object manipulation

In robotic manipulation, FlowBot most often refers to FlowBot++: a deep 3D vision system for generalized articulated-object manipulation from partial depth point clouds (Zhang et al., 2023). The target setting is zero-shot articulation of novel objects such as doors, drawers, fridge panels, toilets, and microwaves. The robot observes a partial point cloud of an object in a closed state and must infer how to move a selected part toward its open state.

FlowBot++ addresses limitations of both modular kinematic pipelines and end-to-end manipulation policies. Modular methods are described as brittle because failure in segmentation, part connectivity, or joint estimation propagates downstream. End-to-end policies are described as less generalizable to unseen articulated objects. The system instead predicts two dense per-point quantities: Articulation Flow (AF) and Articulation Projection (AP). AF encodes local instantaneous motion direction, while AP encodes the per-point displacement to the articulation axis. The two are combined to estimate articulation parameters and then generate a smooth multi-step trajectory.

The key representations are defined pointwise. For Articulation Flow,

$$f_p = \begin{cases} \boldsymbol{\omega}, & \text{if prismatic} \ \frac{\boldsymbol{\omega} \times \vec{r}}{\|\boldsymbol{\omega} \times \vec{r}_{\max}\|}, & \text{if revolute} \end{cases}$$

and for Articulation Projection,

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$

For revolute joints, the paper combines these as

$$\hat{\boldsymbol{\omega}} = \frac{r_p \times f_p}{\|r_p \times f_p\|}, \qquad \hat{v} = p + r_p.$$

Because AP can be noisier than AF, a Gram-Schmidt correction is applied:

$\tilde{r}_p = r_p - \mathrm{proj}_{f_p} r_p.$

The network, FlowProjNet, is built on PointNet++ and regresses both AF and AP from a partial point cloud. In simulation, a binary segmentation mask is provided as an extra input channel. The articulation-type classifier is also PointNet++-based. Training uses supervised regression with

$$\mathcal{L}_{\text{MSE}} = \left\| (\mathbf{f}_t \oplus \mathbf{r}_t) - f_\theta(O_t) \right\|_2^2,$$

while the prismatic-versus-revolute classifier uses binary cross entropy. Optimization uses Adam with batch size 64 and learning rate $1e^{-4}$, trained on synthetic tuples from PartNet-Mobility (Zhang et al., 2023).

A practical distinction from the earlier articulation-flow-only formulation is execution strategy. FlowBot++ predicts flow and projection, generates a K-step trajectory, executes only the first $H$ steps, and replans at lower frequency using an MPC-style controller. The ablation over lookahead horizon reports that $H=1$ effectively reduces to the older stepwise replanning regime and that the best result in the reported setting is $H=7$. This produces smoother motion, fewer replans, better robustness to occlusion, and faster execution.

On PartNet-Mobility, the primary metric is Normalized Distance to the goal joint configuration after rollout, where lower is better. The reported averages are 0.17 for AF only, 0.11 for AP only, and 0.07 for the combined FlowBot++ model. The corresponding average success rates at threshold $\delta = 0.1$ are 0.81, 0.77, and 0.82. The paper also reports wall-clock time of about 17.1 s/object for the AF-only baseline and about 1.2 s/object for FlowBot++. Real-world transfer is demonstrated on a Sawyer robot with an Intel RealSense depth camera and hand-labeled segmentation masks, including prismatic and revolute objects such as a drawer, oven, fridge, toilet, trashcan, and microwave (Zhang et al., 2023).

The method’s main assumptions are explicit: the object is either prismatic or revolute, a segmentation mask for the relevant part is available in the evaluation pipeline, and correct articulation-type classification remains necessary. If both AF and AP are wrong, the downstream trajectory cannot correct the error.

4. FlowBots as recirculating-fluid soft robots

In soft robotics, “FlowBots” denotes a class of robots whose intelligence is embodied in the characteristics of continuous fluid flow in a closed-loop recirculation regime (Gepner et al., 2023). The central claim is that control functionality can be embedded directly into the structure of the robot by using internal channel geometry, viscous losses, and routing topology, rather than relying on one-to-one mappings from control inputs to actuator outputs.

The paper contrasts three operating regimes: steady-state flow/pressure systems, pulsatile or cyclic systems, and recirculating systems. FlowBots are defined by the third regime. Fluid flows from a pump or pressure source, through internal channels, and back to the reservoir. This makes the robot behave like a fluidic impedance network in which flow corresponds to current, pressure to voltage, and viscous loss to resistance. The structural analogy is central because the robot body itself performs part of the control logic.

Several design principles recur throughout the paper. First, viscous losses create useful pressure asymmetries across actuator chambers. Second, reversing the flow direction reverses actuator behavior. Third, the architecture can switch actuators between parallel and series connections within the same recirculating loop, reducing the number of independent control inputs. Fourth, these principles compose to more complex robots while preserving monolithic, no-moving-part internal control structures.

The three exemplars are a bidirectional actuator, a gripper, and a quadruped swimmer. In the bidirectional actuator, a tip constriction and chamber geometry create pressure differences that bend the actuator one way under one flow direction and the opposite way when the flow reverses. In the gripper, two bidirectional actuators can be routed in parallel or in series depending on whether a middle port is blocked. The paper states that two independently controllable actuators would normally require four controls, whereas the recirculating gripper reduces the “fan-in” from 4 to 3. The quadruped swimmer extends the same series/parallel logic to a more complex body while remaining a single printed component (Gepner et al., 2023).

The proposed workflow for designing these systems is: design the fluidic body and channel network, simulate flow with CFD and deformation with FEA, print the robot monolithically using FDM additive manufacturing, and interface it through manual tubing or a tactile soft controller. The printed examples require no supports or post-processing. The paper reports that the quadruped swimmer took under 7 hours to print on a \$200 Artillery Sidewinder X1 using Filaflex 70A filament. The bidirectional actuator was tested from 1.25 bar to 2.5 bar in increments of 0.25 bar with three repetitions per point, and the authors report up to 11% variance in deformation between directions in some samples, attributed to manufacturing micro-errors. The actuator also deforms consistently with both pneumatic and hydraulic working fluids (Gepner et al., 2023).

The paper explicitly notes a tradeoff: recirculation broadens the control design space but is less thermodynamically efficient than simpler pressure or pulsed systems. A plausible implication is that FlowBots are best understood not as universal replacements for conventional soft-fluidic actuation but as a distinct design regime in which embodied control, monolithic fabrication, and routing simplification are primary objectives.

5. FlowBot in network security and botnet detection

In cybersecurity, FlowBot denotes a flow-based botnet detection system built around supervised ML, feature selection, and bio-inspired hyperparameter optimization (Issac et al., 2024). Here “flow” refers to network flow behavior rather than robotics or physical motion. The goal is binary classification of network activity as Normal or Botnet without dependence on payload signatures, ports, protocols, or other communications architectures.

The system motivation is that signature-based IDS methods become brittle under encryption, fragmentation, port changes, and payload obfuscation. Flow records are presented as privacy-preserving, smaller than raw PCAPs, and faster to process. The classifier comparison includes Gaussian Naïve Bayes, Decision Tree, Random Forest, AdaBoost, Linear SVC, KNN, and ANNs with one and two hidden layers. In the default setting, Random Forest performed best overall, followed closely by Decision Tree. The major methodological contribution is Genetic Algorithm optimization of classifier hyperparameters, where each chromosome represents a candidate hyperparameter set and fitness is measured by cross-validated F1-score under stratified 10-fold cross-validation.

The detection workflow comprises data processing from PCAP or flow files, feature preprocessing, feature selection or reduction, classifier training and evaluation, GA-based hyperparameter optimization, model serialization, and deployment in a detection engine with a GUI. Implementation uses Python 3.7, scikit-learn, pandas, TensorFlow/Keras, Argus and the ra client for flow extraction, Electron for the GUI, and WebSockets for detector–GUI communication. The detector can ingest live traffic from a SPAN/mirrored port, PCAP files, or preprocessed flow files such as .binetflow and .csv (Issac et al., 2024).

Feature engineering uses the extended CTU-13 feature set, with dataset-specific selection of the top 15 features. The paper states that identifiers such as IP addresses, ports, timestamps, and protocol/metadata fields are removed so that detection does not depend on content or host identifiers. Evaluation metrics include accuracy,

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$0

precision,

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$1

recall,

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$2

and

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$3

The F1-score is explicitly used as the GA fitness function because accuracy alone is misleading under severe class imbalance.

The evaluation spans CTU-13, ISOT 2010, and ISCX Botnet 2014. The paper reports baseline average results of RF with F1 = 0.9742 and Accuracy = 0.9964, ahead of DT, KNN, and AdaBoost. After GA optimization, Random Forest + GA achieves an average accuracy of 99.85% and an average F1-score of 97.74% across the three datasets. The authors further report very low false positives against legitimate traffic and lower false positive rate than Snort in the compared scenarios (Issac et al., 2024).

This usage should be distinguished from earlier graph-based flow-driven bot detection systems. A prior two-phase approach transforms bidirectional network flows into a directed weighted communication graph and then combines SOM-based unsupervised pruning of presumable benign hosts with DT-based supervised classification of suspicious hosts. That system emphasizes robustness to zero-day attacks, cross-topology normalization, and scalability, while also noting that some graph features—especially betweenness centrality—are computationally expensive (Daya et al., 2019). The later FlowBot detector remains flow-centric but is framed as a complete behavioral-modeling and deployment pipeline rather than a communication-graph classifier.

6. FlowBot as bilevel induction of LLM workflows

In LLM systems, FlowBot is a framework for automatically inducing LLM workflows rather than merely optimizing prompts inside a fixed workflow graph (Yu et al., 29 Apr 2026). A workflow is defined as

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$4

with per-step prompts $$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$5, and maps an input $$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$6 to an output through

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$7

The framework treats workflow induction as a bilevel optimization problem: an outer loop changes the workflow sketch, while an inner loop optimizes each LLM call.

The optimization target is written as

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$8

The paper’s central mechanism is the textual gradient: a natural-language critique or prescription generated by an LLM, used as an analog of a numerical gradient. For the final layer,

$$r_p = \mathrm{proj}_{\vec{v}} p - p = (\boldsymbol{\omega}\boldsymbol{\omega}^T - \mathbf{I})(p - v).$$9

and for intermediate layers,

$$\hat{\boldsymbol{\omega}} = \frac{r_p \times f_p}{\|r_p \times f_p\|}, \qquad \hat{v} = p + r_p.$$0

Prompts are then updated via another LLM call,

$$\hat{\boldsymbol{\omega}} = \frac{r_p \times f_p}{\|r_p \times f_p\|}, \qquad \hat{v} = p + r_p.$$1

while the outer loop computes a workflow-level gradient

$$\hat{\boldsymbol{\omega}} = \frac{r_p \times f_p}{\|r_p \times f_p\|}, \qquad \hat{v} = p + r_p.$$2

and updates the sketch accordingly.

The framework is designed for multi-step workflows involving retrieval, entity disambiguation, extraction, verification, final answer generation, and tool use. A step may be a pure LLM executor or a tool-augmented executor. The initialization procedure starts by asking an existing LLM to solve examples without explicit instructions, obtaining an initial workflow sketch through a textual-gradient step, and then generating initial detailed prompts for each step. The reported training setup uses one epoch, batch size 5, and per batch two bilevel optimization loops, each consisting of one outer-loop step and five inner-loop steps (Yu et al., 29 Apr 2026).

The evaluation covers ten benchmarks: HotpotQA1, HotpotQA2, HoVer, IFBench, PUPA, DROP, GSM8K, MATH, HumanEval, and MBPP. Against prompt optimization in fixed workflows, FlowBot reports an average of 69.80, compared with 66.97 for GEPA, 68.69 for GEPA+Merge, 61.08 for TextGrad, 59.71 for MIPROv2, and 57.93 for Trace. In the controlled AFlow comparison, the reimplementation table reports HotpotQA2: 80.19 vs 75.41, DROP: 92.28 vs 79.69, GSM8K: 96.01 vs 86.16, MATH: 72.71 vs 72.01, HumanEval: 93.74 vs 94.65, and MBPP: 73.84 vs 74.78 for FlowBot versus AFlow. The cost table reports 54.7K total API calls and \$\hat{\boldsymbol{\omega}} = \frac{r_p \times f_p}{\|r_p \times f_p\|}, \qquad \hat{v} = p + r_p.$3130.95 for AFlow (Yu et al., 29 Apr 2026).

The ablations indicate that prompt optimization alone, removal of bilevel optimization, or removal of layer-wise backpropagation all degrade performance. The method’s limitations are also explicit: optimization-time cost is nontrivial, workflows can plateau early, experiments mainly focus on feedforward chains rather than arbitrary graphs, and the quality of textual gradients depends on the meta-LLM. This suggests that the framework is most useful when a task benefits from explicit modular decomposition and stepwise verification rather than a single direct prompt.

Across these usages, the most stable encyclopedic characterization of FlowBot is therefore not a single architecture but a recurring research label for systems that convert some structured notion of flow into decision-making capacity. In different subfields, that flow may be environmental state in HRI, per-point articulation geometry, recirculating fluid motion, network traffic behavior, or the sequence structure of LLM calls.