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.
101008 5 hours ago [-]
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?
segmenta 4 hours ago [-]
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 :(
Google used to have news alerts. Have you checked those?
one_d4 4 hours ago [-]
I did that using n8n. Quite easy to setup a workflow that reads an RSS feed. Maybe give it a try.
segmenta 4 hours ago [-]
Would love to know how you find Rowboat for this!
coderinsan 4 hours ago [-]
How are you protecting against Willison's lethal trifecta attacks in agents connected to tools like shown here - https://tramlines.io/blog
warthog 4 hours ago [-]
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
segmenta 4 hours ago [-]
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?
ActionHank 5 hours ago [-]
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?
akhisud 4 hours ago [-]
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.
asdev 5 hours ago [-]
why would I use this over n8n?
akhisud 5 hours ago [-]
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.
nextworddev 5 hours ago [-]
Looks very similar to relevance ai. How should we think about this product’s difference other than oss
akhisud 5 hours ago [-]
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.
KaoruAoiShiho 2 hours ago [-]
Can you give a specific example of something that can't be expressed with a flowchart but can be with rowboat.
segmenta 2 hours ago [-]
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?
zoomzoom 30 minutes ago [-]
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.
segmenta 11 minutes ago [-]
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.
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.
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?
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....
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?
What is the plan if, like Jetbrains have recently experienced, customer usage exceeds the $20?
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.
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...
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.
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?
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?