> * there is LangChain and LangGraph - used a lot, but framework bloat is hated as well
I've used them a fair bit, and I'm not a huge fan. Only self-hosted, I can't comment on their cloud-SaaS agent runner thing. The observability looks neat, though.
LangChain is nice enough, I appreciate having a unified API across providers. LangGraph is... just not all that much? As in the DAG is too much for a simple agent, but when I start thinking about a large agent and dealing with that flow in their their DAG DSL my head starts to hurt. "Go To Definition" isn't going to help navigate that very well, the state is going to be a lot of Optional's with not a lot of info on when they have a real value at which stages in the DAG.
I had substantial issues with branches in my DAG because the state has to include all possible fields for every step. It gets hard to mentally track all the combinations of fields that will be present or missing depending on the path taken upstream of this node. Do I have RAG results? Not sure, it depends on whether the query includes X, but then later it also depends on whether a tool returns a particular result, in which case it can either be missing, have a single value or have 2 values. Yada yada, in a sufficiently large DAG it gets hard to track those. Things are much cleaner in function world where you can declare "this functions require X and Y, and can optionally provide Z".
I mostly go directly to the API these days, but I'm fairly settled on Ollama. I might use LangChain if I think I'll want another backend, but I also might use OpenRouter. I haven't yet, but it seems cool.
raghilda is deliberately narrower than LangGraph/Haystack/etc. It focuses on the RAG parts: document ingestion, chunking, embedding, storage, and retrieval. It’s meant to leave the pieces visible and replaceable rather than wrap the whole application in a framework.
It also composes well with the other parts of the Posit ecosystem: chatlas for LLM interaction, and Shiny for building interactive apps around the result.
My bias is that orchestration is often better hand-rolled for the specific application. Once the framework gets too far removed from the actual steps, it tends to bring in a lot of complexity you probably don’t need. In the end, most of these pieces are not that complicated.
People who name projects, please think very carefully if you want to use "Haystack" as the name of anything. There are literally thousands upon thousands of both overlapping and completely different products, projects, bands, initiatives, efforts, and so on with that name and all the possible variants you can think of (Haystax, Heystack, Heystax, Hay Stak, and so on).
And no, you probably won't be the first project with that name in whatever market/vertical/milieu that you are working in.
I found half a dozen different "Haystack" products and companies working in AI in 10 seconds of googling.
> Haystack collects anonymous usage statistics of pipeline components. We receive an event every time these components are initialized. This way, we know which components are most relevant to our community.
Observability keeps coming up in this thread, and it's the part I never think about until I'm debugging something an agent did at 2am.
Claude Code specifically. Adoption is the easy part, I love thinking how I have 10x'd everything, but figuring out what it actually shipped to prod last Tuesday when something broke sucks
Anyone solved this without going full framework or rebuilding everything from scratch?
16 comments
[ 3.1 ms ] story [ 42.5 ms ] threadno, thanks, never going to use that.
For example,
* there is LangChain and LangGraph - used a lot, but framework bloat is hated as well
* mastra - for typescript projects
* pydantic, agno, strands, openai agents sdk, claude agents sdk, and so on and on and on
I've used them a fair bit, and I'm not a huge fan. Only self-hosted, I can't comment on their cloud-SaaS agent runner thing. The observability looks neat, though.
LangChain is nice enough, I appreciate having a unified API across providers. LangGraph is... just not all that much? As in the DAG is too much for a simple agent, but when I start thinking about a large agent and dealing with that flow in their their DAG DSL my head starts to hurt. "Go To Definition" isn't going to help navigate that very well, the state is going to be a lot of Optional's with not a lot of info on when they have a real value at which stages in the DAG.
I had substantial issues with branches in my DAG because the state has to include all possible fields for every step. It gets hard to mentally track all the combinations of fields that will be present or missing depending on the path taken upstream of this node. Do I have RAG results? Not sure, it depends on whether the query includes X, but then later it also depends on whether a tool returns a particular result, in which case it can either be missing, have a single value or have 2 values. Yada yada, in a sufficiently large DAG it gets hard to track those. Things are much cleaner in function world where you can declare "this functions require X and Y, and can optionally provide Z".
I mostly go directly to the API these days, but I'm fairly settled on Ollama. I might use LangChain if I think I'll want another backend, but I also might use OpenRouter. I haven't yet, but it seems cool.
https://posit-dev.github.io/raghilda/
raghilda is deliberately narrower than LangGraph/Haystack/etc. It focuses on the RAG parts: document ingestion, chunking, embedding, storage, and retrieval. It’s meant to leave the pieces visible and replaceable rather than wrap the whole application in a framework.
It also composes well with the other parts of the Posit ecosystem: chatlas for LLM interaction, and Shiny for building interactive apps around the result.
My bias is that orchestration is often better hand-rolled for the specific application. Once the framework gets too far removed from the actual steps, it tends to bring in a lot of complexity you probably don’t need. In the end, most of these pieces are not that complicated.
Disclosure: I’m one of the authors of raghilda.
Clients choose it because it's EU-based company.
And no, you probably won't be the first project with that name in whatever market/vertical/milieu that you are working in.
I found half a dozen different "Haystack" products and companies working in AI in 10 seconds of googling.
Please make it stop.
For an EU based company, this stands out.