Pipelex: declarative DSL and Python runtime for repeatable multi-step LLM pipelines

What they did

Robin, Louis, and Thomas kept rebuilding the same agentic patterns across projects, so they separated generic workflow logic from use-case specifics and built Pipelex: a declarative DSL plus Python runtime for multi-step LLM pipelines, positioned as Dockerfile/SQL for AI workflows. Instead of wrapping provider APIs, the abstraction transcribes business logic into a structured script that says what should be done, not how. Each step carries natural-language context (purpose, inputs and outputs with meaning) so LLMs can follow, audit, and optimize it. Pipes compose: a pipe can call other pipes, yours or ones shared by the community. To dogfood, they built a Pipelex workflow that writes Pipelex workflows, exposed via MCP and CLI as `pipelex build pipe '...'`, which runs a multi-step structured generation flow producing a validated workflow you then execute with `pipelex run` and iterate on by hand or with a coding agent. Shipped pieces: Python library, FastAPI server and Docker image, MCP server, n8n node, and a VS Code extension. They asked HN to try building a workflow, test agent/MCP and n8n usability, suggest new pipe kinds and model integrations, and contribute to the core library or share pipes.

How it went

A public MIT-licensed open standard with spec, runtime, API server, editor extension, MCP server, and n8n node, plus cookbook, starter repo, docs, a two-minute demo, and a Discord. The team is upfront that it is early: the pipe builder is still buggy, there is no hosted API yet, and flow-chart visualization is missing. They frame the launch as a feedback request, asking users to report exactly where it hurts.

Worth knowing

No connectors to your apps: integration happens through code/API, MCP, or n8n. No hosted Pipelex API yet, so you self-host. Cost tracking covers LLM calls only, not image generation or OCR. Caching and reasoning options are unsupported. Flow-chart visualization is still needed, and the pipe builder is acknowledged as buggy, so generated workflows need review before trusting them.

Wiring

Install the Pipelex Python package and set provider credentials; workflows are declared as .plx-style scripts with typed inputs/outputs and natural-language context per step. Run locally via CLI (`pipelex build pipe` to generate, `pipelex run` to execute) or serve through the FastAPI app in Docker. Agents connect through the MCP server, which can both run existing pipelines and generate new ones on demand. Automation platforms connect through the n8n node, which calls the runtime/API. Authoring happens in the VS Code extension for syntax highlighting and semantic coloring. Pipes compose by calling other pipes, so shared community pipes can be imported as steps.

Try it yourself

Clone https://github.com/Pipelex/pipelex and the pipelex-starter repo. Install the Python library, configure model provider keys, and run the starter pipeline with `pipelex run` to confirm the runtime works. Then use `pipelex build pipe '<describe a small multi-step workflow, e.g. summarize a URL then extract action items as structured output>'` to generate a Pipelex script, read it, fix anything the buggy builder got wrong, and run it. Finally, expose the same pipeline through the MCP server and call it from a coding agent, and wire the n8n node to trigger it. Report where the DSL fought you, any builder bugs, and missing pipe kinds or model integrations.