Launching today
Finyuus
A code-first language for durable, governed AI workflows
50 followers
A code-first language for durable, governed AI workflows
50 followers
ConFinyuus is a code-first platform for building, running, and governing AI workflows. It introduces a small indentation-based DSL for composing agents, tools, guards, human approvals, and nested workflows — then runs them on Temporal with retries, cancellation, and replayability. Unlike visual builders, workflows are stored as text for Git-based review and diffs. Unlike prompt chains, every run is durable, versioned, observable via Langfuse, and governable through guards and human approvals.
Mnexium AI
the durability and git-diffable execution graph is the genuinely useful part, that's a real gap in a lot of prompt-chain tools. the new DSL is the part I'd push back on though - Temporal already has SDKs in Python and TypeScript that get you retries, replay and versioning without asking anyone to learn new indentation rules. what does the language buy you over a thin Python wrapper around the same guards and approvals, besides a smaller surface to write the interpreter for? "governable" and "diffable" don't obviously require a new syntax, they require the underlying execution model you already built.
Mnexium AI
@galdayan Very fair question. You are right Python+Temporal gets you retries, replay, versioning and "governable" and "diffable" don't require new syntax. I personally think having a clear separation between app logic and LLM/AI Logic is important and understated.
What it buys:
Static analyzability. A Python workflow can import/call/branch on anything — no bounded surface to review, no way to know "this calls these tools, runs these guards, pauses for these approvals" without executing it. The DSL is constrained enough to parse a workflow and extract that graph statically. That's what makes governance tractable; in Python you're doing AST analysis or trusting conventions.
Enforced separation. "Put workflows in a separate file" works until someone imports a service or inlines a prompt. The DSL physically can't reach into your app. That's the feature for teams where AI logic metastasized across services.
Reviewable diffs. A Python PR touches imports, helpers, control flow, and prompt text in one diff. A DSL PR touches workflow logic only — "added a tool call, removed a guard" is a one-line change.
I will concede that for a solo dev or small team in Python, a thin wrapper gets you 80% with zero learning curve. The DSL pays off when reviewers, auditors, and teams need to reason about AI behavior they didn't write.
We are also witnessing teams appearing in enterprises similar to data teams with SQL. Im not sure what the future will be like but these folks need a tool to get to production at the enterprise scale. Things not built into Finyuus yet like SSO/SAML & security are top of mind things.
@marius_ndini the static analyzability point actually lands for me, that's a real gap in a thin Python wrapper, not just a nice-to-have. the SQL-for-workflows framing makes sense too. honestly the SSO/SAML gap you mentioned might matter more than the language question though - that's usually what blocks the first enterprise deal regardless of how good the DSL is underneath. curious if that's already on your near-term roadmap or waiting on demand to justify it.
Mnexium AI
@galdayan The SSO/SAML is something i'd like to build ASAP because it is important for enterprises. There are a lot of features i'd like to build as well (memory is important, chat history etc) really would like to gauge based on usage, I think as soon as one customer says they need SSO i'd like to shift focus toward it b/c it pays dividends once in product.
Temporal, ClickHouse, MinIO, Langfuse and Redis to run a prompt is the part I'd push on. Nobody spins that up on a Tuesday afternoon, and a Tuesday afternoon is how these things actually get adopted. The SQL analogy cuts the other way too, SQL won because it was one language across every engine, and a DSL that runs on exactly one runtime is a lock in people can feel. I'd ship a single binary mode that fakes durability in SQLite so someone can write a workflow in ten minutes and only meet Temporal when they need it.
Mnexium AI
@asadmalik901 Appreciate the comment(s) and you are right on a lot of things.
Infra weight: Fair. make up is one Docker command, not five manual installs, but that's still heavier than pip install langchain. The services exist because how do you then deploy "pip install langchain" for 100s of users? (but their cloud tool? thing about infra etc...). I've attempted to be accessible to the hobbyist whose moving past just running one prompt (a big heavy here but still doable) and to the enterprise running for 100s of people. For the enterprise they can scale to infinity with hosting on ec2 or cloud infra or even going to the SaaS solutions of each of those tools... but you're right that adoption doesn't start at production. People evaluate with one prompt on a Tuesday afternoon, and if that takes 20 minutes of Docker pulling, they never come back.
SQL analogy: agreed - just a good analogy for what i'd like to get to - even if this DSL doesnt win, it be great to have something like it for LLMs. I'm sure the DSL can be improved, ultimately the only option people have right now is a JS/python lib (complex and not designed for it) or a workflow tool (super locked-in and difficult to build production pipelines).
SQLite mode: Genuinely good suggestion, and I've thought about it. Just design considerations and other things took priority.
Voquill
Keeping workflows as plain text instead of locking everything into a visual builder is probably my favorite part. Git diffs and PR reviews are hard to give up once a project grows.
Mnexium AI
@henry_habib Appreciate it - I think we have to many visual builder tools now.
They get hard to productionalize and as complexity grows it gets hard to maintain.