LangFlow for visual workflows

Kavita runs operations for all six Crumb stores. She has the 200-page store operations handbook more or less memorised, which is exactly the problem: every store manager messages her instead of opening it. “What’s the opening checklist on a public holiday?” “How long can cream cakes sit in the display?” “Who signs off a cash shortfall over ₹2,000?” She counted last month. Forty-three questions, nearly all of them answered somewhere in the handbook.

She had asked Arjun for a handbook bot three weeks ago. It was still on his list, under the WhatsApp line, the refund approvals and the Diwali rush.

So on Tuesday Arjun tried to be helpful. He sent Kavita his RAG script from Module 09, a README, and a cheerful note: “Should take ten minutes!” Forty minutes later she sent him a screenshot of a terminal. uv: command not found. After he talked her through installing it, the next screenshot was a red wall of text ending in KeyError: 'ANTHROPIC_API_KEY'. After that one, she stopped sending screenshots.

“It’s not that she can’t do it,” Priya said when Arjun told her. “She designs every store’s workflow. She thinks in steps and handoffs better than either of us. You handed her a programming problem when she has a design problem. Give her a canvas instead of a terminal.”

Bricks with labelled studs

Priya found a box of Lego in the office’s kids’ corner (Meera’s nephew visits on Saturdays) and tipped a few bricks onto the desk.

“Every brick has studs on top and holes underneath. You can’t connect them wrong: either they fit or they don’t. Now imagine each brick does one job. One brick takes a question. One brick holds a prompt with a blank in it. One brick is Claude. One brick shows the answer. You snap them together in order.”

“So it’s a graph,” said Arjun. “Nodes and edges.”

“It is a graph. The difference is who can build it. With Lego, Kavita does not need to know how plastic is moulded. She needs to know what she wants built.”

That is low-code: building software mostly by arranging and configuring ready-made pieces instead of writing code line by line. Langflow is an open-source low-code tool for LLM apps. Each brick is called a component. Each component has typed inputs on one side and typed outputs on the other, and you connect them by dragging a wire from an output to a compatible input. The whole drawing is called a flow.

Where the analogy breaks: Lego bricks never change. Langflow components are Python code underneath, written by other people, and they get renamed, split and updated between versions. And when you need a shape that no brick provides (a loop with a counter, a rule about rupee limits), Lego leaves you stuck, while code lets you write it. Keep that in mind; it decides when to stop using Langflow.

Getting Langflow running

There are two routes. Kavita used the first; you will probably use the second.

Langflow Desktop is an installable app for macOS and Windows. Download, double-click, done. No terminal. This is the route for non-engineers.

The Python package is for engineers who want it alongside their other tools. Langflow supports a range of recent Python versions (3.10 to 3.14 at the time of writing; check the docs before installing). In a fresh folder:

uv venv
uv pip install langflow
export LANGFLOW_SUPERUSER_PASSWORD="choose-a-long-password"
uv run langflow run

The install is large (it pulls in many integrations), so give it a few minutes. When it starts, open http://127.0.0.1:7860 in your browser.

In recent versions automatic login is turned off by default, so Langflow asks you to sign in. The default administrator username is langflow and the password is whatever you put in LANGFLOW_SUPERUSER_PASSWORD. Use a real password even on a laptop: anyone who can sign in can run code on the machine, as you will see.

Component names shift between versions. Throughout this lesson, if a name below does not match your sidebar, use the sidebar’s search box and pick the closest match.

Kavita’s first flow: a chatbot in four bricks

Kavita started with the simplest possible flow, to get a feel for it:

flowchart LR
    I["Chat Input"] --> P["Prompt"]
    P --> M["Anthropic (Claude)"]
    M --> O["Chat Output"]

• Chat Input receives the user’s message.
• Prompt is a template with blanks in curly braces. She wrote: “You are Crumb’s operations assistant. Answer store managers’ questions briefly. Question: {question}”. Typing {question} creates a new input socket on the component, and she wired Chat Input into it.
• Anthropic (or a generic Language Model component with Anthropic selected) calls Claude. She pasted the API key into the component’s key field, which Langflow can store as a global variable so it is not copied into every flow. She set the model to claude-opus-5-5.
• Chat Output displays the answer.

Then she opened the Playground, Langflow’s built-in chat window for testing the current flow, and asked: “How long can cream cakes sit in the display?”

