51–60 of 60 posts
This is exactly why I am betting on open source for the AI future. Local first, code I can audit, no black box APIs that change their terms overnight. The future of knowledge work is not locked behind some corporate API with rate limits and price hikes. It is tools like this that keep the user in control.
1. Do you see any downsides to storing your graph as markdown files on filesystem, rather than, say, a graph DB? I have little experience with either but I imagine there would be perf advatages to certain operations on a graph DB at least?
2. If you're using Obsidian-like .md files, why not use the Obsidian format? I bet some folks would love to have an AI coworker helping build and maintain their Obsidian vault.
Nice work. I have two questions. 1. Do you see any downsides to storing your graph as markdown files on filesystem, rather than, say, a graph DB? I have little experience with either but I imagine there would be perf advatages to certain operations on a graph DB at least? 2. If you're using Obsidian-like .md files, why not use the Obsidian format? I bet some folks would love to have an AI coworker helping build and m…
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.
Would this work by just feeding it my obsidian vault?
I've seen a whole heap of graph-based startups start and then pivot or fail because having a graph doesn't seem to add any additional value that a Sqllite or Postgres database offers. That is, saying we have a "context graph" is just marketing speak, it doesn't really add any new possibility or feature that isn't possible from using other search and database tools.
Also, this kind of tool, using AI to extract a decision from Granola for example, is possible to one-shot prompt. I.e. you don't need any special tool to do it, you just need a single prompt. Granola itself has this kind of functionality.
I think you're trying to solve a problem that doesn't really exist, what surface patterns are you going to uncover that someone don't know to look for? Either there is a todo from a meeting or note or email or there isn't.
Writing notes or prep for a meeting isn't rocket science, and you don't need a graph database to "surface patterns" to prepare your pre-meeting notes. If you use something like Granola, 99% of the time (or maybe 100% really), the Granola summary is all you need. If you want something more you copy the whole transcript and send it to Claude for some specific reason.
Since you're a YC company, I assume this will become paid at some point, but why would I pay when just having an AI note-taker and Claude access is already perfect?
The knowledge graph is well done. I think what's missing from all coworking apps is the UX. Prompting is a very specialized skill, average users just don't know what to ask for to get the most out of the LLMs. Ideally the UX should organize and surface information to the user that is important automatically, without needing to be prompted.
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.
Cool idea. I use Logseq with some custom scripts and plugins for that. Works very well with today's models capabilities.
Earlier quoted context omitted.
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.
I'd be happy to meet and discuss. I will reach out.
The weird: the javascript it's supposed to run is included as part of the prompt, for the LLM to write to a file via tool calls.
The naive: "Never actually send emails - only create drafts" yeaah the text generator really doesn't work like that.
https://github.com/rowboatlabs/rowboat/blob/f68887496bcb608e...
https://github.com/rowboatlabs/rowboat/blob/f68887496bcb608e...