Giselle

@nexaios Thanks a lot — really glad it resonated.

On state persistence: each node’s runtime state is stored as an independent data object, so long-running workflows can rehydrate and resume by referencing the latest persisted state for the nodes they need (rather than relying on an in-memory “session”). That makes it easier to checkpoint, inspect, and replay parts of a run as it progresses.

“Cognitive OS + persistent memory + governance” is a super important direction — especially if you want these agents to be usable in real business contexts. Nex Sovereign sounds very relevant.

Giselle is intentionally designed to be pluggable so we can interface with stateful agents/memory layers and governance systems as they emerge. Would love to explore how Giselle workflows could hand off / sync state with Nex Sovereign once you launch. And congrats on the launch!

@nexaios Thanks for the upvote and the kind words! Would love to explore how Giselle and Nex Sovereign could work together. We'll check out your launch!

@nexaios Thanks so much for the support, really appreciate it.

@nexaios san, Thanks so much! Nex Sovereign sounds really impressive – can't wait to see your launch tomorrow! 🚀

@teodor_hascau Exactly, Giselle's core value is making LLM orchestration something humans can easily experiment with and iterate on. Sometimes you want AI to suggest the optimal approach, but ultimately, if humans can't understand it, it's hard to make good decisions. Our plan is to first make it easy to translate human ideas into flows, then layer in AI-powered suggestions.

As for reproducibility, it's a tough problem. We have internal state management, but we haven't yet shipped robust snapshotting or version control features for users. It's a pain point everyone's grappling with, and definitely on our roadmap.

@teodor_hascau san, Thanks for the comment! You nailed it exactly.

On reproducibility, we're planning features like "app version history," "app templates," and "template sharing + community." As for reproducibility of flow execution results—since LLM outputs depend on the model itself, we're not planning to intervene there for now. That said, having an environment where workflows run reliably day after day is something I need myself as a daily Giselle user, so we're definitely working on it.

@teodor_hascau Great question — and yes, that’s absolutely the knife-edge.

Today, Giselle already persists full step-level inputs and outputs for every execution (including intermediate states). The UI for inspecting, diffing, and selectively re-running those steps isn’t fully exposed yet, but it’s very much on the roadmap.

We’re pretty realistic about this part: bit-perfect reproducibility with LLMs is a mirage. Models change, providers evolve, and some entropy is inherent. Rather than pretending we can freeze time, our goal is to make every run legible — so you can see exactly what happened, why it happened, and what changed.

In other words, we may not guarantee “works on every Tuesday,” but we can guarantee you’ll know why it worked last Tuesday and what drifted by Thursday — and give you the tools to course-correct quickly.

Thanks for calling this out. I’ve personally been burned by this class of failure more times than I’d like to admit, and it’s one of the core problems we want to solve for builders trying to tame very energetic LLMs.

@mykyta_semenov_ Thanks! Giselle's workflows can be used for content creation and analytics in tourism and e-commerce. We'd love to explore creating samples and templates for those use cases.

@mykyta_semenov_ san, Thank you!
That's awesome! Please let me know when you launch — I'd love to check it out! And thanks for taking a look at Giselle :)

@mykyta_semenov_ Thank you for sharing. Both tourism and e-commerce are ideal candidates for workflow-driven AI.

If you're interested, we can run it on a private cloud as well as a cloud version. Feel free to share more details or discuss your requirements.

@shawn_park_f12 Thank you so much for your kind words! We've finally launched! 🎉 Please give it a try and let us know what you think!

@shawn_park_f12 Thanks so much! I'm really glad you picked up on that - it's a detail I really worked on. Hoping to add customization features like other editors down the line. Will keep pushing forward with updates!

@shawn_park_f12 Thanks for the early comment — we're live now! FUNCTION12 looks awesome too. Hope you get a chance to try it out!

@syed_hassan9 san, Thank you so much!
I'm really glad it resonates with you. We've built this to handle our own use case—running complex workflows for extended periods—and we believe it's now at a level where others can benefit from it too.
Today marks just the beginning, and we'll keep refining the product from here.

@syed_hassan9 Really appreciate this — means a lot to hear. We'll keep pushing!

@syed_hassan9 Thank you so much. We’ll keep pushing to improve the quality and polish of the product.

@richard_wang18 Great question! Right now, we offer token visibility, but model selection and workflow design are up to the user. We're exploring features where AI could recommend optimal workflows and model choices based on your use case—definitely something we want to build toward.

@richard_wang18 san, Thank you for your comment!
Currently, we don't have intelligent model selection—users choose their preferred model themselves. That said, smart auto-selection and switching sounds like a great idea, so we'll definitely consider adding it. Thanks for the suggestion!

@richard_wang18 Thanks a lot — really appreciate it!

Right now, our “model selection” is intentionally manual. As we’ve been building Giselle, we’ve developed a pretty practical sense of each model’s strengths (quality vs. latency vs. cost, tool-use reliability, long-context behavior, etc.), and we wanted to make it easy for builders to choose the right model per node/workflow step—especially since different parts of a long-running workflow often benefit from different models/providers.

So to answer your question: we don’t have a single routing algorithm in place today that automatically optimizes across cost / speed / cache hits. Giselle focuses on making multi-model orchestration visible and controllable rather than “magic.”

That said, we agree this is a great direction. We’re seeing how popular modes like Cursor’s “Auto” are, and we’re actively considering adding an Auto Mode / model router in the future that could optimize for things like:

- execution cost

- latency / speed

- cache hits / token efficiency

- (and potentially reliability per task type)

If you have a specific workflow in mind (e.g., classify → extract → write → verify), I’d love to hear what signals you’d want the router to prioritize.

@musa_molla Thanks for this. Debuggability and execution transparency being first-class is something we deeply care about too. Beyond open source and real-time visibility, we want to strengthen features like debugging and eval. But first, we're focused on making the experience of experimenting and iterating with AI as smooth as possible. As teams move toward production use, transparency and debugging become even more critical. We're also exploring the ability to expose workflows as APIs, and through that process, we aim to improve stability and transparency further.

@musa_molla san, Thank you! Transparency was our top priority when building Giselle, so I'm glad that resonated with you. We're continuing to improve it for production use. Would love to hear your feedback if you give it a try!

@musa_molla Thanks for the thoughtful take — you’re hitting the core of it. Visual workflows only really become “production-ready” when you can clearly see what ran, why it ran, and exactly where it failed so you can iterate with confidence.

Giselle already keeps the underlying run data, but we don’t yet have a user-facing UI that makes debugging and execution transparency truly first-class. That’s a priority for us next: better run history, step-by-step inspection, and clearer failure points so teams can move from experimentation to shared workflows with trust.

If there are specific debugging views you’ve found most useful (e.g., per-node logs, inputs/outputs diffs, retries), I’d love to hear what you’d want to see.