Launch HN: Rowboat (YC S24) – Open-source IDE for multi-agent systems
github.comHi HN! We are Arjun, Ramnique, and Akhilesh, the founders of Rowboat (https://www.rowboatlabs.com), an AI-assisted IDE for building and managing multi-agent systems with a copilot. Using Rowboat, you can build both deterministic automation agents (e.g. automatically summarizing emails) and more agentic systems (e.g. a meeting prep assistant or a customer support bot).
Here are some examples:
- Meeting-prep assistant: https://www.youtube.com/watch?v=KZTP4xZM2DY
- Customer support assistant: https://www.youtube.com/watch?v=Xfo-OfgOl8w
- Gmail and Reddit assistant: https://www.youtube.com/watch?v=6r7P4Vlcn2g
Rowboat is open-source (https://github.com/rowboatlabs/rowboat) and has a growing community. We first launched it on Show HN a few months ago (https://news.ycombinator.com/item?id=43763967).
Today we are launching a major update along with a cloud offering. We’ve added built-in tool integrations for 100s of tools like Gmail, Github and Slack, RAG with documents and URLs, and triggers to invoke your assistant based on external events.
Our cloud version includes all the features of the open-source IDE, but runs instantly with no setup or API keys. For launch, we're offering $10 free usage with Gemini models so you can start building right away for free without adding any card details. Paid plans start at $20/month and give you access to additional models (OpenAI, Anthropic, Gemini, with more coming) and higher usage limits.
There’s a growing view that some tasks are better handled by single agents (https://news.ycombinator.com/item?id=45096962), while others benefit from multi-agent systems for higher accuracy ( https://www.anthropic.com/engineering/multi-agent-research-s...). The difference often comes down to scope: a focused task like coding suits a single agent, but juggling multiple domains such as email, Slack, and LinkedIn is better split across agents. Multi-agent systems also help avoid context pollution, since LLMs lose focus when asked to handle unrelated tasks. In addition, cleanly dividing responsibilities makes each agent easier to test, debug, and improve.
However, splitting work into multiple agents and getting their prompts right is challenging. OpenAI and others have published patterns that work well for different scenarios (https://cdn.openai.com/business-guides-and-resources/a-pract...). We’ve added agent abstractions, built on top of OpenAI’s Agents SDK, to support these patterns. These include user-facing agents that can decide to hand off to another agent when needed; task agents that perform internal tasks; and pipelines that deterministically call a sequence of agents.
Rowboat’s copilot (‘Skipper’) is aware of these patterns and has been seeded with tested patterns, such as a manager‑worker setup for a customer support bot, a pipeline for automated document summarization, and multi‑agent workflows for combining web search with RAG. It can:
- Build multi-agent systems from a high-level request and decide how work must be delegated across agents
- Edit agent instructions to make correct tool calls using Composio tools or any connected MCP server
- Observe your playground chat and improve agents based on your tests
We see agentic systems as a spectrum. On one end are deterministic workflows with a few LLM calls. On the other end are fully agentic systems where the LLM makes all control flow decisions - we focus on this end of the spectrum, while still allowing deterministic control where necessary for real-world assistant use cases. We intentionally avoided flowchart-style editors (like n8n) because they become unwieldy when building and maintaining highly agentic systems.
We look forward to hearing your thoughts!
Not sure if this came through in the post, but with Rowboat we’re taking a strong stance: flowchart-style agent builders are useful today, but we believe they won’t scale with how LLMs are evolving.
As models get better at reasoning, you shouldn’t need to manually draw structured paths. It should feel more like onboarding a new teammate - you give high-level goals, and context, and they figure out the details. We don’t give flowcharts to teammates because it’s a lot of overhead to specify everything upfront. We think agentic systems are heading the same way. Flowcharts are helpful in some cases, but not how we’ll build long-lived assistants.
I want to create something that every X hours (could be 6 hours, 8 hours, 12 hours) check if there are news about a certain topic, and if there are and are interesting enough, generate an image, a text, and post it to Instagram.
The second part is done (generating it and posting it), but finding the news is the hardest part, even if I share some RSS feed. Would this help me with my use case or is something completely different?
This is great, and exactly the type of thing we would love folks to build on Rowboat!
Rowboat has tools to search the web, find HN posts, browse Reddit etc, and you can ask the copilot to build an agent to filter posts based on topics - at the granularity that you want. We have time based triggers, so you can have the agent invoked every x hours.
We have a similar prebuilt template you could checkout: https://app.rowboatlabs.com/projects?shared=N2pJTzyTdh-NdwMi....
I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Reddit and it never worked. Got tired after trying for a while :(
Ah that is unexpected. Do you mind hopping on our discord: https://discord.com/invite/rxB8pzHxaS - we can debug this for you.
Google used to have news alerts. Have you checked those?
I did that using n8n. Quite easy to setup a workflow that reads an RSS feed. Maybe give it a try.
Would love to know how you find Rowboat for this!
How are you protecting against Willison's lethal trifecta attacks in agents connected to tools like shown here - https://tramlines.io/blog
What is the core use case here? For example instead of adopting a dedicated customer support chatbot, why should someone build one on Rowboat? As far as I can see, the customisability parameters are not that different
Great question. Rowboat is a non-opinionated agent framework, so you can build support bots but also meeting prep, reporting, repo management, and other daily automations in the same place.
Even for support, it's more flexible: companies are shifting from narrow "customer support" to broader customer experience - not just resolving tickets, but handling onboarding, account health, proactive updates, and escalations across teams. With Rowboat, you can compose cross-functional agents across support, product, and ops. The same system that answers tickets can also trigger workflows, update dashboards, or prep reports.
Does this make sense?
Who is your ideal customer and what could they create?
What is the plan if, like Jetbrains have recently experienced, customer usage exceeds the $20?
Our ideal users are developers and product teams who want to automate everyday workflows for themselves and their users. Examples include meeting prep, daily/weekly reporting, project management, GitHub repo management, and customer support.
Power users treat Rowboat as their daily go-to assistant for a range of different tasks, customizing assistants for themselves and expanding to cover more use cases.
Regarding pricing: If usage exceeds beyond the $20 (starter) plan, we have a $200 (pro) plan that users can upgrade to. Additionally, we will soon be launching pay-as-you-go pricing as well.
why would I use this over n8n?
From our experience, n8n is great for linear workflows and connecting APIs through flowcharts. Rowboat is aimed at building agentic systems (multiple orchestration patterns, autonomous agents coordinating, non-linear decision making).
Those are much harder and time-taking to express and maintain in a flowchart model. Our goal with Rowboat was to make it simple and quick to build and maintain multi-agent assistants. Hence, the copilot is equipped with tools and state-of-art orchestration patterns [1], which allow it to build ready-to-go assistants in minutes from high-level requirements.
[1] https://cdn.openai.com/business-guides-and-resources/a-pract...
To add to this, we strongly believe that a flowchart type builder quickly hits the ceiling on the type of assistants you could build with it. And this has do with the fact that many real world tasks don't have a well defined flow to them. This is especially true if there is a human on the other side like in customer support - something n8n is clearly not meant for.
Looks very similar to relevance ai. How should we think about this product’s difference other than oss
Thanks for the pointer! We briefly checked them out. Looks like they use a flowchart-style canvas - that’s great for certain types of automations.
Rowboat is especially designed for agentic patterns (e.g. manager-worker) which lend more autonomy to agents. Rowboat's copilot is empowered to organize and orchestrate agents flexibly, based on the nature of the assistant.
Can you give a specific example of something that can't be expressed with a flowchart but can be with rowboat.
In theory you could express most things as a flowchart but the complexity of doing that quickly escalates. A customer support bot that goes beyond informational answers might be a good example for something that is hard to express in a flowchart (without exploding complexity), but can be built in Rowboat.
Here is some personal experience: we previously built Coinbase's automated chatbot and we used a flowchart type builder to do that. This was a intent-entity based system that used deep learning models. It started great, but pretty quickly it became a nightmare to manage. To account for the fact that users could ask things out of turn or move across topics every other turn - we added in concepts called jumps - where control could go from one path to another unrelated path of workflow in on hop - which again introduced a lot of maintenance complexity.
The way we see it is that, when we assign a task to another human or a teammate we don't give them a flowchart - we just give them high level instructions. Maybe that should be the standard for building systems with LLMs?
Is this making sense?