segmenta

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.

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.

Thanks, would love your feedback after trying it.

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.

Thanks! Would love to hear what you think, after you get a chance to try it.

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.

Great, looking forward to it.

Yep - if you just want the assistant to access your Obsidian vault, you can point it to the vault during chat. If you’d like it to show up in the UI as well, or don't want to point to it on every chat, you can copy the vault to a folder under knowledge: ~/.rowboat/knowledge/obsidian-vault.

Thanks!

1. We chose Markdown deliberately so each node is human-readable and editable. The idea is that a project or person note represents the current state of that entity, so you can just open it and understand what’s going on. That also lets users add updates manually, for example from offline conversations that aren’t captured in email or meetings.

In terms of performance, the graph mainly acts as an index over structured notes, and retrieval happens at the note level rather than through complex graph queries. So for our use case, plain files have been sufficient and keep the system simple and transparent.

2. It’s actually Obsidian-compatible. The notes use Obsidian-style backlinks, and you can open the folder directly as an Obsidian vault if you’d like.

Appreciate that. We think having a transparent and fully local option really matters.

That’s great to hear! Would love to hear your feedback once you’ve had a chance to try it.

Thanks! Appreciate it.

This was a really interesting read. Thanks for the detailed breakdown and the office references. The multi-persona approach is interesting, almost like a mixture of experts. The corporate email contradiction use case is not something we had in mind, but I can see how flagging those inconsistencies could be valuable!

Thanks for the kind words. We plan to offer an account-based option for users that want zero setup, with managed integrations and a choice of LLMs.

Thanks, completely agree. UX is probably the hardest part here. Prompting should not be a prerequisite for getting value. We have been thinking about making the system more proactive, for example surfacing relevant notes ahead of meetings or highlighting changes that need attention. Would love to hear how you think this should ideally work.

That’s interesting. Would be curious to know what types of contradictions you were looking at and how you approached flagging them.

Nice, that sounds like an interesting approach. We did try simpler setups first, including giving the model direct access to raw emails and meeting notes. It works to some extent, but it’s harder to maintain a clear notion of “current state” for different entities. Without links, the model also has to do entity resolution at query time, which can require multiple passes.

A design choice we made was that each note should be usable by the user too, not just the AI. For example, if someone opens a project note, they should be able to immediately understand its current status. Linking notes and using backlinks became a natural way to surface relationships and references while keeping things human-readable.

Really appreciate that. Glad the visualizations made sense.

Interesting framing! We’ve mostly been thinking of inconsistencies as signals that something was missed by the system, but treating them as attention points makes sense and could actually help build trust.

The graph building agent processes the raw files (like emails) in a batch. It gets two things: a lightweight index of the entire knowledge graph, and the raw source files for the current batch being processed.

Before each batch, we rebuild an index of all existing entities (people, orgs, projects, topics) including aliases and key metadata. That index plus the batch’s raw content goes into the prompt. The agent also has tool access to read full notes or search for entity mentions in existing knowledge if it needs more detail than what’s in the index.

It’s effectively multi-pass: we process in batches and rebuild the index between batches, so later batches see entities created earlier. That keeps context manageable while still letting the graph converge over time.

We use a two-layer approach.

The raw sync layer (Gmail, calendar, transcripts, etc.) is idempotent and file-based. Each thread, event, or transcript is stored as its own Markdown file keyed by the source ID, and we track sync state to avoid re-ingesting the same item. That layer is append-only and not deduplicated.

Entity consolidation happens in a separate graph-building step. An LLM processes batches of those raw files along with an index of existing entities (people, orgs, projects and their aliases). Instead of relying on string matching, the model decides whether a mention like “Sarah” maps to an existing “Sarah Chen” node or represents a new entity, and then either updates the existing note or creates a new one.

Really appreciate the detailed feedback. There are bunch of great features that you are pointing out that are on our roadmap (will add whats missing). The agent can setup tasks on schedule and help manage them. You can try a prompt like 'Can you schedule a background task xyz to run every morning ...'. The background tasks would show up on the UI once it is scheduled by the assistant. However, you might have to connect the necessary MCP tools in your case.

On Gmail actions - we currently don’t take write actions on inboxes like archiving or categorizing emails. The Google connection is read-only and used purely to build the knowledge graph. We’re working on adding write actions, but we’re being careful about how we implement them. Also probably why the agent was confused and was looking for an MCP to accomplish the same job.

On noise in the knowledge graph — this is something we’re actively tuning. We currently have different note-strictness levels that auto-inferred based on the inbox volume (configurable in ~/.rowboat/config/note-creation.json) that control what qualifies as a new node. Higher strictness prevents most emails from creating new entities and instead only updates existing ones. That said, this needs to be surfaced in the product and better calibrated. Using “people I send emails to” as a proxy for importance is a really good idea.

Good question. We don’t pass the entire graph into the model. The graph acts as an index over structured notes. The assistant retrieves only the relevant notes by following the graph. That keeps context size bounded and avoids dumping raw history into the model.

For contradictory or stale information, since these are based on emails and conversations, we use the timestamp of the conversation to determine the latest information when updating the corresponding note. The agent operates on that current state.

That said, handling contradictions more explicitly is something we’re thinking about. For example, flagging conflicting updates for the user to manually review and resolve. Appreciate you raising it.

Graphiti is primarily focused on extracting and organizing structured facts into a knowledge graph. Rowboat is more focused on day-to-day work. We organize the graph around people, projects, organizations, and topics.

One design choice we made was to make each node human-readable and editable. For example, a project note contains a clear summary of its current state derived from conversations and tasks across tools like Gmail or Granola. It’s stored as plain Markdown with Obsidian-style backlinks so the user can read, understand, and edit it directly.

Thanks. Obsidian and Logseq were definitely an inspiration while building this. What we’re trying to explore is pushing that a bit further. Instead of manually curating the graph and then querying it, the system continuously updates the graph as work happens and lets the agent operate directly on that structure.

Would love to know what kind of scripts or plugins you’re using in Logseq, and what you’re primarily using it for.

Thanks! Agent capabilities are getting commoditized fast. The differentiator is context. If you had a human assistant, you'd want them sitting in on all your meetings and reading your emails before they could actually be useful. That's what we're trying to build.

Thanks!

All the knowledge is stored in Markdown files on disk. You can edit them through the Rowboat UI (including the backlinks) or any editor of your choice. You can use the built in AI to edit it as well.

On background tasks - there is an assistant-skill that lets it schedule and manage background tasks. For now, background tasks cannot execute shell-commands on the system. They can execute built-in file handling tools and MCP tools if connected. We are adding an approval system for background tasks as well.

There are three types of schedules - (a) cron, (b) schedule in a window (run every morning at-most once between 8-10am), (b) run once at x-time. There is also a manual enable/disable (kill switch) on the UI.

That’s great to know. I’ve come to the same conclusion. I’ve found that things work best when they happen right where I’m already working. Uploading files or recreating context in a web service adds friction, especially when everything is already available locally.

Ah, that makes sense. I’ve had similar luck with UI refactoring on cheaper models, mainly because you can quickly verify whether the output is right.

Came across this interesting article on the internals of Claude Code: https://medium.com/@outsightai/peeking-under-the-hood-of-cla... . The author redirected the LLM calls into LiteLLM to analyze how it behaves.