[solarkraft]

This looks really cool for DIYing workflows, especially since you seem to have a very useful selection of tools!

Did you build your own agent engine? Why not LangGraph?

Say I was building a general agentic chat app with LangGraph in the backend (as it seems to provide a lot of infrastructure for highly reliable and interactive agents, all the way up to a protocol usable by UIs, plus a decent ecosystem, making it very easily extensible). Could I integrate with this for DIY workflows in a high quality fashion (high-precision updates and control)?

Is there a case for switching out LangGraph‘s backend with Sim (can you build agents of the same quality and complexity - I’m thinking coding agent)? Could it interact with LangGraph agents in a high quality way so you can tap that ecosystem?

Can I use Sim workflows with my current agent, say, via MCP?

[waleedlatif1]

1. we wanted to have full control over the agent orchestration and the execution since we didn't like the abstractions that many of the existing frameworks had built, and didn't want to have dependencies in places we didn't need them. so, we built the orchestration and execution engine from scratch, allowing us to do neat things like human in the loop, settings that run the same block 10 times concurrently, etc.

2. this would kind of serve as a drop-in replacement for langgraph. you could build a workflow with an agent and some tools, perhaps some form of memory. then, just deploy that as an API, call it from your frontend, and consume the streamed response on your chat client and without the need to maintain any infra at all.

3. we have a generic code block and an api block used to call APIs for integrations that we may not have, and you can use those to plug (langgraph) agents into the Sim ecosystem.

4. we are adding in the ability to deploy your workflow as an MCP server in the next week, stay tuned :) in the meantime, you can deploy the workflow as an API and have the agent call it as a tool. moreover, you can use the workflow block in sim to call other agents/worklows as well, so its easy to encapsulate a lot of complexity in a `parent` workflow that you call that dynamically routes and uses different tools based on the task at hand

[threecheese]

Their deployment stuff has been turning me off lately; everyone is rushing to monetize - which I understand and support - but I feel like Langsmith is creeping further and further into Langchain|graph and it makes me hesitant to invest. It’s giving AWS-like gentle but firm lock-in vibes, I wonder if they have any PMs from there.

I do like the way they’ve been able to leverage Langgraph workflows to build agents - it seems like the right abstraction to me - and I also feel their middleware approach is very Django-y which I also like. Are you enjoying their stack?

[solarkraft]

I’m only in the research phase of my hypothetical project so far, so I’m going more off of vibes than personal experience for now.

I’m interested in LangGraph because it seems the closest to an industry standard - every use case seems to be addressed with a tutorial (both first and third party) and there’s an ecosystem of already available graphs/agents. I’m aiming for both high extensibility (new use cases should be easily implementable) and high reliability. The LangGraph docs do a pretty good job at convincing me that they got the latter pretty nailed down. It seems like a hard enough problem to question a new solution on this.

I want to build a (highly reliable & controllable) UI for agents more than I want to build the agents themselves, so my hope is that LangGraph has the biggest ecosystem I can plug into.

They do have some funky lock-in attempts, for instance the LangGraph CLI, which acts as a server for their agent protocol (https://github.com/langchain-ai/agent-protocol), is proprietary. However (and this is what I consider indicative of a strong ecosystem) there’s a free reimplementation named Aegra: https://www.aegra.dev/