Why this instead of yet another workflow builder?

- Declarative, not glue code: you state what to do; the runtime figures out how. - Agent-first: each step carries natural-language context (purpose, inputs/outputs with meaning) so LLMs can follow, audit, and optimize. Our MCP server enables agents to run pipelines but also to build new pipelines on demand. - Open standard under MIT: language spec, runtime, API server, editor extensions, MCP server, n8n node. - Composable: pipes can call other pipes, created by you or shared in the community.

Why a domain-specific language?

- We need context, meaning and nuances preserved in a structured syntax that both humans and LLMs can understand - We need determinism, control, and reproducibility that pure prompts can't deliver - Bonus: editors, diffs, semantic coloring, easy sharing, search & replace, version control, linters…

How we got there:

Initially, we just wanted to solve every use-case with LLMs but kept rebuilding the same agentic patterns across different projects. So we challenged ourselves to keep the code generic and separate from use-case specifics, which meant modeling workflows from the relevant knowledge and know-how.

Unlike existing code/no-code frameworks for AI workflows, our abstraction layer doesn't wrap APIs, it transcribes business logic into a structured, unambiguous script executable by software and AI. Hence the "declarative" aspect: the script says what should be done, not how to do it. It's like a Dockerfile or SQL for AI workflows.

Additionally, we wanted the language to be LLM-friendly. Classic programming languages hide logic and context in variable names, functions, and comments: all invisible to the interpreter. In Pipelex, these elements are explicitly stated in natural language, giving AI full visibility: it's all logic and context, with minimal syntax.

Then, we didn't want to write Pipelex scripts ourselves so we dogfooded: we built a Pipelex workflow that writes Pipelex workflows. It's in the MCP and CLI: "pipelex build pipe '…'" runs a multi-step, structured generation flow that produces a validated workflow ready to execute with "pipelex run". Then you can iterate on it yourself or with any coding agent.

What’s included: Python library, FastAPI and Docker, MCP server, n8n node, VS Code extension.

What we’d like from you

1. Build a workflow: did the language work for you or against you? 2. Agent/MCP workflows and n8n node usability. 3. Suggest new kinds of pipes and other AI models we could integrate 4. Looking for OSS contributors to the core library but also to share pipes with the community

Known limitations

- Connectors: Pipelex doesn’t integrate with “your apps”, we focus on the cognitive steps, and you can integrate through code/API or using MCP or n8n - Visualization: we need to generate flow-charts - The pipe builder is still buggy - Run it yourself: we don’t yet provide a hosted Pipelex API, it’s in the works - Cost-tracking: we only track LLM costs, not image generation or OCR costs yet - Caching and reasoning options: not supported yet

Links

- GitHub: https://github.com/Pipelex/pipelex - Cookbook: https://github.com/Pipelex/pipelex-cookbook - Starter: https://github.com/Pipelex/pipelex-starter - VS Code extension: https://github.com/Pipelex/vscode-pipelex - Docs: [https://docs.pipelex.com](https://docs.pipelex.com/) - Demo video (2 min): https://youtu.be/dBigQa8M8pQ - Discord for support and sharing: https://go.pipelex.com/discord

Thanks for reading. If you try Pipelex, tell us exactly where it hurts, that’s the most valuable feedback we can get.