Claude answered fluently: “Cream cakes are generally safe at room temperature for about two hours.” Which is general food-safety advice, and not Crumb’s rule. The model had never seen the handbook. This is the same lesson as Module 09: a model only knows what is in its training data and its context window (the text it can see right now). To answer from the handbook, the handbook’s relevant pages have to be in the prompt.

Adding the handbook: a retrieval flow

Kavita did not start from a blank canvas for this. Langflow ships starter templates, including a retrieval one (in recent versions it is called something like Vector Store RAG). She opened it, and Priya walked her through the two halves.

flowchart LR
    F["File (handbook PDF)"] --> S["Split Text"]
    S --> V1["Vector store (ingest)"]
    E["Embeddings"] --> V1
    Q["Chat Input"] --> V2["Vector store (search)"]
    E --> V2
    V2 --> P["Prompt"]
    Q --> P
    P --> M["Anthropic"]
    M --> O["Chat Output"]

The loading half runs once (and again whenever the handbook changes):

• File loads crumb-ops-handbook.pdf.
• Split Text cuts it into chunks (overlapping passages). Kavita used about 1,000 characters per chunk with 200 characters of overlap, so a rule that straddles a boundary still appears whole in at least one chunk. The 200 pages became about 450 chunks.
• Embeddings turns each chunk into an embedding, a list of numbers that captures what the text means, so that passages about similar things end up close together. Claude does not make embeddings, so this is a separate component: a hosted one like OpenAI’s, or a local one through Ollama if you would rather the handbook did not leave your machines.
• Vector store (Chroma, in the template) saves each chunk with its embedding. A vector database is a store built to find the nearest embeddings quickly.

The question half runs for every question:

• Chat Input receives the question.
• The vector store, in search mode, embeds the question and returns the four nearest chunks.
• A small parser component (it may be called Parser or Data to Message) turns those chunks into plain text.
• Prompt now has two blanks: {context} for the chunks and {question} for the question. Kavita’s template: “Answer using ONLY the handbook extracts below. Quote the section number. If the extracts do not answer the question, say ‘I can’t find this in the handbook’ and suggest asking Kavita.\n\nExtracts:\n{context}\n\nQuestion: {question}”.
• Anthropic and Chat Output, as before.

She clicked the run button on the loading half once and watched each component show a green tick.

Following one question through the flow

A store manager in Aundh asks: “Can we sell yesterday’s cream pastries at a discount?”

Chat Input emits that sentence as a message.

Vector store search embeds the question and compares it with 450 chunk embeddings. The top four:

1. §7.3 Display life. “Fresh-cream items must be sold within 24 hours of preparation. They must not be sold the following day at any price. Log unsold items on the waste sheet before closing.”
2. §7.5 Discounting. “Bread and dry cakes may be discounted by 30% after 6 pm. Discounts on other items need the area manager’s approval.”
3. §7.4 Waste sheet. “The waste sheet is sent to operations every night by 23:00…”
4. §3.2 Closing checklist. “Check display temperatures, clear the cream display…”

Notice that chunk 2 is a near miss. It is about discounts, and on its own it might suggest that a discount is possible with approval. This is why the prompt says “ONLY” and asks for section numbers: the model must reconcile the extracts, not pick one.

Parser joins the four chunks into about 900 tokens of plain text (a token is a chunk of text, about three quarters of an English word).

Prompt fills both blanks. The text sent to Claude is about 1,050 tokens.

Anthropic replies (about 90 tokens): “No. Section 7.3 says fresh-cream items must not be sold the day after preparation at any price, so they cannot be discounted. Log them on the waste sheet before closing (Section 7.4). The 30% evening discount in Section 7.5 applies only to bread and dry cakes.”

Chat Output shows it in the Playground.

Cost per question: roughly 1,050 input tokens and 90 output tokens. At $4and$20 per million, that is about $0.006, or half a rupee at ₹88 to the dollar, plus a fraction of a paisa for embedding the question. Forty-three questions a month costs less than a cup of chai. Prices change; check the provider’s pricing page.

Show the answer

The loading half was never re-run, or it was re-run on top of the old data. Uploading a new file to the File component does not change what is already in the vector store. Either the store still holds only the old chunks, or it now holds both versions and search returned the old one. The fix is to clear the collection (or use a fresh one) and re-run ingestion whenever the handbook changes, and to put a version or date in each chunk’s metadata so answers can cite it. This is a process problem, not a Langflow problem; the same thing happens in code.

