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.

1. That's right - Rowboat's agent instructions are currently written in structured prompt blocks, and a lot of logic does live there (with @mentions for tools, other agents, and reusable prompts). We support oAI GPTs at the moment (we chose to start with the oAI Agents SDK), but we're actively working on expanding to other LLMs as well. One of our community contributors just created a fork for Rowboat + OpenRouter. Re: performance, we expect other closed LLMs to perform comparably, and (with good prompt hygiene + role instructions) open LLMs as well, if individual agent scope is kept precise.

2. We've been discussing both A2A and pydantic! Right now, Rowboat is designed to be prompt-first, but we’re integrating more typed interfaces. Design-wise, its likely that prompts might stay central - encoding part of the logic and also acting as the glue layer between more code-based components. Similar to how code has comments, config, and DSLs, agent systems could benefit from human-readable intent even when the core logic is more structured.

Does that make sense?

2. Rowboat agents are technically stateless in that they do not store any messages and state between turns. Our HTTP API [0] requires previous messages and state to be explicitly passed from the previous turn to the next turn. For now, the state is pretty simple - just the name of the last agent that responded to the user. This allows the system to start off directly from where the previous agent left off. The Python SDK [1] manages the state for you. Does that make sense?

[0] API docs - https://docs.rowboatlabs.com/using_the_api/

[1] SDK docs - https://docs.rowboatlabs.com/using_the_sdk/