Prompt flow: Microsoft's Python toolkit for testing and shipping LLM apps

The gap prompt flow fills between a notebook and a deployed LLM app

A prompt that works in a notebook is not an application. The moment you add a retrieval step, a Python post-processor and a second model call, you have a pipeline whose behaviour changes every time you edit a string. Prompt flow is aimed at that moment. The README describes it as a suite of development tools covering ideation, prototyping, testing, evaluation, deployment and monitoring, with the stated goal of making prompt engineering easier and enabling production-quality LLM apps.

The intended user is a Python developer or a small team that wants the pipeline expressed as files under version control rather than as cells in a notebook. The README lists three capability groups: creating executable flows that link LLMs, prompts, Python code and tools; evaluating quality and performance over larger datasets and wiring that into CI/CD; and deploying the flow to a serving platform or embedding it in an application's codebase. The optional cloud path is Prompt flow in Azure AI, which the README calls highly recommended for team collaboration. That framing tells you where Microsoft expects the product to be used: locally for authoring, in Azure for shared work.

How a flow.dag.yaml becomes an executable graph

A flow is a directory. The README points to `flow.dag.yaml` inside the generated `my_chatbot` folder as the file that outlines the flow: inputs and outputs, nodes, connection and the LLM model. Nodes are the units of work, and the README's concept links describe tools as the things a node can call, which is how LLM prompts, Python functions and other utilities end up in the same graph. A connection is a named credential object, referenced by name from a node rather than pasted into the prompt.

That naming is the part worth understanding before you write anything. In the generated chat template the chat node refers to a connection named `open_ai_connection`, and the model is selected through a `deployment_name` field, which the README says specifies either the OpenAI model or the Azure OpenAI deployment resource. The same field therefore means two different things depending on which backend the connection points at, and switching providers is a change to the connection plus that field, not to your prompt text. Execution happens through the `pf` command line, and the flow can also be opened in the VS Code extension, which the README describes as a flow designer for interactive development. Tracing of LLM interactions is a first-class feature with its own how-to guide, which matters because a DAG you cannot inspect mid-run is hard to debug.

Installing promptflow and running a first chat flow

The README recommends Python 3.9 through 3.11 and says to install two packages. Run this in a virtual environment; the second package supplies the built-in tools the templates rely on.

pip install promptflow promptflow-tools

Next, generate a project from the chat template. The command creates a folder named `my_chatbot` and writes the required files into it, including `flow.dag.yaml` and the connection YAML files.

pf flow init --flow ./my_chatbot --type chat

Create a connection so the flow has credentials. For OpenAI, the README uses the `openai.yaml` file in that folder and passes the key with `--set`, which avoids editing the YAML by hand.

pf connection create --file ./my_chatbot/openai.yaml --set api_key=<your_api_key> --name open_ai_connection

For Azure OpenAI the same command takes an additional `api_base` value, and the README shows the `azure_openai.yaml` file for that case.

pf connection create --file ./my_chatbot/azure_openai.yaml --set api_key=<your_api_key> api_base=<your_api_base> --name open_ai_connection

Finally, talk to the flow. The interactive flag starts a session you end with Ctrl+C, and you should see responses from the model named in the chat node's `deployment_name` field.

pf flow test --flow ./my_chatbot --interactive

From there the README points to a 15-minute tutorial covering prompt tuning, batch testing and evaluation, and to a chat-with-PDF example that includes evaluation metrics.

Where prompt flow is the wrong tool, and what it costs you

Prompt flow is opinionated about files. If your team wants to compose agents at runtime in code, with control flow that shifts based on model output, a DAG declared in YAML will feel like a straitjacket. The graph is the unit of work, and the README's framing of flows as the thing you create, evaluate and deploy makes that clear. Anything that does not fit a node boundary has to be pushed into a Python tool.

The documentation is also thinner than the feature list suggests. The README covers installation, flow creation, connections and interactive testing, but it does not document rollback of a deployed flow, nor does it give a migration path between model versions. The `migration-guide/` directory exists at the top level of the repository, which suggests migration is treated as a separate concern rather than something the README walks you through. Release cadence is another data point: the most recent release listed is promptflow 1.17.1 from 2025-01-09, while the last push to the repository was on 2026-08-26. Commits are landing, but the published package has not moved in a long time, so pinning a version and reading the changelog before upgrading is the safer posture.

There is a provider lock-in dimension too. The quick start is built around OpenAI and Azure OpenAI connections, and the cloud collaboration story is Azure AI. Other model providers are reachable through tools you write yourself, but the happy path assumes those two.

Prompt flow versus LangChain, Semantic Kernel and the visual builders

The comparison people search for most is prompt flow against LangChain. The difference is where the structure lives. LangChain is a Python library: you build chains by calling classes and functions, and the program is the source of truth. Prompt flow inverts that. The flow is a YAML file and a folder of assets, and the CLI or the VS Code designer executes it. You get a reviewable artifact and a batch evaluation command for free; you give up the freedom to express arbitrary control flow in code.

Semantic Kernel sits closer to LangChain in that it is a library you call, with its own plugin and planner concepts, and it is not tied to a YAML graph. Autogen takes a different axis entirely, focusing on multi-agent conversation rather than a single evaluated pipeline. n8n is a general workflow automation tool with a visual canvas; prompt flow's canvas is tied to LLM evaluation and deployment rather than to connecting SaaS systems. MLflow overlaps on experiment tracking and evaluation, but it does not define an LLM flow as a deployable DAG with connections. None of these is a drop-in replacement, and the honest question is whether you want your pipeline to be a program or a document.

Licence, maintenance and the upgrade bill

The repository is MIT licensed, which permits commercial use and modification with the usual requirement to keep the copyright notice; the LICENSE file at the repository root is the authoritative text, and this is not legal advice. No separate enterprise tier is described in the README, though the Azure AI cloud service is a distinct product with its own terms.

The upgrade cost is mostly environmental. Python 3.9 to 3.11 is the recommended range, so a team on 3.12 has to solve that before anything else. The `promptflow-tools` package versions independently of the core package and supplies the built-in tools, so a flow that depends on a specific tool can break when only that package moves. Because the last published release predates the most recent commits by more than a year, running from PyPI and running from `main` are meaningfully different experiences, and the README does not describe a support window for either.

Editorial conclusion

Adopt prompt flow if you already write Python and want evaluation, tracing and deployment to sit in the same repository as the flow definition, especially on Azure AI. Skip it if you need a visual-first builder or a framework whose abstractions you never inspect. Before committing, verify that your Python version is in the supported range, that your chosen model deployment works through the connection you create, and that the evaluation metrics you need exist in promptflow-tools.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/promptflow on GitHub
3. Project website
4. README
5. Releases