Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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

    by ronaldgumo
  • 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.
    by hartem_
  • 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?
    by RoyTyrell
  • Interesting Wondering how this compares to BAML

    See: https://docs.boundaryml.com/home

    by AIorNot
  • 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.

    by atombender
  • 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

    by novoreorx
  • 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?

    by novoreorx
  • 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!

    by clafferty

Explore Birbla archives