LLM Flow Designer

Over the weekend, I dug into the current wave of LLM tools: FlowiseAI and Llama Flow, and the chatter on Reddit and the pattern is clear, they’re all high-level, abstract agent flows with little grip on precision.

FlowiseAI? It’s a visual playground for chaining LLM calls, but each node is a black box. You wire things together and hope the output fits. Want to switch models? You’re adding nodes, duplicating logic, or hacking around the UI. It’s low-code, sure but certainly not built for deterministic systems.

Some Llama Flow implementations (like the TypeScript-first llama-flow on GitHub) offer more control, but they’re dev-only, code-heavy, and lack real-time adaptability. Others, like llama_flow for RAG, simplify workflows but still treat the LLM as a dumb pipe.

LLM Flow Designer is different. While others give you abstraction, we give you control. We don’t just let you call an LLM—we let you define the exact output schema, validate it, and enforce deterministic behavior. No hallucinated JSON. No broken pipelines.

And yes, you can change the model ad-hoc right inside the node. No extra nodes, no workarounds. GPT-5.1 to Claude to a local Llama? One dropdown. Done. While Flowise and others force you to architect around model switching, we bake it into the core.

They’re building sandcastles. We’re building software.

We built this because the existing tools don’t ship to production. They demo well. We work well.

LLM Flow Designer: Precision over hype. Determinism over duct tape.

After years of internal developing a tool for repeated issues to solve and then finally deciding to acutally make it available to others was a first step. Now finding your first customer is a huge hurdle. Actually implementing the solution for them, especially when tackling a complex problem, is often an even bigger challenge. We've just crossed that bridge.

After intense collaboration with our first customer, we've successfully launched our first comprehensive automation flow for processing and labelling invoices before handing them over to the accounting system. This isn't a simple script; it's an in-depth system designed to solve a genuinely intricate data processing task.

Here's a detailed look at the workflow we've built:

The process starts with User Input, where we defined the input and fields to receive before handing it over to a complex LLM flow. From there, the system branches into several parallel validations and extractions:

• Contact Extraction: Pulls relevant contact information directly from the source data.

• Data Completeness Check: Uses predefined Data Completeness Guidelines to verify all required fields are present and valid.

• Cost Center Guidelines: A set of rules that feed into the data extraction and matching process.

The core processing begins with Extract Invoice Data, which takes the validated input and pulls out the necessary details. This data then flows into two critical matching systems:

1. Match Cost Centers: Applies the Cost Center Guidelines to accurately categorize expenses.

2. Iterate over Invoice Line Items: This is where the complexity deepens. For each individual line item on the invoice, the system performs a nested operation:

   • It references the Chart of Account Matching Guide.

   • Uses the Chart of Accounts to find the correct accounting classification.

   • Applies VAT Tax Authority Matching Guidelines to assign the proper code.

Finally, the results from the Data Completeness Check, Match Cost Centers, and the processed line items are all consolidated into a single, structured Output. It's a robust, multi-step flow that transforms raw, messy data into reliable, actionable information.

Building this together with our first customer has been an incredible learning experience, and seeing it live is a major milestone.

So I have building llm-flow-designer.com out of an own need. While building a product to do AppStore optimisation I was using a lot of complex, connected prompts to come up with a description and keywords matching current trends and the apps for which I was doing the optimization. I looked at many tools, frameworks and SDKs and while they were promising the world the reality underneath ended up in more work than before.

Instead of writing complex code following conditional execution graphs and loops I decided to make it visual. And not visual like dropping a few prompts and hope for the best but a more deterministic way of prompt and context engineering:

• have a node for each action to take: LLM prompt execution, data pulling, conditional paths and loops

• specify exactly the expected output (usually JSON) with fields and types

• build quorums on field output by running it multiple times in parallel

• implement conditions and loops to validate and run again

• change and use different LLM models on the fly (test the differences)

• have full traceability of time, token and cost usage

Then, next I started building a product for finance, extremely number centric (there is just true or false as valid answer) and it blew my mind.

This approach actually helped a lot here as well:
Changing prompts to cover more use cases, blow up execution graphs in code and any change in the chain could side effect heavily. The only way to master this was going visual with in-depth details available at your fingertips which made usually hours of debugging a 30 second problem!

Next is legal, data analytics and customer support for more concise and determined answered to difficult and complex questions fed by a gazillion systems but before jumping into that I ultimately decided to actually build my flow designer out as a whole own product on it's own and I’m looking for early access users harden what I have built for more use-cases: llm-flow-designer.com

So please drop a comment with your feedback and happy to reserve a front row seat!