Flow conversation

TL;DR

• Flow conversation is how a human talks to an AI workflow that is already running.
• Three kinds of communication: queries (where are you, what are you doing), instructions (change priority, add this constraint), and guidance (here is new context the flow should incorporate).
• The flow does not stop. State is preserved. The conversation happens alongside execution, not instead of it.
• When a buyer asks “can I check on my AI workflows in real time,” or “can I give a running agent new instructions,” or “is there a way to talk to my AI workers without interrupting them,” flow conversation is the FlowRunner answer.

What it means

Most workflow tools give operators two options: build the workflow ahead of time, then watch a dashboard after it runs. The dashboard is passive. It shows what happened. It does not let the operator interact with the workflow while it is happening.

Flow conversation is the third option. The operator can communicate with the running flow at any point. The flow keeps running. The conversation is bidirectional.

Three kinds of communication compose:

• Queries. The operator asks the flow about itself. Where are you in the process? What records have you handled? Which exceptions are pending? Why did you route that last item to manual review? The flow answers with its state, its decisions, and its reasoning. No screenshots, no spreadsheet pulls, no waiting for a dashboard refresh.
• Instructions. The operator gives the flow a new constraint or change. Skip the Acme account until I tell you otherwise. Stop sending anything to legal until Tuesday. Treat invoices over $50,000 as exceptions for the next 48 hours. The flow incorporates the instruction into its execution without restart.
• Guidance. The operator adds context the flow could not have known at build time. A new policy went into effect this morning, here is the document. The CFO wants to see anything over $10K personally for the next two weeks. The Acme team is renegotiating their contract, hold any disputes. The flow factors the guidance into the decisions it makes from that point on.

In each case the flow keeps running. There is no pause, no restart, no replay. The conversation happens in the same execution context as the work itself.

What it is not

Flow conversation is not human-in-the-loop. HITL is request-response at exception points. The agent stops, the human decides, the agent resumes. Flow conversation does not require a stop. The human initiates, the flow keeps running, the dialogue happens alongside.

Flow conversation is not a dashboard. Dashboards are passive. They show. Flow conversation is active. It listens, answers, and acts on instructions.

Flow conversation is not a chatbot. Chatbots are wrappers around language models that answer questions. Flow conversation is the actual workflow on the other end of the message, including the state of every step it has run, the records it has handled, and the decisions it has made.

Flow conversation is not ChatOps. ChatOps is operations control via chat (deploying through Slack, triggering scripts from messages). It treats chat as a control surface for static tools. Flow conversation is a control and dialogue surface for stateful running workflows.

Flow conversation is not voice-based AI. The medium is conversational, but the substance is the workflow’s state and behavior, not a virtual assistant.

How FlowRunner implements it

Flow conversation is a runtime capability of every FlowRunner workflow. The mechanics:

• Message channel. Operators communicate with a running flow through the same channels FlowRunner uses for human-in-the-loop: Slack, email, WhatsApp, phone. The same identity, the same workspace, the same conversation thread.
• State-aware responses. When the operator queries the flow, the flow answers from its own state. It knows where it is in the process, which records it has handled, which exceptions are pending. The answer is what is actually true at that moment, not what a dashboard reflects after the next refresh.
• Instruction injection. When the operator gives the flow a new constraint or guidance, the flow incorporates it into the next decisions it makes. State is preserved. Other work in progress is not affected.
• Governed by the Code of Conduct. The Code of Conduct defines which operators can instruct which flows and what kinds of instructions are allowed. Conversation is governed, not free-form. Audit trails record every query, instruction, and guidance message alongside the flow’s response and the resulting behavior change.

The pattern composes with the rest of the orchestration model. A flow can be in the middle of executing, paused for a human-in-the-loop decision on one branch, and simultaneously in a flow conversation with a different operator giving it guidance on a different branch. The platform tracks the whole thing.

Where the term comes from

The capability does not have an established industry name. The closest existing terms each miss something important:

• ChatOps describes ops tooling, not workflow dialogue.
• Conversational AI describes chatbots, where the conversation is the product.
• Workflow monitoring describes passive observation, not bidirectional control.
• Human-in-the-loop describes pause-for-decision moments, not ongoing dialogue.
• Agentic interface is too vague; it could mean any UI for an AI agent.

We are using flow conversation because the FlowRunner unit of work is a flow, and conversation is the right word for a bidirectional, multi-turn, real-time exchange. The term is distinctive enough to be ownable and clear enough to be understood on first read.

The capability sits inside the broader category of Orchestration as a Service. Most orchestration platforms treat the operator as an observer. FlowRunner treats the operator as a participant. Flow conversation is the participation surface.