[HN Gopher] Show HN: Sim Studio - Open-Source Agent Workflow GUI
___________________________________________________________________
Show HN: Sim Studio - Open-Source Agent Workflow GUI
Hi HN! We're Emir and Waleed, and we're building Sim Studio
(https://simstudio.ai), an open-source drag and drop UI for
building and managing multi-agent workflows as a directed graph.
You can define how agents interact with each other, use tools, and
handle complex logic like branching, loops, transformations, and
conditional execution. Our repo is
https://github.com/simstudioai/sim, docs are at
https://docs.simstudio.ai/introduction, and we have a demo here:
https://youtu.be/JlCktXTY8sE?si=uBAf0x-EKxZmT9w4 Building
reliable, multi-step agent systems with current frameworks often
gets complicated fast. In OpenAI's 'practical guide to building
agents', they claim that the non-declarative approach and single
multi-step agents are the best path forward, but from experience
and experimentation, we disagree. Debugging these implicit flows
across multiple agent calls and tool uses is painful, and iterating
on the logic or prompts becomes slow. We built Sim Studio because
we believe defining the workflow explicitly and visually is the key
to building more reliable and maintainable agentic applications. In
Sim Studio, you design the entire architecture, comprising of agent
blocks that have system prompts, a variety of models (hosted and
local via ollama), tools with granular tool use control, and
structured output. We have plenty of pre-built integrations that
you can use as standalone blocks or as tools for your agents. The
nodes are all connected with if/else conditional blocks, llm-based
routing, loops, and branching logic for specialized agents. Also,
the visual graph isn't just for prototyping and _is_ actually
executable. You can run simulations of the workflows 1, 10, 100
times to see how modifying any small system prompt change,
underlying model, or tool call change change impacts the overall
performance of the workflow. You can trigger the workflows
manually, deploy as an API and interact via HTTP, or schedule the
workflows to run periodically. They can also be set up to trigger
on incoming webhooks and deployed as standalone chat instances that
can be password or domain-protected. We have granular trace spans,
logs, and observability built-in so you can easily compare and
contrast performance across different model providers and tools.
All of these things enable a tighter feedback loop and
significantly faster iteration. So far, users have built deep
research agents to detect application fraud, chatbots to interface
with their internal HR documentation, and agents to automate
communication between manufacturing facilities. Sim Studio is
Apache 2.0 licensed, and fully open source. We're excited about
bringing a visual, workflow-centric approach to agent development.
We think it makes building robust, complex agentic workflows far
more accessible and reliable. We'd love to hear the HN community's
thoughts!
Author : waleedlatif1
Score : 105 points
Date : 2025-04-28 16:14 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gavmor wrote:
| I'm sure that the complex logic and state management were not
| trivial to implement, but the link said GUI so I wanted to see
| some screenshots, but all I saw were two very dim simple forms.
|
| This space is REALLY struggling to graduate from Gradio-like
| design sensibilities.
|
| That being said, I'm looking forward to playing with this,
| congrats on the launch!
| rancar2 wrote:
| The screenshot on the website are helpful, and it would be good
| to add them into the GitHub documentation as the OP mentioned.
| waleedlatif1 wrote:
| thanks for the feedback! adding some screenshots to the docs
| showcasing more complex workflows we've created so far
| nico wrote:
| The video linked in the post description shows everything
| pretty clearly, here:
| https://www.youtube.com/watch?v=JlCktXTY8sE
| ddon wrote:
| Would be amazing to be able to design the workflow using your
| builder, and then export to code (and choose the language) and
| then copy paste the code into the project... just an idea.
| waleedlatif1 wrote:
| this is something we've been looking into. curious, would you
| rather export the code into an existing agentic framework like
| crewai/langgraph, or have it exported as raw code? also, would
| you prefer if the code was exported block-by-block or the
| entire workflow altogether?
| frabonacci wrote:
| This could play very well with building a managed agentic system
| around computer-use for RPA. Great stuff!
| waleedlatif1 wrote:
| we have support for browser agents (browser-use and stagehand),
| but running this locally with computer use agents would change
| the game. will explore :)
| nico wrote:
| Can the browser agents use my already running browser? It
| would be nice to automate some light workflows in platforms
| that require login, especially the ones that make it hard to
| use headless browsers
|
| Right now my solution is to build extensions that I can
| manually start on my browser. But using extensions to gather
| and export data + maintaining them is a bit of a pain
| waleedlatif1 wrote:
| yeah! for stagehand, I actually stitched together a way for
| you to login and authenticate on platforms without the
| LLM's ever seeing your login credentials. in the prompt,
| you can specify the username as %username% and provide the
| credentials right below, and then we use selectors to enter
| that value into the DOM and hand it back to the agent once
| the login is completed. you can also get structured output.
| afaik, stagehand themselves don't even offer these three in
| their SDK and there's no way to login without giving the
| LLM your credentials. it isn't the best, but its the only
| place I've seen you can get secure login + agents +
| structured output
| nico wrote:
| Amazing. Can it also use multimodal local LLMs? For
| example, can it pass images to gemma3 running via ollama?
| waleedlatif1 wrote:
| although I haven't experimented with gemma 3 locally,
| with ollama we have instructions in the README, and all
| you need to do is initialize the model, and pull it when
| running sim studio. let me know how it goes!
| simple10 wrote:
| Congrats on the launch! Looking forward to playing with it.
|
| Do you mind elaborating on what differentiates Sim Studio from
| n8n, Flowise, RAGFlow and other open source flow based AI
| automation platforms?
| ekarabeg wrote:
| Thanks! The main difference between Sim Studio and other open-
| source AI agent workflow builders is the level of abstraction
| used when creating agents.
|
| For instance, n8n has a "memory" parameter, which is not an
| inherent parameter of LLMs. You can inject your agent's
| memories into the agent message history (or system prompt) -
| which is the most common scenario - but we give you control
| over that. We want to provide visibility, so everything that's
| exposed on the workflow canvas is exactly what's being executed
| in the background. Also, we think it's faster and more
| intuitive to get your workflow up and running in Sim Studio.
| I'd love your feedback, though! What do you think?
| all2 wrote:
| This sounds like execution/variable resolution scopes in
| programming languages. I wonder if there are ideas from
| programming languages you could pick up and use?
| ekarabeg wrote:
| Yes exactly! A lot of our platform was inspired by
| programming languages - for loops, for each loops, custom
| variables, and environment variables in settings. If you
| have any more concepts, we'd love to hear them!
| monatron wrote:
| Hi y'all. Love the idea and congratulations on your launch. I've
| used [n8n](https://github.com/n8n-io/n8n) for similar use cases
| in the past. Any differences in Sim Studio that you'd like to
| call out?
| ekarabeg wrote:
| Thank you! n8n has done really well over the last few years to
| simplify the workflow building process. I responded to this in
| a previous comment, but we believe the agent building process
| should be more open, meaning fewer abstractions between the
| interface and the model provider. We want our platform to be as
| lightweight as possible.
|
| How this translates in the application is through features like
| allowing for custom tool calling with code execution, JSON
| schema input for response format, etc. I'd love to hear your
| thoughts using Sim Studio - let us know how we compare to the
| other workflow builders!
| skeeter2020 wrote:
| > Building reliable, multi-step agent systems with current
| frameworks often gets complicated fast.
|
| In my experience so far it's not just complicated, but
| effectively impossible. I struggle to get a single agent to
| reliably & consistently use tools, and adding n+1 agents is a
| error multiplier.
| waleedlatif1 wrote:
| on our platform (for the providers that allow granular tool use
| control), you can actually 'force' certain tool calls and have
| the agent dynamically select others. this was a painpoint that
| we faced ourselves and were confused why any frameworks didn't
| allow granular tool use control if the provider allows it. try
| it out and let us know what you think
| joshcsimmons wrote:
| Congrats on the launch the tool looks phenomenal.
|
| I'm conflicted because n8n does feel like the right level of
| abstraction but the UI and dated JS runtime environment are
| horrible. I don't really want to write my own memory
| functionality for my AI agents but wondering if it's worth it
| just to have a nicer UI and more modern JS env.
| waleedlatif1 wrote:
| for ease of use, we are exploring a way to add in short-term
| and medium-term memory out of the box in a way that doesn't
| require us to inject anything into the agent's context unless
| the user explicitly wants to. for longer-term memory, we
| support popular vector DB's like pinecone and integrations with
| mem0
| gitroom wrote:
| This is pretty sick, I love having that much control without
| having to hack around a bunch of stuff.
| waleedlatif1 wrote:
| thank you and exactly! that's why we built it. trigger it many
| different ways, swap out tools, models, etc. Just focus on the
| things that matter for agent performance and ignore everything
| else
| neil_s wrote:
| Much simpler UI than n8n, congrats on the launch!
| waleedlatif1 wrote:
| thanks!
| artem_zin wrote:
| Youtube demo looks intriguing, I'm self-hosting n8n for exact
| this purpose with a home run LLM machine in a local k8s cluster
| (lol) but out of the box I can tell your tool surpasses AI
| integrations and workflow in n8n.
|
| Quick glance at GitHub suggests that GitHub package for the
| Docker image is missing, let me know if you need help with that
| -- happy to contribute!
| waleedlatif1 wrote:
| thanks! that would be awesome to have, always welcome
| contributors :)
| vseplet wrote:
| It's funny, but I solved a similar problem myself, but instead
| of n8n I came to write my own solution. I even noticed this
| post thanks to automation and llm. Likewise, I'll be glad to
| help!
| deshraj wrote:
| Congratulations, Emir and Waleed! This is exactly the kind of OSS
| tooling I've been waiting for. I've spent countless hours
| wrestling with multi-step agent workflows hidden inside
| monolithic prompts, and every iteration felt like shooting in the
| dark. Having a drag-and-drop, executable graph with built-in
| branching, loops, and observability is a game-changer.
| waleedlatif1 wrote:
| thank you! check out the mem0 integration and let us know if
| you like the form factor. excited for you to check out the
| platform and let us know if it helps you wrangle those multi-
| step agent workflows.
| dr_kiszonka wrote:
| It looks very nice. What happens when a flow that takes 1 minute
| to complete is triggered by three different Slack messages from
| different users one second apart. Are flow executions queued or
| executed in parallel? Is it configurable?
| waleedlatif1 wrote:
| thanks! this would actually trigger three separate workflow
| executions, and the messages would be processed in parallel by
| each execution. by default, within the workflow all the blocks
| execute once their dependencies are resolved, and for the
| workflow itself they are also executed in parallel. if three
| messages are sent by the same user, it is also executed as
| separate workflow executions. curious to hear about your
| usecase though, are you looking to process the messages in
| batches?
| brene wrote:
| I checked it out and it's quite polished for a workflow builder.
| But I struggled for it to handle lists of content well. But I saw
| that's already an ongoing feature request.
| ekarabeg wrote:
| Thank you! Yes - we are adding variable resolution to the for
| each input. Let us know if there's anything else you'd like to
| see!
| pjpr wrote:
| congrats on the launch!!
___________________________________________________________________
(page generated 2025-04-28 23:00 UTC)