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.
How do you build trust in a system like that? The flowchart style have the advantage that you can decide when you want a human to review/approve as well as ensuring actions that need to happen at certain conditions do happen.
Yeah, flowchart style does have that advantage since you can add in approvals and conditions. The tradeoff is you end up limited to simpler logical flows that are easier to verify.
Our take is that trust in agent systems has to be empirical. You start with manual testing and then layer on AI based simulations (we’re adding this in Rowboat soon) to test more scenarios at scale. Splitting work into multiple agents also makes it easier to isolate and test parts separately.
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.
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 :(
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.
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.
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.
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.
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.
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 the high level instruction compiled to a flowchart under the hood? If so maybe a conversational interface is another layer on a flowchart and not an alternative? Overall it makes sense that flowcharts are limiting when they get big, yes. Product looks cool congrats on the launch.
No, the instructions are not compiled into a flowchart under the hood. We use OpenAI’s agent SDK and use handoffs as a mechanism to transfer control between agents.
There are 3 types of agents in Rowboat:
1. Conversational agents are ones which can talk to the user. They can call tools and can choose to handoff control to another agent if needed.
2. Task agents can’t talk to users but can otherwise call tools and do things in a loop - they are internal agents.
3. Pipeline agent is a sequence of task agents (here the transfer of control is deterministic).
For instance, if we build a system for airline customer support, there might be a set of conversational agents each for different high level topics like ticketing, baggage etc. and internally they can use task and pipeline agents as needed.
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.
How do you build trust in a system like that? The flowchart style have the advantage that you can decide when you want a human to review/approve as well as ensuring actions that need to happen at certain conditions do happen.
Yeah, flowchart style does have that advantage since you can add in approvals and conditions. The tradeoff is you end up limited to simpler logical flows that are easier to verify.
Our take is that trust in agent systems has to be empirical. You start with manual testing and then layer on AI based simulations (we’re adding this in Rowboat soon) to test more scenarios at scale. Splitting work into multiple agents also makes it easier to isolate and test parts separately.
How are you protecting against Willison's lethal trifecta attacks in agents connected to tools like shown here - https://tramlines.io/blog
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.
Sorry I don't use Discord :(
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!
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.
Why are you giving this product a theme of a computer game?
You are a business facing startup, act like one.
The current UI[1] made me feel the target market are my elementary school kids.
[1] https://imgur.com/a/NMxz150
Fair point. We went lighter so it didn’t feel heavy/overly enterprise, but I get that it can come off playful. We’ll keep iterating on the design.
it is simple! as long as you don't have a solid, field proven concept for a design, copy stripe.
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?
Is the high level instruction compiled to a flowchart under the hood? If so maybe a conversational interface is another layer on a flowchart and not an alternative? Overall it makes sense that flowcharts are limiting when they get big, yes. Product looks cool congrats on the launch.
Thanks!
No, the instructions are not compiled into a flowchart under the hood. We use OpenAI’s agent SDK and use handoffs as a mechanism to transfer control between agents.
There are 3 types of agents in Rowboat: 1. Conversational agents are ones which can talk to the user. They can call tools and can choose to handoff control to another agent if needed. 2. Task agents can’t talk to users but can otherwise call tools and do things in a loop - they are internal agents. 3. Pipeline agent is a sequence of task agents (here the transfer of control is deterministic).
For instance, if we build a system for airline customer support, there might be a set of conversational agents each for different high level topics like ticketing, baggage etc. and internally they can use task and pipeline agents as needed.
Does this make sense?