Declarative workflows is such a good idea, fantastic, and I love the AI first principles where pipeline creation and editing the pipeline can be done with AI too.
The declarative style keeps the workflow detail at a high enough level to iterate super quick - love that. More important to me is that it’s structured and seems like it would be more testable (I see validation in your docs).
Zooming in to the pipe/agent steps I can’t quite see if you can leverage MCP as a client and make tool calls? Can you confirm? If not what’s your solution for working with APIs in the middle of your pipeline?
Also a quick question, declarative workflows won’t solve the fact that LLMs output is always non deterministic, and so we can’t always be guaranteed the output from prior steps will be correct. What tools or techniques are you using/recommending to measure the reliability of the output from prior steps? I’m thinking of how might you measure at a step level to help you prioritise which prompts need refinements or optimisations? Is this a problem you expect to own in Pipex or one to be solved elsewhere?
Great job guys, your approach looks like the right way to solve this problem and add some reliability to this space. Thanks for sharing!
Hi Clafferty,
Providing an MCP server was a no brainer and we have the first version available. But you're right, using "MCP as a client" is a question we have started asking ourselves too. But we haven't had the time to experiment yet, so, no definitive answer.
For now, we have a type of pipe called PipeFunc which can call a python function and so possibly any kind of tool under the hood. But that is really a makeshift solution. And we are eager to get your point of view and discuss with the community to get it right.
Many companies are working on evals and we will have a strategy for integration with Pipelex. What we have already is modularity: you can test each pipe separately or test a whole workflow, that is pretty convenient. Better yet, we have the "conceptual" level of abstraction: the code is the documentation. So you don't need any additional work to explain to an eval system what we were expecting at each workflow step: it's already written into it. We even plan to have an option (typically for debug mode) that checks every input and every output complies semantically with what was intended and expected.
Thanks a lot for your feedback! It's a lot of work so greatly appreciated.
Recently I'm working on a project that let the users to analyze and rate the bid documents based on one tender document. The general logic is quite alike to the cv-job_offer example in Pipelex. The challenge I encountered is that both tender and bid documents are very large, it's impossible to load even a single one in LLM context, not to say both. Therefore I have to design a workflow to extract structured informations and evaluation criteria from the tender doc into predefined data models, and then dispatch multiple tasks to complete evaluation of these data models against each bid doc.
I'm wondering if this kind of scenario (essentially it's just the input document is too big) is possible to be handled in Pipelex. In my understanding DSL is good for it's high-level abstraction and easy to understand, but lacks flexibility and the power is restricted. How can the users of Pipelex iterate the pipelines to fulfill the complex need when the business logic became complex inevitably?
When the business logic becomes complex, our motto which is to break it down into smaller problems, until they are manageable.
Regarding large docs, I know what you mean and we've been there: at one point we considered focusing on that feature, build a kind of agentic system to master large docs. At the time in 2023-2024, everyone was relying on vector store RAG and embeddings to solve that problem but we always thought that solution wouldn't bring enough reliability. We wanted the LLM to actually read the whole docs, in order to know what's in there and where. The idea was to read and "take notes" according to different aspects of what it's reading, and synthesize hierarchically from bottom to top. So, that part of the work could be done once and the structured "notes" could be exploited for each use case, pretty efficiently thanks to the zoom-in/out provided by the architecture.
We went pretty far in building that solution, which we called "Pyramid RAG" internally, and the aim was to build AI workflows of top of that. But at some point, the building of the pyramid became pretty complex, and we realized we needed AI workflows to build the pyramid itself, and we needed to to do it right. That's when we decided to focus on what would become Pipelex.
Now, in our new setting, solving the "large docs" problem is a large problem we can break down into a collection of Pipelex workflows. So it's part of our plan to provide those building blocks, and we hope to involve the community as much as possible, to cover all the possible applications.
Very thoughtful and inspiring suggestion, I think we are on the same road, which really makes it much clear to me. Looking forward seeing the Pipelex solution for these kind of problems.
I don't see any provisions for scaling up workflows horizontally — is that something this supports, or this more for interactive agents?
As an example, I have a use case where I'm processing millions of documents in a fan-out/fan-in pipeline that uses multiple LLMs to analyze and condense information. This mostly isn't CPU-bound, but it does consume a lot of RAM.
I'm currently using Ray to split the workload across a cluster. Ray has autoscaling, so it's very good for this kind of thing.
Hi atombender, you have a point.
The current runtime supports asynchronous operations with the limits of python asyncio and your CPU/RAM.
But we designed our orchestration layer so that it could integrate easily with durable workflow platforms such as temporal.io which also bring the ability to spread the load over many workers, which will give you horizontal scaling.
Our integration with temporal.io has been working as a prototype in our lab for many months but we had to focus on the core features to nail down our language and make it as easy to use as possible. Now in the coming weeks we'll be able to focus more on the temporal-powered version, adding the missing features to make it practical, which will also make it usable with other workflow platforms.
Hi novoreorx,
the biggest difference is that in Pipelex workflows, we express the logic in our high-level language, rather than in Python or typescript.
This makes it easier to collaborate between tech and non-tech people, like domain experts. It's also great for collaboration with AI: the declarative approach and the high level of abstraction means that LLMs have all the context to understand what's going on in the workflow.
Also, we don't use Pipelex for "autonomous agents": our workflows are meant to be repeatable and deterministic, like a tool. Like a tool that can be used by agents though our MCP server.
We get this question of comparison to BAML often, so let me take the time to clarify the differences:
Positioning:
• Pipelex is an AI workflow orchestrator. You declare multi-step pipelines (.plx) with LLM calls, OCR/PDF extraction, image generation, custom Python/tool steps, conditionals, and parallelism, then run them via CLI or Python, FastAPI/Docker, MCP, or n8n node.
• BAML defines typed, single-call “AI functions” (primarily LLM interactions) and compiles them into SDKs you call from your app; you typically orchestrate multi-step flows and any non-LLM work in your own code.
Developer experience:
• Pipelex feels like writing a readable pipeline spec you can iterate on or auto-generate and then execute end-to-end. Non-LLM ops (OCR, PDF, image gen, API calls) are first-class pipes you compose with LLM steps.
• BAML feels like writing typed prompt functions with templates and getting a clean, generated client API. Non-LLM work (OCR, PDF parsing, external APIs) usually sits in your app code or tools around those generated functions.
Structured output:
• Not exclusive to BAML. Pipelex’s PipeLLM supports strongly typed structured generation (based on the instructor package). Define schemas directly in .plx (simple concept syntax) or in Python with Pydantic v2, including custom validators and arbitrary validation logic.
Where each fits:
• If you want to design and run full workflows (extract → analyze → generate, with branching/parallelism) and keep that logic declarative and shareable, Pipelex is a great fit.
• If you mainly need reliable, typed “AI functions” embedded in an existing codebase, Pipelex also works well (define structures in Pydantic and call steps from Python). BAML is likewise a good fit when you prefer generated SDKs and you’re comfortable orchestrating steps and non-LLM work in app code.
Why Pipelex’s higher abstraction matters:
• It captures business logic and domain know-how in a structured, unambiguous language. Instead of burying intent across scattered prompts and glue code, a .plx file centralizes the specification (data concepts, pre/post-conditions, step semantics). That makes workflows easier to review, version, audit, and hand off, by humans and by AI, while remaining extensible to new AI/software operations.
TL;DR:
• Pipelex = declarative workflow engine/standard for multi-step AI pipelines, with first-class non-LLM ops and strongly typed outputs.
• BAML = typed prompt/function language that generates SDKs; you assemble and extend around it in your app.
Declarative DSL is a really interesting approach, especially since you’re exposing it directly to the users. There are some applications where throwing the dice in production by having LLM as part of the runtime is not an option.
Yes! Clearly the introduction of LLMs into the mix raises the problem of throwing dice.
The point of view we chose is: how to orchestrate the collaboration between AI, Software and people?
With our aim to have repeatable workflows, this drove us away from building autonomous agents and towards a place where the software is in command of the orchestration. Then the Humans and AI can discuss "what you want to do" and have software run it and use AI where it's needed.
Sorry, I guess I'm not fully understanding what this is exactly. Would you describe this as a low-code/no-code agent generator? So if you can define requirements via a pipelex "config" file, Pipelex will generate a python-based agent?
Hi RoyTyrell,
I guess you could call it low-code, a new kind of no-code where we have natural language in the mix.
But no, Pipelex does not generate a python-based agent: the pipelex script is interpreted at runtime.
Very cool declarative + agent-first is the right direction. Love the “Dockerfile for AI reasoning” analogy. Excited to try composing Pipelex with Codiris workflows.
Currently, a failed step means you need to restart everything: we have started to add features that save intermediate states so you can recover from there but the recovery part is not finished.
Our main strategy is to make Pipelex easy to integrate with durable workflow orchestrators which are really good at solving that problem. For instance, we'll soon release a plugin integration with temporal.io.
Hi cranberryturkey,
currently, we offer an open-source API server that you can run on your infrastructure, directly or through our docker image: https://github.com/Pipelex/pipelex-api
If what you're after is a hosted API where you just need to get an API key and run workflows on our infrastructure, we are working on it. It will open soon and you can join the waitlist to get early access: https://go.pipelex.com/waitlist
Declarative workflows is such a good idea, fantastic, and I love the AI first principles where pipeline creation and editing the pipeline can be done with AI too.
The declarative style keeps the workflow detail at a high enough level to iterate super quick - love that. More important to me is that it’s structured and seems like it would be more testable (I see validation in your docs).
Zooming in to the pipe/agent steps I can’t quite see if you can leverage MCP as a client and make tool calls? Can you confirm? If not what’s your solution for working with APIs in the middle of your pipeline?
Also a quick question, declarative workflows won’t solve the fact that LLMs output is always non deterministic, and so we can’t always be guaranteed the output from prior steps will be correct. What tools or techniques are you using/recommending to measure the reliability of the output from prior steps? I’m thinking of how might you measure at a step level to help you prioritise which prompts need refinements or optimisations? Is this a problem you expect to own in Pipex or one to be solved elsewhere?
Great job guys, your approach looks like the right way to solve this problem and add some reliability to this space. Thanks for sharing!
Hi Clafferty, Providing an MCP server was a no brainer and we have the first version available. But you're right, using "MCP as a client" is a question we have started asking ourselves too. But we haven't had the time to experiment yet, so, no definitive answer. For now, we have a type of pipe called PipeFunc which can call a python function and so possibly any kind of tool under the hood. But that is really a makeshift solution. And we are eager to get your point of view and discuss with the community to get it right.
Many companies are working on evals and we will have a strategy for integration with Pipelex. What we have already is modularity: you can test each pipe separately or test a whole workflow, that is pretty convenient. Better yet, we have the "conceptual" level of abstraction: the code is the documentation. So you don't need any additional work to explain to an eval system what we were expecting at each workflow step: it's already written into it. We even plan to have an option (typically for debug mode) that checks every input and every output complies semantically with what was intended and expected.
Thanks a lot for your feedback! It's a lot of work so greatly appreciated.
+1 for MCP client support. I’ve backed off MCP after an initial burst of enthusiasm specifically because the client ecosystem is limited.
Recently I'm working on a project that let the users to analyze and rate the bid documents based on one tender document. The general logic is quite alike to the cv-job_offer example in Pipelex. The challenge I encountered is that both tender and bid documents are very large, it's impossible to load even a single one in LLM context, not to say both. Therefore I have to design a workflow to extract structured informations and evaluation criteria from the tender doc into predefined data models, and then dispatch multiple tasks to complete evaluation of these data models against each bid doc.
I'm wondering if this kind of scenario (essentially it's just the input document is too big) is possible to be handled in Pipelex. In my understanding DSL is good for it's high-level abstraction and easy to understand, but lacks flexibility and the power is restricted. How can the users of Pipelex iterate the pipelines to fulfill the complex need when the business logic became complex inevitably?
When the business logic becomes complex, our motto which is to break it down into smaller problems, until they are manageable.
Regarding large docs, I know what you mean and we've been there: at one point we considered focusing on that feature, build a kind of agentic system to master large docs. At the time in 2023-2024, everyone was relying on vector store RAG and embeddings to solve that problem but we always thought that solution wouldn't bring enough reliability. We wanted the LLM to actually read the whole docs, in order to know what's in there and where. The idea was to read and "take notes" according to different aspects of what it's reading, and synthesize hierarchically from bottom to top. So, that part of the work could be done once and the structured "notes" could be exploited for each use case, pretty efficiently thanks to the zoom-in/out provided by the architecture. We went pretty far in building that solution, which we called "Pyramid RAG" internally, and the aim was to build AI workflows of top of that. But at some point, the building of the pyramid became pretty complex, and we realized we needed AI workflows to build the pyramid itself, and we needed to to do it right. That's when we decided to focus on what would become Pipelex. Now, in our new setting, solving the "large docs" problem is a large problem we can break down into a collection of Pipelex workflows. So it's part of our plan to provide those building blocks, and we hope to involve the community as much as possible, to cover all the possible applications.
> Now, in our new setting, solving the "large docs" problem is a large problem we can break down into a collection of Pipelex workflows.
I think a solution to this problem as a runnable example would be a nice showcase of what is achievable with pipelex.
Working on it.
Very thoughtful and inspiring suggestion, I think we are on the same road, which really makes it much clear to me. Looking forward seeing the Pipelex solution for these kind of problems.
I don't see any provisions for scaling up workflows horizontally — is that something this supports, or this more for interactive agents?
As an example, I have a use case where I'm processing millions of documents in a fan-out/fan-in pipeline that uses multiple LLMs to analyze and condense information. This mostly isn't CPU-bound, but it does consume a lot of RAM.
I'm currently using Ray to split the workload across a cluster. Ray has autoscaling, so it's very good for this kind of thing.
Hi atombender, you have a point. The current runtime supports asynchronous operations with the limits of python asyncio and your CPU/RAM. But we designed our orchestration layer so that it could integrate easily with durable workflow platforms such as temporal.io which also bring the ability to spread the load over many workers, which will give you horizontal scaling.
Our integration with temporal.io has been working as a prototype in our lab for many months but we had to focus on the core features to nail down our language and make it as easy to use as possible. Now in the coming weeks we'll be able to focus more on the temporal-powered version, adding the missing features to make it practical, which will also make it usable with other workflow platforms.
Temporal is solid, glad to hear it's being worked on.
Love the concept, I saw similar ideas in BAML [1], what do you think are the differences and advantages of Pipelex over it?
[1]: https://github.com/boundaryml/baml
Hi novoreorx, the biggest difference is that in Pipelex workflows, we express the logic in our high-level language, rather than in Python or typescript. This makes it easier to collaborate between tech and non-tech people, like domain experts. It's also great for collaboration with AI: the declarative approach and the high level of abstraction means that LLMs have all the context to understand what's going on in the workflow. Also, we don't use Pipelex for "autonomous agents": our workflows are meant to be repeatable and deterministic, like a tool. Like a tool that can be used by agents though our MCP server.
Interesting Wondering how this compares to BAML
See: https://docs.boundaryml.com/home
We get this question of comparison to BAML often, so let me take the time to clarify the differences:
Positioning:
• Pipelex is an AI workflow orchestrator. You declare multi-step pipelines (.plx) with LLM calls, OCR/PDF extraction, image generation, custom Python/tool steps, conditionals, and parallelism, then run them via CLI or Python, FastAPI/Docker, MCP, or n8n node.
• BAML defines typed, single-call “AI functions” (primarily LLM interactions) and compiles them into SDKs you call from your app; you typically orchestrate multi-step flows and any non-LLM work in your own code.
Developer experience:
• Pipelex feels like writing a readable pipeline spec you can iterate on or auto-generate and then execute end-to-end. Non-LLM ops (OCR, PDF, image gen, API calls) are first-class pipes you compose with LLM steps.
• BAML feels like writing typed prompt functions with templates and getting a clean, generated client API. Non-LLM work (OCR, PDF parsing, external APIs) usually sits in your app code or tools around those generated functions.
Structured output:
• Not exclusive to BAML. Pipelex’s PipeLLM supports strongly typed structured generation (based on the instructor package). Define schemas directly in .plx (simple concept syntax) or in Python with Pydantic v2, including custom validators and arbitrary validation logic.
Where each fits:
• If you want to design and run full workflows (extract → analyze → generate, with branching/parallelism) and keep that logic declarative and shareable, Pipelex is a great fit.
• If you mainly need reliable, typed “AI functions” embedded in an existing codebase, Pipelex also works well (define structures in Pydantic and call steps from Python). BAML is likewise a good fit when you prefer generated SDKs and you’re comfortable orchestrating steps and non-LLM work in app code.
Why Pipelex’s higher abstraction matters:
• It captures business logic and domain know-how in a structured, unambiguous language. Instead of burying intent across scattered prompts and glue code, a .plx file centralizes the specification (data concepts, pre/post-conditions, step semantics). That makes workflows easier to review, version, audit, and hand off, by humans and by AI, while remaining extensible to new AI/software operations.
TL;DR:
• Pipelex = declarative workflow engine/standard for multi-step AI pipelines, with first-class non-LLM ops and strongly typed outputs.
• BAML = typed prompt/function language that generates SDKs; you assemble and extend around it in your app.
Declarative DSL is a really interesting approach, especially since you’re exposing it directly to the users. There are some applications where throwing the dice in production by having LLM as part of the runtime is not an option.
Yes! Clearly the introduction of LLMs into the mix raises the problem of throwing dice. The point of view we chose is: how to orchestrate the collaboration between AI, Software and people? With our aim to have repeatable workflows, this drove us away from building autonomous agents and towards a place where the software is in command of the orchestration. Then the Humans and AI can discuss "what you want to do" and have software run it and use AI where it's needed.
Sorry, I guess I'm not fully understanding what this is exactly. Would you describe this as a low-code/no-code agent generator? So if you can define requirements via a pipelex "config" file, Pipelex will generate a python-based agent?
Hi RoyTyrell, I guess you could call it low-code, a new kind of no-code where we have natural language in the mix. But no, Pipelex does not generate a python-based agent: the pipelex script is interpreted at runtime.
Very cool declarative + agent-first is the right direction. Love the “Dockerfile for AI reasoning” analogy. Excited to try composing Pipelex with Codiris workflows.
Waiting for partnership to propose to our users
Thanks, Ronald! Yes, very interested in discussing integrations. Pipelex is super modular and open by design, so it should be a breeze.
Love the DSL. Saw caching is roadmap — does a failed step restart everything, or resume partway?
Hi teunlao,
Currently, a failed step means you need to restart everything: we have started to add features that save intermediate states so you can recover from there but the recovery part is not finished.
Our main strategy is to make Pipelex easy to integrate with durable workflow orchestrators which are really good at solving that problem. For instance, we'll soon release a plugin integration with temporal.io.
does pipex expose any kind of api I can build around?
Hi cranberryturkey, currently, we offer an open-source API server that you can run on your infrastructure, directly or through our docker image: https://github.com/Pipelex/pipelex-api If what you're after is a hosted API where you just need to get an API key and run workflows on our infrastructure, we are working on it. It will open soon and you can join the waitlist to get early access: https://go.pipelex.com/waitlist