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've heard that refrain ("we can switch models so we won't be obsolete!") a hundred times, but it doesn't hold any water for me. OpenAI and Anthropic command such a large percentage of LLM usage that it doesn't really matter which one implements your product - either way, you're screwed.
Your end users literally do not care what model you use behind the scenes or if you're using "the right tool for the job".
Just did - asked Claude Opus 4.8 in Claude Desktop to generate an image of a horse. It drew an SVG by hand in code and said (verbatim): "I drew it by hand in code, not with an AI image generator. There's no diffusion/photo image model wired into this session."
On the labs: agreed that end users don't care about the model - only that the job gets done well, which is our argument too. At any point some model is best at a given job, so any single lab is behind for a portion of time on a portion of tasks.
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.
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).
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.
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.
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.
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.
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.
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.