segmenta

Ah, that’s interesting. Are there any parts of Claude Code that you feel could work differently or get in your way for these kinds of tasks?

Will check out Grok Code Fast - thanks for the pointer. In my experience, coding agents can swing a lot in quality depending on the model’s reasoning power. When the model starts making small but avoidable mistakes, the overhead tends to cancel out the benefit. Curious to see how Grok performs on multi-step coding tasks.

We’ve included the exact agents used in the demo here for reference: https://github.com/rowboatlabs/rowboat/blob/cli/apps/cli/exa....

We’re adding an easier way to run examples soon. In the meantime, if you’d like to try this one locally: (1) Copy the agent file into ~/.rowboat/agents/ (2) Add the MCP server (and your keys) to ~/.rowboat/config/mcp.json (3) Run: 'rowboatx --agent=tweet-podcast --input=go'

Cline is great, but it’s primarily focused on coding workflows, similar to Claude Code. RowboatX is aimed at a different category: background agents for non-coding automations (e.g. meeting prep, daily briefings, etc).

The big difference from Claude Code (and Cline) is that RowboatX can spin up persistent background agents that run on schedules, use the system shell, and call MCP tools to automate tasks outside of coding.

In the demo - for the voice and music, it uses the ElevenLabs MCP server for TTS, and ffmpeg locally to stitch the audio together. In the demo we pull content from Tweets via an MCP tool, but you can swap that step for anything — for example, fetching your saved articles with curl. There’s no special model required; any LLM that can call tools will work.

Thanks, that makes sense. I assume the CLI approach might be the main hurdle for end users?

Thanks! Curious what kinds of workflows you are automating right now and any pain points you’ve run into.

Fixed the quick start instructions to not start with OpenAI.

Yeah, I think when they made the bet it genuinely made sense. But in coding workflows, once models got cheaper, people did not spend less. They just started packing way more LLM calls into a single turn to handle complex agentic coding steps. That is probably where the math started to break down.

Ah did not realize this - good to know!

For example, the NotebookLM-style podcast generator workflow in our demo uses around 3k tokens end to end. Using Claude Sonnet 4.5’s blended rate (about $4.5 per million tokens for typical input/output mix), you can run this every day for roughly eight months for a bit over three dollars. Most non-coding automations end up in this same low range.

Yep, totally agree. We actually had an earlier web version, and the big learning was that without access to code-related tools the agent feels pretty limited. That pushed us toward a CLI where it can use the full shell and behave more like a real worker.

Really appreciate the support and the Goose pointer. Would love to hear what you think of RowboatX once you try it.

Yep, this is a fair take. Token usage shoots up fast when you do agentic stuff for coding. I too end up doing the same thing.

But for most background automations your might actually run, the token usage is way lower and probably an order of magnitude cheaper than agentic coding. And a lot of these tasks run well on cheaper models or even open-source ones.

So I don't think you are wrong at all. It is just that I believe the expensive token pattern mostly comes from coding-style workloads.

Yes - you can use local LLMs through LiteLLM and Ollama. Would you like us to support anything else?

Context: Posting this after yesterday’s OpenAI visual agent builder announcements. The link is not vendor specific; it isolates one design choice in the visual layer: static flowcharts vs runtime handoffs with full history.

Scope: We are comparing a pure visual flowchart to a handoff model built around one primitive: handoff(agent, history). Each agent takes the full conversation history H, updates it, and decides which agent should act next (or halt). The entire history travels with control, so routing happens dynamically.

Takeaways:

• Topology: flowchart = fixed graph; handoffs = graph generated at runtime from H

• State: flowchart stores state in the diagram; handoffs keep it in the shared data (H)

• Routing cost: flowchart needs explicit branches (many edges or a large router); handoffs keep routing as a small function over H

• Extensibility: flowchart adds edges; handoffs add a function

COI: We built Rowboat around handoffs. The code is open source: https://github.com/rowboatlabs/rowboat

Context: Posting this after today’s OpenAI visual agent builder announcements. The link is not vendor specific; it isolates one design choice in the visual layer: static flowcharts vs runtime handoffs with full history.

Scope: We are comparing a pure visual flowchart to a handoff model built around one primitive: handoff(agent, history).

Each agent takes the full conversation history H, updates it, and decides which agent should act next (or halt). The entire history travels with control, so routing happens dynamically.

Takeaways:

• Topology: flowchart = fixed graph; handoffs = graph generated at runtime from H

• State: flowchart stores state in the diagram; handoffs keep it in the shared data (H)

• Routing cost: flowchart needs explicit branches (many edges or a large router); handoffs keep routing as a small function over H

• Extensibility: flowchart adds edges; handoffs add a function

COI: We built Rowboat around handoffs using OpenAI’s Agents SDK. The code is open source: https://github.com/rowboatlabs/rowboat

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.

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.

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?

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.

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.

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?

Would love to know how you find Rowboat for this!

Ah that is unexpected. Do you mind hopping on our discord: https://discord.com/invite/rxB8pzHxaS - we can debug this for you.

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?

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....

Curious - what was the use case you were trying out?

Agree that the microservices analogy is great for the maintainability aspect of multi-agents. However, there is one more dimension which is specific to LLMs - performance. Smaller agents tend to have better instruction-following accuracy.

Glad you like the mascot! Thanks, curious to learn your feedback once you try it.

Thanks for the pointer. We do agree that not all agentic systems should be multi-agent.

Having said that, from our experience we see that for complex workflows e.g. customer support for enterprises, both quality and maintainability stands to gain when the system is decomposed into smaller scoped agents. We see a parallel of this in humans as well. For instance, when we call into customer support we get routed to different human agents based on our query.

OpenAI says something similar in their recent guide on building agents [0]: "For many complex workflows, splitting up prompts and tools across multiple agents allows for improved performance and scalability. When your agents fail to follow complicated instructions or consistently select incorrect tools, you may need to further divide your system and introduce more distinct agents."

A relevant benchmark here might be the Instruction Following benchmark: https://scale.com/leaderboard/multichallenge. Even the best reasoning models top out at ~60% accuracy on this.

The options to improve accuracy then, are (a) either fine-tune a model on this task specific dataset, (b) or decompose the problem into smaller sub-problems (divide-and-conquer) - this is more practical and maintainable.

[0] https://cdn.openai.com/business-guides-and-resources/a-pract...