Rowboat markets itself as "local-first," but if you look in the actual codebase, transcription is Deepgram cloud, voice is ElevenLabs, analytics is PostHog, and the LLM is a cloud API.
I had a hunch that would be the case. I'm always nervous pointing any AI tool at my email, browser, and finances. Any similar solution that's truly local-first?
Not right now but I'm actually exploring this idea space — doing user research —. I would be happy to chat with you – or whoever happens to read this and is into this topic – about that. simone [at] breadboards.io
Local-first for us means: your data such as emails, notes, meetings, the knowledge graph - lives on your machine as plain Markdown, readable and deletable, and the app doesn't require our servers to run. You can also go fully local for the LLM with Ollama or LM Studio. We do special handling there, like suppressing background agents during chat, so local models aren't overwhelmed. That's the core of the product.
Some third-party APIs we couldn't avoid (search has to be an API call). For TTS/STT we deliberately chose cloud quality over local support for now - if there's demand, we'll support local.
On PostHog: usage metadata only, never content. Anonymous install ID unless you sign in to Rowboat; email and plan attached after. Everything sent is cataloged in apps/x/ANALYTICS.md. We shipped v1 with no analytics and were flying little blind on whether anyone used it. If you build without the PostHog env vars, it no-ops entirely.
Instead of having to define what “local-first” means to you personally you should emphasize that the data lives on your local machine. For some example messaging take a look at how Apple is marketing their new Siri AI.
That's fair - "your data lives on your machine as plain files" is the concrete claim, and something we should lead with. Will take a look at how Apple frames it, thanks.
You have completely misused and re-purposed this term. The common interpretation is that the software will continue to function without an internet connection which is not the case for your product.
What I'm looking for right now is a tool like this that lets more than one person participate in the conversation: right now Claude Code and similar tools are great for working alone, but I'd like to effectively pair-prompt with a partner who can see what's happening, and take turns steering the conversation.
Can Rowboat do this? If not, does anybody know a harness that can?
By default conversations are shares in your team (you can also make them private), and the agent has access to them.
So you can do things like "how would $teammate think about this" and the agent will read your colleague's conversations with Amp to get a feel for that and evaluate your work based on that.
Or just figuring out what everyone is doing at the moment is much easier that way
I have a hunch that both OpenAI and Anthropic are building towards this very quickly. It's one of the startup ideas that will be killed overnight when it's "officially" launched. Claude Tag was just released which lets Claude participate in chats in Slack - only a matter of time until they move those chats out of Slack and into their own platform.
That hunch is probably right - the labs are likely building towards this. However, our bet is that in knowledge work the labs don't have a structural advantage: the model isn't the product there, unlike coding where it mostly is - and even in coding, opencode and others are gaining real traction.
What they do have is funding and distribution, but that's the same advantage every incumbent has against every startup.
The single biggest advantage we have is that the labs are tied to their ecosystems. Claude still doesn't have image generation; Gemini-flash-lite is the best cheap model, but Gemini's apps can't use the latest models from Anthropic or OpenAI. We can always use the best tool for each job.
I seem to remember GitHub working on something similar. I remember having seen a video from a conference talk someone at GH gave at an European AI conference a while back. She presented some current prototype/early version they were working in. Where AI was basically like a team member in a chat interface with access to the task boards, issue tickets and also the whole conversation of the team, if I remember correctly.
Also different members of the team could steer/approve what the AI did or did not do.
Not yet, but we're actively working exactly toward this - group chats with the assistant, where people can see the session and take turns steering. We're exploring a peer-to-peer connection for it so there's no server in the middle, which keeps it consistent with the local-first setup.
Have you tried using a purpose built pair programming app? Essentially these are tools with low latency screen sharing and remote control. Then you can pair-prompt in a call.
I built a harness in the cloud with slack like interface for this, allowing multiple people to join. It allows chat members to tag action items, work on files and sync to GitHub. My team uses it to coordinate on our task and teM context together, setup meetings which are auto transcripted and ingested into the attached wiki, and connect to calendar to setup meetings. Built it for our needs.
Didn't really consider putting it out in public. Is there a viable product out of this? How much would you pay.
This isn't exactly what you're looking for but for just the coding part, I am working on https://www.buildautomaton.com to allow multiple people to participate on a shared coding session. It's also bring your own agent subscription, uses ACP to talk to any agent (Cursor, Claude, Codex, etc), and is end-to-end encrypted for most of your IP.
Looks great, but the pricing model is a challenge for a small team. If there was a generous trial period (for testing) with a lower small team price I might be able to consider it, but it’s hard to justify constantly increasing AI and compute costs (already paying for several model subscriptions, existing orchestration tools… in addition to typical infrastructure)
Rather than a single application, is it possible to run a VM and have multiple remote access sharing one login session?
I get that great pains have been made to make sure that doesn't happen by default. But if you really want to co-op on something, why not at the session level on a dedicated VM/login pair?
Today the UI and the server run as a single app. We're working on separating that, so you could technically have one server with multiple clients. But even then, for collaboration with others, there are two issues with sharing a login session: (1) the system doesn't know these are two separate people, and (2) it has access to someone's email etc. - if it doesn't know who the user is, everyone gets the same access and can run anything.
That's why we're exploring a peer-to-peer setup for group chats instead. Each person keeps their own machine and data, and the assistant knows who's who and can ask the primary user for permission if the secondary user wants to run something non-trivial.
You might want to take a look at AionUI. Its a desktop app. I was an early contributor there and they do seem to work on like AI collaborations conversations rather than a single user only chat.
Looks great. Is there an onboarding/xfer workflow from an existing Claude code harness?
I’ve spent a ridiculous amount of time building my wiki, feature plans, retrospectives, client overviews, meta overview, log, skills, commands and the barrier to trying a new command surface or agent is always “will I maintain my edge”.
Or am I misunderstanding? Is it that I would just spawn windows to that existing harness and get to harvest additive features/data from rowboat on top?
Edit - my typical approach would be to scrape out features from a tool like this to bolt onto my harness, why would I not do that here?
You should be able to ask the assistant to copy over your data to its 'knowledge' folder. This is in ~/.rowboat/knowledge - you could copy it over manually too. Now Rowboat should be able to access and update it. If it's under knowledge then it auto-updates with new emails, meetings etc.
Alternately you can point Rowboat directly to your folder by setting workspace in the assistant chat and it should be able to read and use it. It can update it as well, but you would need to explicitly ask it to do so.
I'm happy to onboard you over a call if you'd like (you can DM me on Discord).
That makes sense but I guess the biggest rub for me is… do my existing skills become contradictory or overlapping with what rowboat is doing… I guess I’d want to be able to actually read the skills rowboat employs and marry them with mine so that there’s no double work and there’s an opportunity for rowboats features to be additively beneficial.
Each skill lives in its own subfolder with a skill.ts, and they're registered in the catalog at skills/index.ts.
And we're releasing an update shortly that makes them all readable and editable directly in the app, so merging yours with Rowboat's the way you describe becomes straightforward. Looking forward to the call!
That's fair and you can do that. We built Rowboat with the principle that the whole should be better than the sum of the parts - the email client, notetaker, and surfaces all write back into one knowledge graph, which then improves each of them. So it's much better if you use Rowboat end to end.
Fair - it's Gmail-only today. We've thought about generic IMAP, but it seems to have some technical gaps for how our email surface works. For instance, there's no reliable cross-provider way to pre-create drafts on a thread. So we haven't prioritized it just yet. We do plan to add Outlook support soon.
Thanks for the straight answer, sadly I use neither of those providers. As a suggestion: maybe you could add an option to just disable e-mail integration, for users like me? Right now I'll be getting, "finalize your app setup" vibes... forever.
85%* of small to midsize biz in United States are on Microsoft's office platform, not Google Workspace and Gmail.
starting with indies and SV startups and education is less risky, but the real market outside startup culture is often overlooked by those who came up inside that culture
generic IMAP is not worth the time, first class integration with M365 is worth the time
OIDC flavor "Continue with Microsoft" should be right there beside Continue with Google / Github / Whatever, on every SaaS that wants business clients small enough to make "sign up online" decisions. By contrast, for consumer, Continue with Apple would be the equivalently overlooked OIDC option if you are targeting "wallet share" (a revenue model) instead of headcount (an ad model, for instance).
* Didn't look this up. Used to be. Doesn't matter if 50% or 90%, it's substantial, and point stands: don't overlook it.
Makes a ton of sense, and the framing is correct - it's easy to build for the ecosystem you live in. We plan to add M365 (Outlook) soon. And noted on "Continue with Microsoft" at sign-in.
What I would find lovely is to connect my already existing Thunderbird profile that exists locally. I have 5 email accounts connected and there is no real need to sync them twice on the same machine.
That is a neat idea. We could tap into the locally-synced Thunderbird files for the knowledge graph, which would make ingestion straightforward. We could explore this. The write side - pre-creating drafts on threads, sending etc. still needs the provider work that made us defer IMAP for all email handling.
Fair point. But our goal with Rowboat is to do the opposite, to distill down only the parts you care about. For instance, you are not expected to read meeting notes, the important parts from it are added to your knowledge graph. That way next time you want to know something like 'where are we on x', you can find exactly that without having to wade through irrelevant information to get there.
On productivity: I feel the baseline for productivity has moved up. As a personal anecdote, I had a startup before with 25+ engineers. Now we are a startup of 2 co-founders and a couple of interns, and if I step back, I feel we can produce a surprising amount of stuff. But producing is just the input side, which brings me to 'care'.
On somebody needs to care enough: I meant that AI agents by design have no intrinsic motivations, so (stating the obvious) they do not really care if the product works or actually solves the user's problem. This puts the onus on the human to care for the problem to really solve it, vs just building something. With increased AI output there are too many things to care about which the AI won't, and I believe that's why people might be working more and not less
I think we are talking about the same thing and reaching wildly different conclusions. If "producing is just the input side" and you still need people to check if the product really solves the user's problems, then I get to conclude that the bottleneck has never been the "generating the code" part of the work, and actual productivity - i.e, delivering things that actually solves the customer's problem - is pretty much the same.
I think we agree on the diagnosis: generating code was never the whole bottleneck. Where we differ is the conclusion. Work is implementation plus verification (specing, testing, checking it actually solves the problem). Pre-AI, implementation was so slow that verification hid inside its schedule - you verified while the next thing was being built. AI collapsed implementation time, so verification is now the exposed bottleneck - and the cheapest way teams absorb that today is more human hours. So: output per person is up, hours up too, and the delivered-value gain is real but smaller than the raw output gain suggests. Which I think explains both our observations.
Really interesting, thanks for creating this. I've been slow to adopt the desktop apps (although use the web interface and VS code plugins for all the main players). This might just be the point at which there's a vendor-agnostic option worth investing my effort into setting up.
My question is, can I interact with it over mobile? If I'm away from the desktop, and I want to check-in with it (query the .knowledge, or trigger some coding task etc), is there that option?
Yes! Under settings you can connect your WhatsApp or Telegram and chat with the assistant. It can query your knowledge and trigger coding tasks.
In addition, we have a caffeinate mode (in new release) that keeps your machine awake so the connection doesn't drop. We are also working on a mobile app.
I actually was using this quite a lot earlier this year, thanks for this!
What I actually ended up doing was regularly pointing Claude at the Rowboat directory. Really useful to have all of this context available as markdown files.
I use my own standard format for all context capsules, and had my own branch running with that format hacked in.
Being able to describe the format in a plugin style architecture would be awesome.
Granola notes silently stopped working when they decided to encrypt the DB, interesting to see you've got your own in there now.
We heard of others pointing Claude to the knowledge graph. It made us double down on building a Claude desktop alternative, so we could couple them deeply. For instance, there are places you could provide feedback on emails to Rowboat and that goes into the knowledge graph which then improves the email handling.
Something like this would be hard, if we did not control the assistant as well.
Would love to see your context capsule format. We could definitely make it possible to describe your own format.
Granola no longer working was what led us to build it natively.
Welcome back. Would love your thoughts on the product.
Context Capsules cover business concepts (even org structure), all the way through to implementation. Compounding value from bounded context.
I implemented the Granola Sync when rowboat stopped pulling it in (I have a year's worth of transcripts of pretty much every conversation I've had over the past year).
One shot granola sync in both TypeScript and go from a single Context Capsule:
Nightmare passing markdown files around in this day and age, and yet they are the future. DownKeep is my personal attempt at keeping some sanity, not production!
We're exploring a company brain - team-level context rather than just individual, and the context capsule seems like a great way to distill the individual knowledge graph into team level useful context!
Thanks for the Granola script. Yep, I never imagined markdown would be the killer format.
I'll be watching closely, we're moving this way very quickly. If you get there it'll save me a job!
One thought, the knowledge graph rowboat creates is passive, based on context in emails, transcripts etc. A tool to pull further context from an individual would be amazing. Sit there and chat with it to flush out all of the tribal knowledge (gotchas in this spec).
We have Context Capsules running in production as agent context (amongst other layers of governance) to define metrics etc, so we can guarantee what you see in your dashboard matches exactly what your invoice says, what we're reporting externally, regardless of who is reporting it. Agent or human.
This is a great idea. Almost like an interview mode where the assistant asks pointed questions (using your capsule spec as a guideline) and writes the answers back into the graph.
And thanks for the production context - this is not something we would have come up with. So really helpful data point.
1. cd <myVeryImportantProject.repo>
2. start_AI_agent_REPL
3. "hey AI, analyze the code base in this repo, and find any and all bugs related to 'e.g. porting from 32bit -> 64bit architecture', create work branches for the bug fixes, submit a PR at the repo site for each fix"
4. Goto 3.
I want to be able to treat my AI/ML assistant as a daemon I can turn on and off for any repo - I do not want it to be running all the time, I don't want an email interface to it, I don't want it to analyze my system to try to help me, I want it to be treated like any other system service I will enable and disable, per-directory, manually.
Everything else - the desktop app, the in-built browser, the Obsidian note-taking system - is pure noise, and it immediately disqualifies Rowboat from any investment on my part.
Just a simple daemon style approach, with a REPL, an interface to Git, and THAT IS ALL.
There will be a time and place for a whole new radical UI to AI/ML in my personal laboratory - that time is when I get a brand new machine dedicated just to AI/ML and only put things on it that I want to put on it. Not my personal machine, not my development machine - a machine that will only function as a junior AI/ML-based software developer in my team, with an interface to Git that is standard and battle-tested over years and years of actual work - and nothing else.
I know this tool is out there. I continue to swim through the junk to find it, however.
Rowboat is instantly disqualified from my environment by bringing in too many bells and whistles - all of it junk, because I will have to learn to manage it all anew, and that is not what I want in an AI/ML agent.
Anything which detracts from having AI/ML sandboxed as a daemon and its only interface through the current .git/config for the repo I'm applying it to, is noise and nonsense.
Yes! You can use local models through Ollama and LM Studio. We do some special handling when you use local models, such as suppressing background agents when you chat, so the model is not overwhelmed.
This looks great, but let's see if I have this right ...
The "Agent Apps" (or whatever we are calling them) from the big vendors are organized around projects/folders, and we attach apps (via plugins) to the projects.
This appears to mae the apps (work surfaces) the primary artifact?
Surfaces are the primary artifact for collaborating with the assistant - each one attaches an app to a workflow and gives both you and the agent a structured place to work, instead of everything flowing through chat.
Chat is still first class, and projects/folders exist separately to organize work around it.
I gave this a real shot, but I found it impossible to use the email client. There are basic things like collapsing replies (in a conversation with multiple lawyers no less, damn do they love their email signatures) are extremely important. Without them, it makes scannning and replying to email, even withe aid of AI, impossible.
Really love the whole idea and I hope it gets more usable.
We looked into the specific issue you mentioned. Collapsing replies does exist in the product, but we found it doesn't work for emails sent from Outlook (our guess on why you might have faced this). We are fixing this in the next release, shipping this week. Hope you give it a try.
This is neat, excited to try it. Over the last months I’ve been exclusively using Codex for non-coding tasks. It’s not bad, but there’s much to improve. This seems like a step in the right direction!
There's no app-enforced sandbox today. However, coding tasks get delegated to Claude Code or Codex using ACP.
- Codex runs under its native OS sandbox (Seatbelt on macOS, bubblewrap on Linux) — where it's sandboxed to the selected working directory with network off.
- Claude Code's sandbox is opt-in and we don't enable it yet, but we load your Claude config (~/.claude/settings.json), so if you've enabled sandboxing there it should work.
Surfacing these options in the app UI is a small change on our side, which we'll pick up shortly.
I have a project on very similar lines, https://github.com/brainless/dwata, which I have not been developing for the past few months. I have been meaning to get back to it and I really like what I see on your project page.
My aim is to build a truly local app using only tiny/small models. I have had really good results from Qwen 3.5 1B, 4B, etc. Also, Gliner or similar models for different uses. SQLite + sqlite-vec + Tantivy + a tiny embedding model will stay as my go to.
In my case, coding agent is a separate product. I have https://github.com/brainless/nocodo for that. nocodo is also built for tiny/small models from the ground up. And recently I started building a wGPU based UI framework to build both these apps as native UI apps in Rust: https://github.com/brainless/akar. I also want e2e encrypted team/family sharing in my products.
Thank you for the inspiration. Would love to share notes and follow your progress.
Thank you! And would love to share notes. The tiny-models-only discipline is interesting; we do special handling just to keep local models from being overwhelmed, so I'd like to hear how far you've pushed it. You can find me on Discord, if you want to chat on anything.
Super neat; will test. Initial read suggests the memory accretion continues indefinitely. Asking partially since I am still working on a personal way to deal with that as an issue:
Any plans for a more opinionated way to handle memory ( but still within user's control )?
Update. It has a lot of potential ( and it did get better since I remember it from the original ShowHN ). There are pieces missing, but this may be a project to which I can happily contribute the pieces I think are missing.
You mentioned Claude Code makes drafts. Does rowboat have a terminal area that is fully compatible with claude code? How does claude code then access my emails?
1. True - no OS-level container today. The constraint is approval gating: consequential actions surface as a permission ask before they run (a separate supervisor LLM flags anything outside your intent).
2. True today. We'd deprioritized generic IMAP (drafts-on-thread is unreliable cross-provider), but you're the third person in this thread to raise it, so we'll scope it properly.
3/4/5. Today: Deepgram for STT, ElevenLabs for TTS, Exa for search.
At least for search we supported more providers earlier (e.g. Brave) and found the assistant's skills degrade when they can't lean on provider-specific capabilities, like Exa's granular search. So we trimmed and went deep on a few.
Feel free to raise a GitHub issue with what you want us to support and we'll do our best.
Thank you for addressing my list. I'd like to use it, but requirements on non-local services is a deal breaker for me.
Right now, with my Nanoclaw, I'm running it in a container on a VM on proxmox. If things get bad, I lose a backed up machine and any services it has credentials to.
I can understand why IMAP is a pain. There's plenty of functions that can trash mailboxes. I don't envy you all in this task.
And OpenWhispr is local Whisper model that I also run locally. And still, no data leaks. And since its local, its also FAST. I also use it via HomeAssiatant.
For search, I use SearXNG. Ive even changed my daily driver to it at home, since it gets great results and none of the public cloud forced crap (llm searches when I don't want it).
Thanks for the concrete list! I understand where you are coming from.
Will go through these and see what we could support. If you drop your stack into a GitHub issue, that's the best place for us to work through it (and for others to +1).
Thanks, that's great to hear. Would love to know how it goes once you've tried it - and if anything's missing for your setup, let us know (we are active on Discord).
Rowboat markets itself as "local-first," but if you look in the actual codebase, transcription is Deepgram cloud, voice is ElevenLabs, analytics is PostHog, and the LLM is a cloud API.
I had a hunch that would be the case. I'm always nervous pointing any AI tool at my email, browser, and finances. Any similar solution that's truly local-first?
Not right now but I'm actually exploring this idea space — doing user research —. I would be happy to chat with you – or whoever happens to read this and is into this topic – about that. simone [at] breadboards.io
Local-first for us means: your data such as emails, notes, meetings, the knowledge graph - lives on your machine as plain Markdown, readable and deletable, and the app doesn't require our servers to run. You can also go fully local for the LLM with Ollama or LM Studio. We do special handling there, like suppressing background agents during chat, so local models aren't overwhelmed. That's the core of the product.
Some third-party APIs we couldn't avoid (search has to be an API call). For TTS/STT we deliberately chose cloud quality over local support for now - if there's demand, we'll support local.
On PostHog: usage metadata only, never content. Anonymous install ID unless you sign in to Rowboat; email and plan attached after. Everything sent is cataloged in apps/x/ANALYTICS.md. We shipped v1 with no analytics and were flying little blind on whether anyone used it. If you build without the PostHog env vars, it no-ops entirely.
Instead of having to define what “local-first” means to you personally you should emphasize that the data lives on your local machine. For some example messaging take a look at how Apple is marketing their new Siri AI.
That's fair - "your data lives on your machine as plain files" is the concrete claim, and something we should lead with. Will take a look at how Apple frames it, thanks.
You have completely misused and re-purposed this term. The common interpretation is that the software will continue to function without an internet connection which is not the case for your product.
You should choose different language.
What I'm looking for right now is a tool like this that lets more than one person participate in the conversation: right now Claude Code and similar tools are great for working alone, but I'd like to effectively pair-prompt with a partner who can see what's happening, and take turns steering the conversation.
Can Rowboat do this? If not, does anybody know a harness that can?
Disclaimer: I'm part of the team building it
That's what Amp is built around!
By default conversations are shares in your team (you can also make them private), and the agent has access to them.
So you can do things like "how would $teammate think about this" and the agent will read your colleague's conversations with Amp to get a feel for that and evaluate your work based on that.
Or just figuring out what everyone is doing at the moment is much easier that way
I have a hunch that both OpenAI and Anthropic are building towards this very quickly. It's one of the startup ideas that will be killed overnight when it's "officially" launched. Claude Tag was just released which lets Claude participate in chats in Slack - only a matter of time until they move those chats out of Slack and into their own platform.
That hunch is probably right - the labs are likely building towards this. However, our bet is that in knowledge work the labs don't have a structural advantage: the model isn't the product there, unlike coding where it mostly is - and even in coding, opencode and others are gaining real traction.
What they do have is funding and distribution, but that's the same advantage every incumbent has against every startup.
The single biggest advantage we have is that the labs are tied to their ecosystems. Claude still doesn't have image generation; Gemini-flash-lite is the best cheap model, but Gemini's apps can't use the latest models from Anthropic or OpenAI. We can always use the best tool for each job.
I seem to remember GitHub working on something similar. I remember having seen a video from a conference talk someone at GH gave at an European AI conference a while back. She presented some current prototype/early version they were working in. Where AI was basically like a team member in a chat interface with access to the task boards, issue tickets and also the whole conversation of the team, if I remember correctly.
Also different members of the team could steer/approve what the AI did or did not do.
Ahhh found the talk: https://www.youtube.com/watch?v=ClWD8OEYgp8
Not yet, but we're actively working exactly toward this - group chats with the assistant, where people can see the session and take turns steering. We're exploring a peer-to-peer connection for it so there's no server in the middle, which keeps it consistent with the local-first setup.
Have you tried using a purpose built pair programming app? Essentially these are tools with low latency screen sharing and remote control. Then you can pair-prompt in a call.
I built a harness in the cloud with slack like interface for this, allowing multiple people to join. It allows chat members to tag action items, work on files and sync to GitHub. My team uses it to coordinate on our task and teM context together, setup meetings which are auto transcripted and ingested into the attached wiki, and connect to calendar to setup meetings. Built it for our needs.
Didn't really consider putting it out in public. Is there a viable product out of this? How much would you pay.
This isn't exactly what you're looking for but for just the coding part, I am working on https://www.buildautomaton.com to allow multiple people to participate on a shared coding session. It's also bring your own agent subscription, uses ACP to talk to any agent (Cursor, Claude, Codex, etc), and is end-to-end encrypted for most of your IP.
Looks great, but the pricing model is a challenge for a small team. If there was a generous trial period (for testing) with a lower small team price I might be able to consider it, but it’s hard to justify constantly increasing AI and compute costs (already paying for several model subscriptions, existing orchestration tools… in addition to typical infrastructure)
Thanks for the honest feedback. I'm still playing around with the pricing and trying to get it right.
Rather than a single application, is it possible to run a VM and have multiple remote access sharing one login session?
I get that great pains have been made to make sure that doesn't happen by default. But if you really want to co-op on something, why not at the session level on a dedicated VM/login pair?
Today the UI and the server run as a single app. We're working on separating that, so you could technically have one server with multiple clients. But even then, for collaboration with others, there are two issues with sharing a login session: (1) the system doesn't know these are two separate people, and (2) it has access to someone's email etc. - if it doesn't know who the user is, everyone gets the same access and can run anything.
That's why we're exploring a peer-to-peer setup for group chats instead. Each person keeps their own machine and data, and the assistant knows who's who and can ask the primary user for permission if the secondary user wants to run something non-trivial.
Haven't tried them but there are ways to wire a coding agent to slack, that gives you a multi-user session right there doesn't it?
Or you could use tmux and a shared login and any tui agent harness.
Obviously they would be very flawed but a place to start.
You might want to take a look at AionUI. Its a desktop app. I was an early contributor there and they do seem to work on like AI collaborations conversations rather than a single user only chat.
I use a tool called linzumi for this
...tmux?
Looks great. Is there an onboarding/xfer workflow from an existing Claude code harness?
I’ve spent a ridiculous amount of time building my wiki, feature plans, retrospectives, client overviews, meta overview, log, skills, commands and the barrier to trying a new command surface or agent is always “will I maintain my edge”.
Or am I misunderstanding? Is it that I would just spawn windows to that existing harness and get to harvest additive features/data from rowboat on top?
Edit - my typical approach would be to scrape out features from a tool like this to bolt onto my harness, why would I not do that here?
You should be able to ask the assistant to copy over your data to its 'knowledge' folder. This is in ~/.rowboat/knowledge - you could copy it over manually too. Now Rowboat should be able to access and update it. If it's under knowledge then it auto-updates with new emails, meetings etc.
Alternately you can point Rowboat directly to your folder by setting workspace in the assistant chat and it should be able to read and use it. It can update it as well, but you would need to explicitly ask it to do so.
I'm happy to onboard you over a call if you'd like (you can DM me on Discord).
That makes sense but I guess the biggest rub for me is… do my existing skills become contradictory or overlapping with what rowboat is doing… I guess I’d want to be able to actually read the skills rowboat employs and marry them with mine so that there’s no double work and there’s an opportunity for rowboats features to be additively beneficial.
Will take you up on that! Thank you!
You can read all the built-in skills today in https://github.com/rowboatlabs/rowboat/tree/main/apps/x/pack...
Each skill lives in its own subfolder with a skill.ts, and they're registered in the catalog at skills/index.ts.
And we're releasing an update shortly that makes them all readable and editable directly in the app, so merging yours with Rowboat's the way you describe becomes straightforward. Looking forward to the call!
That's fair and you can do that. We built Rowboat with the principle that the whole should be better than the sum of the parts - the email client, notetaker, and surfaces all write back into one knowledge graph, which then improves each of them. So it's much better if you use Rowboat end to end.
Look really great! I'm a bit sad that the only way to connect to email is gmail. Is a generic IMAP connector on your roadmap?
Thanks!
Fair - it's Gmail-only today. We've thought about generic IMAP, but it seems to have some technical gaps for how our email surface works. For instance, there's no reliable cross-provider way to pre-create drafts on a thread. So we haven't prioritized it just yet. We do plan to add Outlook support soon.
Thanks for the straight answer, sadly I use neither of those providers. As a suggestion: maybe you could add an option to just disable e-mail integration, for users like me? Right now I'll be getting, "finalize your app setup" vibes... forever.
Again, great app - all the best for the future!
That's totally fair. We will try to add a way to disable email if you don't want to connect. Appreciate the kind words!
85%* of small to midsize biz in United States are on Microsoft's office platform, not Google Workspace and Gmail.
starting with indies and SV startups and education is less risky, but the real market outside startup culture is often overlooked by those who came up inside that culture
generic IMAP is not worth the time, first class integration with M365 is worth the time
OIDC flavor "Continue with Microsoft" should be right there beside Continue with Google / Github / Whatever, on every SaaS that wants business clients small enough to make "sign up online" decisions. By contrast, for consumer, Continue with Apple would be the equivalently overlooked OIDC option if you are targeting "wallet share" (a revenue model) instead of headcount (an ad model, for instance).
* Didn't look this up. Used to be. Doesn't matter if 50% or 90%, it's substantial, and point stands: don't overlook it.
Makes a ton of sense, and the framing is correct - it's easy to build for the ecosystem you live in. We plan to add M365 (Outlook) soon. And noted on "Continue with Microsoft" at sign-in.
What I would find lovely is to connect my already existing Thunderbird profile that exists locally. I have 5 email accounts connected and there is no real need to sync them twice on the same machine.
That is a neat idea. We could tap into the locally-synced Thunderbird files for the knowledge graph, which would make ingestion straightforward. We could explore this. The write side - pre-creating drafts on threads, sending etc. still needs the provider work that made us defer IMAP for all email handling.
The growing problem with this and many other AI offerings is the asymmetry of effort.
All of them take my notes, meeting transcripts, jira tickets, code, websites, and give me more to read.
Then everyone else in the org is doing the same, to give me more to read. At the end of the day there is too much to read.
AI is supposed to be reducing toil, but it's just making more.
Fair point. But our goal with Rowboat is to do the opposite, to distill down only the parts you care about. For instance, you are not expected to read meeting notes, the important parts from it are added to your knowledge graph. That way next time you want to know something like 'where are we on x', you can find exactly that without having to wade through irrelevant information to get there.
Have you tried having AI read it for you? /s
The AI should be doing the reading, then deciding what to do, then doing it, right? While you are at the beach, or unemployed. That's what Sam says.
I would like to be on the beach. But seems like people are working more and not less with AI. Somebody needs to care enough.
> But seems like people are working more and not less with AI.
Overall productivity hasn't increased, has it? At best there are cases of increased per productivity due to layoffs, at worst it's just busywork.
> Somebody needs to care enough.
Why?
On productivity: I feel the baseline for productivity has moved up. As a personal anecdote, I had a startup before with 25+ engineers. Now we are a startup of 2 co-founders and a couple of interns, and if I step back, I feel we can produce a surprising amount of stuff. But producing is just the input side, which brings me to 'care'.
On somebody needs to care enough: I meant that AI agents by design have no intrinsic motivations, so (stating the obvious) they do not really care if the product works or actually solves the user's problem. This puts the onus on the human to care for the problem to really solve it, vs just building something. With increased AI output there are too many things to care about which the AI won't, and I believe that's why people might be working more and not less
I think we are talking about the same thing and reaching wildly different conclusions. If "producing is just the input side" and you still need people to check if the product really solves the user's problems, then I get to conclude that the bottleneck has never been the "generating the code" part of the work, and actual productivity - i.e, delivering things that actually solves the customer's problem - is pretty much the same.
I think we agree on the diagnosis: generating code was never the whole bottleneck. Where we differ is the conclusion. Work is implementation plus verification (specing, testing, checking it actually solves the problem). Pre-AI, implementation was so slow that verification hid inside its schedule - you verified while the next thing was being built. AI collapsed implementation time, so verification is now the exposed bottleneck - and the cheapest way teams absorb that today is more human hours. So: output per person is up, hours up too, and the delivered-value gain is real but smaller than the raw output gain suggests. Which I think explains both our observations.
Really interesting, thanks for creating this. I've been slow to adopt the desktop apps (although use the web interface and VS code plugins for all the main players). This might just be the point at which there's a vendor-agnostic option worth investing my effort into setting up.
My question is, can I interact with it over mobile? If I'm away from the desktop, and I want to check-in with it (query the .knowledge, or trigger some coding task etc), is there that option?
Yes! Under settings you can connect your WhatsApp or Telegram and chat with the assistant. It can query your knowledge and trigger coding tasks.
In addition, we have a caffeinate mode (in new release) that keeps your machine awake so the connection doesn't drop. We are also working on a mobile app.
I actually was using this quite a lot earlier this year, thanks for this!
What I actually ended up doing was regularly pointing Claude at the Rowboat directory. Really useful to have all of this context available as markdown files.
I use my own standard format for all context capsules, and had my own branch running with that format hacked in.
Being able to describe the format in a plugin style architecture would be awesome.
Granola notes silently stopped working when they decided to encrypt the DB, interesting to see you've got your own in there now.
Will check it out again.
That is great to know!
We heard of others pointing Claude to the knowledge graph. It made us double down on building a Claude desktop alternative, so we could couple them deeply. For instance, there are places you could provide feedback on emails to Rowboat and that goes into the knowledge graph which then improves the email handling. Something like this would be hard, if we did not control the assistant as well.
Would love to see your context capsule format. We could definitely make it possible to describe your own format.
Granola no longer working was what led us to build it natively.
Welcome back. Would love your thoughts on the product.
The format is:
https://contextcapsules.com/v2/CONTEXT_CAPSULES.md
Context Capsules cover business concepts (even org structure), all the way through to implementation. Compounding value from bounded context.
I implemented the Granola Sync when rowboat stopped pulling it in (I have a year's worth of transcripts of pretty much every conversation I've had over the past year).
One shot granola sync in both TypeScript and go from a single Context Capsule:
https://downkeep.com/sDzvgoKx/granola-sync?k=bJ0JXOTErCt1XVU...
Nightmare passing markdown files around in this day and age, and yet they are the future. DownKeep is my personal attempt at keeping some sanity, not production!
This is brilliant, thanks for sharing!
We're exploring a company brain - team-level context rather than just individual, and the context capsule seems like a great way to distill the individual knowledge graph into team level useful context!
Thanks for the Granola script. Yep, I never imagined markdown would be the killer format.
I'll be watching closely, we're moving this way very quickly. If you get there it'll save me a job!
One thought, the knowledge graph rowboat creates is passive, based on context in emails, transcripts etc. A tool to pull further context from an individual would be amazing. Sit there and chat with it to flush out all of the tribal knowledge (gotchas in this spec).
We have Context Capsules running in production as agent context (amongst other layers of governance) to define metrics etc, so we can guarantee what you see in your dashboard matches exactly what your invoice says, what we're reporting externally, regardless of who is reporting it. Agent or human.
Thanks - would love to have this work for you.
This is a great idea. Almost like an interview mode where the assistant asks pointed questions (using your capsule spec as a guideline) and writes the answers back into the graph.
And thanks for the production context - this is not something we would have come up with. So really helpful data point.
I have a lot of thoughts on this, I should start writing a bit more publicly.
All I want in an AI is this:
1. cd <myVeryImportantProject.repo> 2. start_AI_agent_REPL 3. "hey AI, analyze the code base in this repo, and find any and all bugs related to 'e.g. porting from 32bit -> 64bit architecture', create work branches for the bug fixes, submit a PR at the repo site for each fix" 4. Goto 3.
I want to be able to treat my AI/ML assistant as a daemon I can turn on and off for any repo - I do not want it to be running all the time, I don't want an email interface to it, I don't want it to analyze my system to try to help me, I want it to be treated like any other system service I will enable and disable, per-directory, manually.
Everything else - the desktop app, the in-built browser, the Obsidian note-taking system - is pure noise, and it immediately disqualifies Rowboat from any investment on my part.
Just a simple daemon style approach, with a REPL, an interface to Git, and THAT IS ALL.
There will be a time and place for a whole new radical UI to AI/ML in my personal laboratory - that time is when I get a brand new machine dedicated just to AI/ML and only put things on it that I want to put on it. Not my personal machine, not my development machine - a machine that will only function as a junior AI/ML-based software developer in my team, with an interface to Git that is standard and battle-tested over years and years of actual work - and nothing else.
I know this tool is out there. I continue to swim through the junk to find it, however.
Rowboat is instantly disqualified from my environment by bringing in too many bells and whistles - all of it junk, because I will have to learn to manage it all anew, and that is not what I want in an AI/ML agent.
Anything which detracts from having AI/ML sandboxed as a daemon and its only interface through the current .git/config for the repo I'm applying it to, is noise and nonsense.
This looks really great! Quick question, is there any support for using local models?
Yes! You can use local models through Ollama and LM Studio. We do some special handling when you use local models, such as suppressing background agents when you chat, so the model is not overwhelmed.
sweet, is there any plans to implement VLLM in the future?
vLLM works today - it exposes an OpenAI-compatible endpoint, and you can point Rowboat at a custom base URL in model settings.
This looks great, but let's see if I have this right ...
The "Agent Apps" (or whatever we are calling them) from the big vendors are organized around projects/folders, and we attach apps (via plugins) to the projects.
This appears to mae the apps (work surfaces) the primary artifact?
Yes, that's mostly right.
Surfaces are the primary artifact for collaborating with the assistant - each one attaches an app to a workflow and gives both you and the agent a structured place to work, instead of everything flowing through chat.
Chat is still first class, and projects/folders exist separately to organize work around it.
I gave this a real shot, but I found it impossible to use the email client. There are basic things like collapsing replies (in a conversation with multiple lawyers no less, damn do they love their email signatures) are extremely important. Without them, it makes scannning and replying to email, even withe aid of AI, impossible.
Really love the whole idea and I hope it gets more usable.
Thanks for trying it out and reporting this.
We looked into the specific issue you mentioned. Collapsing replies does exist in the product, but we found it doesn't work for emails sent from Outlook (our guess on why you might have faced this). We are fixing this in the next release, shipping this week. Hope you give it a try.
This is neat, excited to try it. Over the last months I’ve been exclusively using Codex for non-coding tasks. It’s not bad, but there’s much to improve. This seems like a step in the right direction!
Thanks! Would love to hear what you think, after you get a chance to try it.
How does sandboxing work for code?
Is there a way to control the isolation myself, e.g. let it run code only in some VM that I provide?
Edit: is there a sandbox for code?
There's no app-enforced sandbox today. However, coding tasks get delegated to Claude Code or Codex using ACP.
- Codex runs under its native OS sandbox (Seatbelt on macOS, bubblewrap on Linux) — where it's sandboxed to the selected working directory with network off. - Claude Code's sandbox is opt-in and we don't enable it yet, but we load your Claude config (~/.claude/settings.json), so if you've enabled sandboxing there it should work.
Surfacing these options in the app UI is a small change on our side, which we'll pick up shortly.
This looks very close to what I want from AI tools: not just chat, but memory + actual work surfaces around
Thanks, that's exactly the bet. Chat-heavy AI usage seems like a temporary phase.
I have a project on very similar lines, https://github.com/brainless/dwata, which I have not been developing for the past few months. I have been meaning to get back to it and I really like what I see on your project page.
My aim is to build a truly local app using only tiny/small models. I have had really good results from Qwen 3.5 1B, 4B, etc. Also, Gliner or similar models for different uses. SQLite + sqlite-vec + Tantivy + a tiny embedding model will stay as my go to.
In my case, coding agent is a separate product. I have https://github.com/brainless/nocodo for that. nocodo is also built for tiny/small models from the ground up. And recently I started building a wGPU based UI framework to build both these apps as native UI apps in Rust: https://github.com/brainless/akar. I also want e2e encrypted team/family sharing in my products.
Thank you for the inspiration. Would love to share notes and follow your progress.
Thank you! And would love to share notes. The tiny-models-only discipline is interesting; we do special handling just to keep local models from being overwhelmed, so I'd like to hear how far you've pushed it. You can find me on Discord, if you want to chat on anything.
Thanks! I will join your Discord server then.
Super neat; will test. Initial read suggests the memory accretion continues indefinitely. Asking partially since I am still working on a personal way to deal with that as an issue:
Any plans for a more opinionated way to handle memory ( but still within user's control )?
edit: syntax
Update. It has a lot of potential ( and it did get better since I remember it from the original ShowHN ). There are pieces missing, but this may be a project to which I can happily contribute the pieces I think are missing.
That's great to hear! Would love your contributions. Please feel free to find us or DM me on Discord if you want to have a quick chat on anything.
You mentioned Claude Code makes drafts. Does rowboat have a terminal area that is fully compatible with claude code? How does claude code then access my emails?
1. No container to constrain a off-the-rails LLM.
2. Doesn't support generic IMAP email.
3. Doesn't accept my STT.
4. Doesn't accept my TTS.
5. Doesn't accept my SearxNG/custom search engine
Fair list:
1. True - no OS-level container today. The constraint is approval gating: consequential actions surface as a permission ask before they run (a separate supervisor LLM flags anything outside your intent). 2. True today. We'd deprioritized generic IMAP (drafts-on-thread is unreliable cross-provider), but you're the third person in this thread to raise it, so we'll scope it properly.
3/4/5. Today: Deepgram for STT, ElevenLabs for TTS, Exa for search.
At least for search we supported more providers earlier (e.g. Brave) and found the assistant's skills degrade when they can't lean on provider-specific capabilities, like Exa's granular search. So we trimmed and went deep on a few.
Feel free to raise a GitHub issue with what you want us to support and we'll do our best.
Thank you for addressing my list. I'd like to use it, but requirements on non-local services is a deal breaker for me.
Right now, with my Nanoclaw, I'm running it in a container on a VM on proxmox. If things get bad, I lose a backed up machine and any services it has credentials to.
I can understand why IMAP is a pain. There's plenty of functions that can trash mailboxes. I don't envy you all in this task.
For my STT and TTS, ones on the HN front page right now: https://ariya.io/2026/03/local-cpu-friendly-high-quality-tts...
And OpenWhispr is local Whisper model that I also run locally. And still, no data leaks. And since its local, its also FAST. I also use it via HomeAssiatant.
For search, I use SearXNG. Ive even changed my daily driver to it at home, since it gets great results and none of the public cloud forced crap (llm searches when I don't want it).
Thanks for the concrete list! I understand where you are coming from.
Will go through these and see what we could support. If you drop your stack into a GitHub issue, that's the best place for us to work through it (and for others to +1).
If I edit or delete a note straight in the vault (outside the app), does the graph re-index it or go stale?
Yes - the files on disk are the source of truth. If you edit a note directly in the vault, Rowboat picks it up.
Really cool, how long did something like this take to build?
This is great!
Thanks!
Does this support using only private LLM instances? Does it integrate with Amazon Bedrock?
You can use both private LLM instances or hosted ones. On private we support Ollama, LM Studio and any OpenAI compatible API.
In hosted, we support: OpenAI, Anthropic, Gemini, OpenRouter, Vercel AI Gateway.
No native Amazon Bedrock support, but you could use OpenRouter or LiteLLM with the Bedrock key and point Rowboat to that today.
Would be more compelling to me if there was native support for Opencode
this is the first harness ive been excited to try in a while. looks pretty feature rich and suits most of my needs.
Thanks, that's great to hear. Would love to know how it goes once you've tried it - and if anything's missing for your setup, let us know (we are active on Discord).
love this. will try this out.
Thanks, would love your feedback after trying it.
Another wrapper . Guys please build something real, AI cost too much $$ to just keep building things that already exist.