I was initially really excited by LangChain/LangGraph, so I spent more than a few days implementing our workflows in LangGraph, everything worked as advertised, but for a ton of work, I basically had 20% of our flow requirements covered, and then I had to start extending everything.
Likewise, CrewAI is a great product. Spent a few days implementing everything over again in CrewAI — got a little further, but not much.12
It got to one of those points, that you realize you are spending so much time making someone else’s framework fit your needs. Back in the before time, I used to do SAP R/3 implementations for Fortune 50 companies, There was always a point where you sat down with the team and CIO/CTO and maybe the CEO, and had to explain that there are two options: 1) you change your business to fit SAP R/3’s way of doing business, or 2) you built a ton of custom software and got to support it forever. The question was, are you in the tech fab business, or are you now a software company.
It was the same deal here, forcing the DigiMuse flows to fit the way that LangChain or CrewAI worked, or build a whole new layer of complexity.
Our focus is client first, so compromising services we provide goes against our goals. Additionally, we have an experienced team, so taking on the support burden, especially for such a well known pattern (Directed Acyclic Graph) seemed to make it clear.
Just a short mention of MCPs3, I love a standard, any standard, for tools that are used by flow nodes. But again, we hit that 20% wall. DigiMuse, at it’s core, has a few ways it “uses” AI. The design centers on context — all they way through. We expend a lot of design time and effort on building the best context possible, to pass with the queries — so we needed better context capabilities. Additionally, our “topics”, such as skill sets, resumes, experience statements, they all seem to hit the LLM right were it likes to wander around a lot. So getting the responses to be consistent between runs, and between users (IE: a good DB Architect named Sam, and one named Sally with the same experience should yield roughly the same skill sets and experience levels), get really variable if you do not watch it.4 So we are fascinated on getting the prompt context centered on the user, in relevancy and scope. We also do a lot of few-shot and ReAct in the process — it is a blend of old schools text analysis and agentic AI — how that gets implemented and balance really matters. Back to tooling, our needs go beyond the standard tools in a lot of cases, so we would have to extend and augment the existing tools — doable, but a whole lot of code and support tail for what purpose? Our business model is not turning around and selling our software — we are not that company.
If I sound down on frameworks, I am not, They have their roles, and implementation must be balanced with the project goals and needs. But for us, we wrote our own.
tldr; If we went with LangGraph or CrewAI — we would have to put the software in the core of the system, and change our processes to be closer to theirs. The “persistence” that LangGraph offers between nodes (checkpointing), we already do in a deeper way (we have tenants, visibility requirements, audit, and our security policies that are involved), and our guard rails have broader requirements. These really need to be “baked in” to the flow, not as extensions or wrappers…that would take longer than writing our own.
But I do know that every project is different, and for the right project requirements — I cannot wait to use CrewAI or LangChain/LangGraph — they are good code. I stole a lot of their design patterns, terminology, and share a log of their architecture goals. Maybe the next project… 😉
- I have taken several hours of training, and even more in developing in CrewAI and LangChain/LangGraph. ↩︎
- CrewAI does this really cool thing around “crews” of agents working together. This reminds me a bit of a scalability problem in an API I wrote — turns out that you can scale sideways (use Kubernetes, run lots of AI’s) if you follow microservice design patterns. So crews are cool, but DigiMuse flows really can be one worker wide, but lots of them running at the same time separately. ↩︎
- Model Context Protocol: it is all about accessing data, tools, and prompts in a standard way. ↩︎
- I really wonder about how other AI “Resume Builders” handle this, do they just send off a list of questions the user answers, and tells the AI “build a resume.” I have not tested, but I probably should. ↩︎