Mykhailo Pronko is a Software Engineer at IXO building the IXO Editor’s block based workflow system
The problem with standard documents is that they are static. They are good for recording information, but they are disconnected from execution.
With the Qi Flow Editor, we are building a block-based workflow system where documents become reactive applications.
The core unit is the Block. Instead of just rendering text, each block is an interactive component that can hold state, manage authorisations, fetch data, and trigger logic.
The Architecture: Two Modes
To make this work, the system operates in two distinct modes.
1. Template Mode (Configuration) This is where we define the block's behaviours. We configure the data sources, set the validation rules, and assign permissions for human and AI agents to act on the block.
2. Flow Mode (Runtime) The rendered document provides the human interface, and an underlying CRDT document API provides the AI agent interface. Users interact with the instance of the block, inputting data or triggering actions based on the configuration defined in the block template.
Watch: Configuring a "Flow Link" block in Template Mode. Notice the right-hand sidebar where we define the Title, add Links, and set specific Conditions (logic) that determine when this block appears.
How Reactivity Works
The key technical differentiator—which you can see in the "Conditions" tab in the video above—is that blocks can reference each other.
In a standard editor, elements are isolated. In Qi Flows, blocks exist in a dependency graph, where each block is a node and the edges between these nodes are conditional. A lot can happen in the messiness of the real-world "on the edge" that produces the conditions for a subsequent block to become active. This is very different to the brittle determinism of DAG graph-based orchestration systems such as n8n and LangGraph.
- State Dependencies: A block can listen to the state of another block. For example, checking a box in
Block_Acan change the visibility state ofBlock_B. - Data Flows: Completing form inputs in
Block Ccan trigger an API call that populates a list inBlock D. - State Updates: Approving a Claim and releasing an escrow payment in
Block Ecan allow and agent to issue a credential inBlock F
This allows us to build conditional workflows where the state of the document adapts based on user input, and the verified state of external systems such as the blockchain.
Baked-In Authorisation
We extended authorisation from the application layer down to the document layer.
Because these flows are used for governance and verification, we need granular control. Every block has internal logic for:
- Access: Who is authorised to view or write to this component
- Action: Who is authorised to interact with or mutate the state of this component (as well as how, by when, by how much)
This creates a built-in audit trail within the document artefact.
Current Capabilities
The component library is extensive. Among the many blocks available today, the core set handles:
- External Data: Fetching live data from APIs.
- User Input: Forms, checkboxes, and file uploads.
- Claims: Submitting and evaluating verifiable claims.
- Governance: Creating proposals and executing votes.
- Logic: Conditional display and enabling/disabling based on other blocks.
- Navigation: Linking between flow documents for multi-step processes.
- Triggers: Updating the state of other systems.
- Governed Skills: Executing agent skills with reasoning, and automations.
- And more...
Request for Feedback
We are continuously adding new block types to the editor library.
If you are designing workflows that require specific validation or automation steps, we want to know: What block type would remove the most friction for your team?