Memory and agents

Two more kinds of component cover most of what people build.

Memory. Every Playground session, and every API call, can carry a session ID. Langflow stores the messages for each session, and a Message History component (the name varies) can pull the recent ones into a prompt blank like {history}. That is how the bot handles a follow-up like “and for dry cakes?”. It is the same idea as the thread ID from the last lesson, managed by Langflow instead of a checkpointer.

Agents with tools. The Agent component wraps a model in an agent loop, the same loop you wrote by hand in Module 13. You connect tool components to its tools input: a calculator, a web request, a search, or the vector store itself exposed as a tool. Kavita tried this to let the bot also check the store opening-hours spreadsheet. It worked, and it was also the first time she saw the bot do something odd (it searched the handbook three times for the same thing). An agent is more flexible and less predictable than the fixed retrieval flow; the trade-offs from Module 13 apply unchanged.

Calling a flow from outside: the API

A flow in the Playground is a demo. A flow behind an API is something other software can use. Every flow gets an endpoint. First, create an API key in Langflow’s settings (look for Langflow API Keys), and find the flow’s ID, which appears in its URL and in the API access panel (which also shows ready-made code snippets).

curl -X POST "http://127.0.0.1:7860/api/v1/run/$FLOW_ID" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $LANGFLOW_API_KEY" \
  -d '{"input_value": "Can we sell yesterday'\''s cream pastries at a discount?",
       "output_type": "chat",
       "input_type": "chat",
       "session_id": "aundh-store"}'

The same call from Python, with the key read from .env:

# ask_handbook.py
import os

import httpx
from dotenv import load_dotenv

load_dotenv()
url = f"http://127.0.0.1:7860/api/v1/run/{os.environ['FLOW_ID']}"
response = httpx.post(
    url,
    headers={"Content-Type": "application/json",
             "x-api-key": os.environ["LANGFLOW_API_KEY"]},
    json={"input_value": "Who signs off a cash shortfall over ₹2,000?",
          "output_type": "chat",
          "input_type": "chat",
          "session_id": "baner-store"},
    timeout=60,
)
data = response.json()
print(data["outputs"][0]["outputs"][0]["results"]["message"]["text"])

Section 9.2 says cash shortfalls over ₹2,000 must be reported to the area manager the same
day and signed off by both the store manager and the area manager.

The answer sits a few levels deep in the response JSON. If the path above fails in your version, print data once and find the text.

Two optional fields are worth knowing. session_id keeps each store’s conversation separate, as above. tweaks overrides a component’s settings for one call without editing the flow: a dictionary keyed by component ID, like {"tweaks": {"Prompt-abc12": {"template": "..."}}}. Component IDs are shown on the canvas.

Library APIs change quickly. If a name has moved, check the docs linked below.

Arjun wired this into a tiny script that the store tablets call. Kavita’s flow was in the hands of six store managers by Thursday.

Exporting, sharing and versioning flows

A flow can be exported as a single JSON file from the flow’s menu, and imported into another Langflow instance by uploading it. Kavita exported hers and sent it to Arjun, who imported it on Crumb’s shared server. Export with care: depending on your settings, stored API keys can travel inside the file, so check before you share and prefer global variables.

The JSON file can be committed to git, which is better than nothing. But open one and you will see why engineers grumble: thousands of lines that include every component’s code, settings and its x and y position on the canvas. Move one box two centimetres and the diff (the line-by-line comparison git shows) lights up. Reviewing a real logic change in that diff is painful.

When Langflow helps, and when it does not

Priya and Arjun argued about this over lunch, and settled on a list.

Langflow is a good fit for:

• Prototyping. Testing whether a handbook bot is useful takes an afternoon, not a sprint. If nobody uses it, you lost an afternoon.
• Demos. A canvas explains a pipeline to Meera faster than any code.
• Non-engineers owning their tools. Kavita can now change her own prompt when managers complain the answers are too long, without filing a ticket.
• Small internal tools with a handful of users and low stakes.

Move to code (LangGraph, or plain Python) when you need:

