So you’re creating your own engine too?
Here’s the analysis: squid-mesh-comparison.md · GitHub
Yeah, but more opinionated and focused on exactly what we need.
Initially I thought that’s a great idea but of course LLMs change the picture substantially and SquidMesh is moving so fast that I might end up just using it – but creating a small opinionated (and likely macro-based) DSL on top of it so the intention of the calls is crystal clear both to my team and our LLMs. We have huge tech debt and the very talkative and cheerfully generating thousands of lines of new code LLMs are not frakkin helping. As a backend lead I am taking measures to start taming our LOC and using my own – or your – workflow engine is going to be a good chunk of that effort. Too many half-done Repo.transaction “sagas” in our code.
Yeah, as if we’re fooling anyone that we do it all manually, right. Everybody knows that strong programmers use agents as productivity multipliers. I am not ashamed because 80% of the time I am steering the wheel. I do have lapses but I am done feeling bad for not being born perfect – I pay attention what is happening, I see the failures and the miscommunications and try to learn and do a better session next time. If anyone can shortcut this and make me even more powerful through LLMs, I’ll be grateful… but I don’t have the time to do this every day for two weeks, for example.
1 Like
I love that one, really well-written and not chatty and verbose as a bank manager on acid. Thanks for posting it.
I particularly love the ideas on what to lift from the other libraries.
And it confirms what I suspected – SquidMesh is already much more feature-rich. Though honestly, why is it “Phoenix/OTP workflow engine”? From what I can see one can use it in a bare Elixir repo just fine, as long as you have Ecto (or just Bedrock-adjacent deps).
1 Like
Ah oops, that’s likely related to your recent web dashboard that you are adding. My bad, forgot. And that’s one more thing that makes SquidMesh irresistible for me.
Yeah. Nothing really I can do other than build with some LLMs at this stage (Dependabot, Copilot, Codex). Until it’s mature and people adopt it, I’ll be pushing agentic code and staying on the loop about what other libraries are doing right.
I am specially disappointed with Claude. Spent a couple of months not using it but was testing today and it drifts even for trivial things like reading its own “manual”:
> why are we not following ~/.claude/CLAUDE.md? is it in the wrong place?
⏺ You're right. I should have created a dedicated worktree and branch first before making any
changes. According to your CLAUDE.md
> why we're not following TDD?
⏺ You're right - according to the CLAUDE.md workflow, I should be following TDD: "failing
test → minimal impl → green → refactor". Let me write the tests first
With AI leverage, we need to continue the discipline of the old times like smaller prs, TDDs, end to end tests, etc otherwise tech debt will grow exponentially. Humans are the bottleneck now as they need to pass the right instructions, review the code, make sure nothing is going off rails.
If there’s another library that is simpler, faster or easier to grasp for your team I’d say go for it. I might be piling too much features in an earlier stage to raise awareness but I am planning to stop after a couple of more issues unless it’s really worth it or someone is needing.
Maybe. But also it could be that it’s referring to the ability of embedding it to Phoenix and also standalone OTP apps.
The web monitoring piece is super simple and read-only now but it’s an interesting way to visualize running workflows.
Codex usually tends to get defensive when i say something different than its AGENTS.md file. Claude seems to completely ignore CLAUDE.md if I don’t pay attention 
1 Like
Yeah, we are circling back to that in my team. LLMs are just too non-deterministic and I am not sure we all want to develop brand new skills i.e. “how to prompt Claude perfectly so it stops doing stupid crap”. Career-wise that’s a very smart move IN THE SHORT TERM and an extremely stupid move in the long-term. This is why I am putting hard caps on my sessions where I just try to devise a better harness for Claude so it needs less supervision. Very mixed success; I had some screaming successes but way too few; most have been embarrassing failures.
I am doing quite OK prompting and my attention rarely drifts but still, it is hugely mentally exhausting to never quite know what you’re getting. I am either taming Claude with hooks in the next 1-2 months or I’ll just start doing the task planning and breaking down on smaller tasks by myself and just delegate it the coding job and nothing else. We’ll see.
But again, I am not interested in doing the big-three-LLM-providers job for them. They are using us as testers and improvers of their own product which I guess is a fair deal having in mind how much I am getting for $100 a month but still, the equation is still not quite in my favor.
Yep. Periodically it just forgets about it at all.
Well shhhh, don’t tell my team, but I am starting to ponder rewriting our app in Rust or Golang. Not like I don’t love Elixir to bits, mind you, but the dynamic typing is not helping, and the tons of shovelware that previous LLMs put in confuses even the frontier models and I have to devise literal dozens of rules and constantly remind them to reread those so they don’t figure “Oh hey, business logic here is literal 17 lines but let’s add 200 more for meaningless defenses on hard contracts where you’d never get a nil, but add them anyway!”.
Exhausting.
But I think that can be alleviated with boundary and reach and dialyzer. I will of course not just do a huge rug-pull like this. A guy can dream though.
But no, no better library in mind. Runic came the closest – extremely disciplined code (I took a look in a few places) but the lack of persistence ultimately swayed me either to my own bespoke workflow engine, or SquidMesh. The latter becomes more likely with each forum post from you.
Sure thing. Dynamic type bite us sometimes. It’s funny that we need no types but we spent a ton of time dealing with dialyxir errors. Hoping the new type system in Elixir would alleviate the pain. Dialyzer errors are not super helpful at times.
In terms of Go/Rust, I’d say we are engineers so the language it’s just a tool. e.g. Jose was trying to solve a problem in Ruby but ended up finding Erlang the best fit so it depends of the problem. No language fits all problems.
If you need to change anything in SquidMesh to match your needs, just let me know. Dont love being the one man show making decisions.
1 Like
Oh, and Zoi of course. It’s quite amazing. I am making an Ecto extension for it with the blessing of the author very soon. It helps with removing ambiguity in typing contracts, like a lot.
2 Likes
Before building SquidMesh, I was experimenting Gleam (because of the types) and built this basic job runner (hit the wall on recovery strategy but decided to stop as there were other libs doing the same with heartbeat) GitHub - ccarvalho-eng/kairos: A background job runner for Gleam. · GitHub
After spending a weekend coding in Gleam, I started missing Elixir
It doesn’t have the same ecosystem (ORMs, Database adapters, etc) so code can look more complex than it actually is.
Btw you’ll not regret if you move to Codex. It’s way more “reliable” or at least it’s stricter following instructions. Eventually it even refuses to make bad choices we give it.
One of my colleagues is telling me the same. Not like I don’t believe it but I spent months building processes and memories of Claude so lifting that to another LLM is a substantial task, and our app is vibe-coded enough to need a lot of guard-rails. Losing those and having to reinvent them from scratch is just a “nope!” from me, though I admit there is a work process during which I could lift all the rules and transfer them to a vendor-neutral file i.e. AGENTS.md. But that does not help with literal 60-ish Claude memories that document many different processes / daily ways of working / gotchas and dangers / non-obvious patterns in our codebase / aspirational refactors so we don’t allow certain slop again (even if we can’t yet refactor it out) etc.
But again, just can’t find the time. I guess I should just say “frak it” and then find the time.
Did a quick skim. Actually I can see where you got certain inspirations. 
Projects like these are mostly learning opportunities. We are blessed to be able to experiment without putting our living spaces on fire. So yep, let’s abuse the freedom!
That’s a real and tangible negative as you found out. I just don’t have the time or even the inclination anymore to be an early adopter of programming languages and I am fine with it.
Libraries and frameworks are another matter. SquidMesh already looks very useful.
Same. Every time I write a Golang program, I facepalm: “Why do these people have a half-implemented OTP runtime with a bunch of footguns? And then they introduce 20 linters to prohibit the usage of 3rd party libraries that fix these idiosyncrasies, even? WTF is wrong with these people?”.
Golang can be so much better if most of the community would just adopt N libraries as de facto standards and finally move on. Which of course reminds me of this wisdom:
Rust is much better, but discoverability of good libraries is very difficult; you have to be in circles and talk to people and be in Discord servers. Too much comms overhead for my taste. But Rust is still strictly and much better if you are willing to put on the elbow grease.
1 Like
Squid Sonar has some controls now (not read-only anymore): GitHub - dark-trench/squid_sonar: Embeddable runtime UI for Squid Mesh · GitHub
It’s not published yet to hex.pm as squid-mesh was not published too. Will push a new release next week
1 Like
Actor-based visibility was added to main GitHub - dark-trench/squid_mesh: Squid Mesh is a Jido-native durable workflow layer with a friendly Elixir DSL for human-in-the-loop and agentic workflows · GitHub
SLA contract is in the works
2 Likes
released Squid Mesh 0.1.0.
This is the first non-prerelease package, and the docs now frame the project around the
supported 0.1.x journal runtime instead of the old early-development warning.
Main things included since the last beta:
- runtime command signals and command history
- runtime-authored workflow specs with safe action registry boundaries
- durable child workflow runs
- saga compensation callbacks and recovery metadata
- deferred continuation support
- executor-owned heartbeats for claimed work
- dynamic work recording, preview, scheduling, and graph overlays
- visual editor spec round trips and draft diffing
- actor-scoped visibility and redaction
- step SLA/deadline contracts exposed through list, inspect, explain, and graph APIs
- clearer Bedrock host app setup for queueing, leasing, retries, cron, and heartbeats
Hex: squid_mesh | Hex
Docs: squid_mesh v0.1.0 — Documentation
Release notes: Release v0.1.0 · dark-trench/squid_mesh · GitHub
The core stance is still the same: Squid Mesh is embedded in the host app, keeps workflow state
durable through Jido journals, and leaves queue delivery, leasing, alerting, and operational
rollout as host-owned boundaries.
3 Likes
will update Squid Sonar to match latest updates so it’s more functional vs read-only
Some minor updates:
- Changed project name to Squidie
- Archived Rift - too long shot for a dogfood app (more focused on ticketing system and workflows would come later and defined only by the host app owners so that would mean more work for testing Squidie)
- Created The Beacon - Just set your discord server channel webhook URL and start receiving Elixir CVEs there powered by Squidie + Bedrock. No Squid Sonar yet
Some minor Squid Sonar features: runtime workflow execution and resume, replay, cancel, approve, etc controls
2 Likes