• Complex logic. Refund limits, approval pauses, loops with counters, branching on database results. Expressible on a canvas, perhaps, but hard to read and harder to change safely.
• Tests. You cannot easily write a unit test for one box on a canvas. Code gets tests, evaluations (Module 23) and continuous integration.
• Code review. A two-line logic change should be a two-line diff, not a wall of moved coordinates.
• Scale and reliability. Retries, rate limits, many concurrent users, checkpointing to your own database, deployment alongside your other services.

The healthiest pattern is a handoff: prototype in Langflow, prove the idea, then rebuild the proven flow in code, using the flow itself as the specification. The canvas already shows the steps, the prompts and the retrieval settings that worked.

Show the answer

(a) Stay in Langflow, for now: small audience, low stakes, and Kavita owns it. Revisit if it grows to every staff member or starts needing integrations. (b) Code. It moves money, needs exact rules, approval pauses that survive restarts, tests and review. That is exactly what you built with LangGraph and MongoDB. © Langflow. It is throwaway by design; the speed matters more than the polish. If the summaries turn out to be valuable every week, then hand it off to code.

Where it breaks

• Versions move under you. Components are renamed or replaced between releases, and an exported flow may not import cleanly into a newer version. Pin the version for anything people depend on, and upgrade deliberately.
• Debugging is shallower. You can inspect each component’s output on the canvas, which is good. But there is no step-through debugger, no time travel and no stack trace in your own code. When something subtle goes wrong, you end up reading the component’s source anyway.
• Hidden defaults. Chunk size, number of retrieved chunks and model settings live in component panels. Two flows that look identical can behave differently because of one field nobody opened.
• Ownership blurs. If Kavita’s bot gives a wrong answer about cash handling, who fixes it? Decide before it matters.

Try it yourself

Build Kavita’s retrieval flow on any document you have: a product manual, a long PDF from work, your college handbook. Then:

1. Ask a question whose answer is clearly in the document, and one whose answer is not.
2. Change the number of retrieved chunks from 4 to 1, and ask the first question again.
3. Call the flow from ask_handbook.py.

Show the expected result

The in-document question should get an answer that cites a section or quotes the text. The out-of-document question should get your “I can’t find this” line; if it answers anyway, tighten the prompt (“use ONLY the extracts”) and try again. With only one chunk, answers get thinner and sometimes wrong, especially when the rule is spread across two sections, which shows why retrieval settings matter. If the API call returns an authentication error, check the x-api-key header and that you created the key in Langflow’s settings, not your Anthropic key.

Common mistakes

• Sending non-engineers a terminal. Use Langflow Desktop, or host one shared Langflow server for them.
• Re-uploading a document without re-ingesting it. The vector store keeps what it had. Clear and re-run the loading half.
• Shipping API keys inside exported flows. Use global variables, and check the JSON before sharing.
• Growing a prototype into production by accident. When a flow starts handling money, personal data or many users, plan the handoff to code.
• Exposing Langflow to the internet. Editor access means code execution on that machine.

Recap

• Langflow is a visual, low-code builder: drag components onto a canvas and wire outputs to inputs to make a flow.
• Typical building blocks: Chat Input, Prompt, a model, Chat Output; File, Split Text, Embeddings and a vector store for retrieval; Message History for memory; Agent plus tools.
• The Playground tests a flow; the API (POST /api/v1/run/<flow_id> with an x-api-key header) lets other software call it.
• Flows export and import as JSON, which works but makes for noisy diffs.
• Use it to prototype, demo and empower non-engineers; hand off to code when you need complex logic, tests, review or scale.

On Friday, Kavita showed Meera the canvas. “Question comes in here. It looks up the four most relevant bits of the handbook here. Claude answers using only those bits, here, and has to quote the section.” She had not used one technical word, and she had not needed Arjun once since Tuesday.

Meera turned to Arjun. “So why don’t we build everything like this?”

“For things like this, we should,” said Arjun. “But the refund process has rules about money and pauses overnight for approval. That needs tests and code review, and it needs to survive a restart. Kavita’s canvas is perfect for trying ideas. Once an idea is proven and important, we rebuild it in code.” He paused. “Speaking of code, Priya wants me to build something that writes it.”

Priya, from across the room: “A coding agent. For our own repo. There’s a failing test in the pricing module that’s been ignored for two weeks.”

Go deeper

• Langflow documentation: installation, Desktop, components, the Playground and the API reference.
• LangGraph documentation: for when a prototype graduates to code.
• Building effective agents (Anthropic): on starting simple before adding agents.