The best Hacker News stories from Show from the past day
Latest posts:
Rari – Rust-powered React framework
Show HN: Geo Racers – Race from London to Tokyo on a single bus pass
Show HN: Geo Racers – Race from London to Tokyo on a single bus pass
Show HN: Geo Racers – Race from London to Tokyo on a single bus pass
Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB
Hey HN, stripe-no-webhooks is an open-source library that syncs your Stripe payments data to your own Postgres database:
<a href="https://github.com/pretzelai/stripe-no-webhooks" rel="nofollow">https://github.com/pretzelai/stripe-no-webhooks</a>.<p>Here's a demo video: <a href="https://youtu.be/cyEgW7wElcs" rel="nofollow">https://youtu.be/cyEgW7wElcs</a><p>Why is this useful? (1) You don't have to figure out which webhooks you need or write listeners for each one. The library handles all of that. This follows the approach of libraries like dj-stripe in the Django world (<a href="https://dj-stripe.dev/" rel="nofollow">https://dj-stripe.dev/</a>). (2) Stripe's API has a 100 rpm rate limit. If you're checking subscription status frequently or building internal tools, you'll hit it. Querying your own Postgres doesn't have this problem. (3) You can give an AI agent read access to the stripe.* schema to debug payment issues—failed charges, refunds, whatever—without handing over Stripe dashboard access. (4) You can join Stripe data with your own tables for custom analytics, LTV calculations, etc.<p>It creates a webhook endpoint in your Stripe account to forward webhooks to your backend where a webhook listener stores all the data into a new <i>stripe.*</i> schema. You define your plans in TypeScript, run a sync command, and the library takes care of creating Stripe products and prices, handling webhooks, and keeping your database in sync. We also let you backfill your Stripe data for existing accounts.<p>It supports pre-paid usage credits, account wallets and usage-based billing. It also lets you generate a pricing table component that you can customize. You can access the user information using the simple API the library provides:<p><pre><code> billing.subscriptions.get({ userId });
billing.credits.consume({ userId, key: "api_calls", amount: 1 });
billing.usage.record({ userId, key: "ai_model_tokens_input", amount: 4726 });
</code></pre>
Effectively, you don't have to deal with either the Stripe dashboard or the Stripe API/SDK any more if you don't want to. The library gives you a nice abstraction on top of Stripe that should cover ~most subscription payment use-cases.<p>Let's see how it works with a quick example. Say you have a billing plan like Cursor (the IDE) used to have: $20/mo, you get 500 API completions + 2000 tab completions, you can buy additional API credits, and any additional usage is billed as overage.<p>You define your plan in TypeScript:<p><pre><code> {
name: "Pro",
description: "Cursor Pro plan",
price: [{ amount: 2000, currency: "usd", interval: "month" }],
features: {
api_completion: {
pricePerCredit: 1, // 1 cent per unit
trackUsage: true, // Enable usage billing
credits: { allocation: 500 },
displayName: "API Completions",
},
tab_completion: {
credits: { allocation: 2000 },
displayName: "Tab Completions",
},
},
}
</code></pre>
Then on the CLI, you run the `init` command which creates the DB tables + some API handlers. Run `sync` to sync the plans to your Stripe account and create a webhook endpoint. When a subscription is created, the library automatically grants the 500 API completion credits and 2000 tab completion credits to the user. Renewals and up/downgrades are handled sanely.<p>Consume code would look like this:<p><pre><code> await billing.credits.consume({
userId: user.id,
key: "api_completion",
amount: 1,
});
</code></pre>
And if they want to allow manual top-ups by the user:<p><pre><code> await billing.credits.topUp({
userId: user.id,
key: "api_completion",
amount: 500, // buy 500 credits, charges $5.00
});
</code></pre>
Similarly, we have APIs for wallets and usage.<p>This would be a lot of work to implement by yourself on top of Stripe. You need to keep track of all of these entitlements in your own DB and deal with renewals, expiry, ad-hoc grants, etc. It's definitely doable, especially with AI coding, but you'll probably end up building something fragile and hard to maintain.<p>This is just a high-level overview of what the library is capable of. It also supports seat-level credits, monetary wallets (with micro-cent precision), auto top-ups, robust failure recovery, tax collection, invoices, and an out-of-the-box pricing table.<p>I vibe-coded a little toy app for testing: <a href="https://snw-test.vercel.app" rel="nofollow">https://snw-test.vercel.app</a>. There's no validation so feel free to sign up with a dummy email, then subscribe to a plan with a test card: 4242 4242 4242 4242, any future expiry, any 3-digit CVV.<p>Screenshot: <a href="https://imgur.com/a/demo-screenshot-Rh6Ucqx" rel="nofollow">https://imgur.com/a/demo-screenshot-Rh6Ucqx</a><p>Feel free to try it out! If you end up using this library, please report any bugs on the repo. If you're having trouble / want to chat, I'm happy to help - my contact is in my HN profile.
Show HN: Clawe – open-source Trello for agent teams
We recently started to use agents to update some documentation across our codebase on a weekly basis, and everything quickly turned into cron jobs, logs, and terminal output.<p>it worked, but was hard to tell what agents were doing, why something failed, or whether a workflow was actually progressing.<p>We thought it would be more interesting to treat agents as long-lived workers with state and responsibilities and explicit handoffs. Something you can actually see and reason about, instead of just tailing logs.<p>So we built Clawe, a small coordination layer on top of OpenClaw that lets agent workflows run, pause, retry, and hand control back to a human at specific points.<p>This started as an experiment in how agent systems might feel to operate, but we're starting to see real potential for it, especially for content review and maintenance workflows in marketing. Curious what abstractions make sense, what feels unnecessary, and what breaks first.<p>Repo: <a href="https://github.com/getclawe/clawe" rel="nofollow">https://github.com/getclawe/clawe</a>
Show HN: Itsyhome – Control HomeKit from your Mac menu bar (open source)
Hey HN!<p>Nick here – developer of Itsyhome, a menu bar app for macOS that gives you control over your whole HomeKit fleet (and very soon Home Assistant). I run 130+ HomeKit devices at home and the Home app was too heavy for quick adjustments.<p>Full HomeKit support, favourites, hidden items, device groups, pinning of rooms/accessories/groups as separate menu bar items, iCloud sync – all in a native experience and tiny package.<p>Open source (<a href="https://github.com/nickustinov/itsyhome-macos" rel="nofollow">https://github.com/nickustinov/itsyhome-macos</a>) and free to use (there is an optional one-time purchase for a Pro version which includes cameras and automation features).<p>Itsyhome is a Mac Catalyst app because HomeKit requires the iOS SDK, so it runs a headless Catalyst process for HomeKit (and now Home Assistant) access while using a native AppKit plugin over a bridge protocol to provide the actual menu bar UI – since AppKit gives you the real macOS menu bar experience that Catalyst alone can't.<p>It comes with deeplink support, a webhook server, a CLI tool (golang, all open source), a Stream Deck plugin (open source, all accessories supported), and the recent update also includes an SSE event stream (HomeKit and HA) - you can curl -N localhost:8423/events and get a real-time JSON stream of every device state change in your home.<p>Home Assistant version is still in beta – would anyone be willing to test it via TestFlight?<p>Appreciate any feedback and happy to answer any questions.
Show HN: I made paperboat.website, a platform for friends and creativity
Show HN: Agent framework that generates its own topology and evolves at runtime
Hi HN,<p>I’m Vincent from Aden. We spent 4 years building ERP automation for construction (PO/invoice reconciliation). We had real enterprise customers but hit a technical wall: Chatbots aren't for real work. Accountants don't want to chat; they want the ledger reconciled while they sleep. They want services, not tools.<p>Existing agent frameworks (LangChain, AutoGPT) failed in production - brittle, looping, and unable to handle messy data. General Computer Use (GCU) frameworks were even worse. My reflections:<p>1. The "Toy App" Ceiling & GCU Trap
Most frameworks assume synchronous sessions. If the tab closes, state is lost. You can't fit 2 weeks of asynchronous business state into an ephemeral chat session.<p>The GCU hype (agents "looking" at screens) is skeuomorphic. It’s slow (screenshots), expensive (tokens), and fragile (UI changes = crash). It mimics human constraints rather than leveraging machine speed. Real automation should be headless.<p>2. Inversion of Control: OODA > DAGs
Traditional DAGs are deterministic; if a step fails, the program crashes. In the AI era, the Goal is the law, not the Code. We use an OODA loop to manage stochastic behavior:<p>- Observe: Exceptions are observations (FileNotFound = new state), not crashes.<p>- Orient: Adjust strategy based on Memory and - Traits.<p>- Decide: Generate new code at runtime.<p>- Act: Execute.<p>The topology shouldn't be hardcoded; it should emerge from the task's entropy.<p>3. Reliability: The "Synthetic" SLA
You can't guarantee one inference ($k=1$) is correct, but you can guarantee a System of Inference ($k=n$) converges on correctness. Reliability is now a function of compute budget. By wrapping an 80% accurate model in a "Best-of-3" verification loop, we mathematically force the error rate down—trading Latency/Tokens for Certainty.<p>4. Biology & Psychology in Code
"Hard Logic" can't solve "Soft Problems." We map cognition to architectural primitives:
Homeostasis: Solving "Perseveration" (infinite loops) via a "Stress" metric. If an action fails 3x, "neuroplasticity" drops, forcing a strategy shift.
Traits: Personality as a constraint. "High Conscientiousness" increases verification; "High Risk" executes DROP TABLE without asking.<p>For the industry, we need engineers interested in the intersection of biology, psychology, and distributed systems to help us move beyond brittle scripts. It'd be great to have you roasting my codes and sharing feedback.<p>Repo: <a href="https://github.com/adenhq/hive" rel="nofollow">https://github.com/adenhq/hive</a>
Show HN: Agent framework that generates its own topology and evolves at runtime
Hi HN,<p>I’m Vincent from Aden. We spent 4 years building ERP automation for construction (PO/invoice reconciliation). We had real enterprise customers but hit a technical wall: Chatbots aren't for real work. Accountants don't want to chat; they want the ledger reconciled while they sleep. They want services, not tools.<p>Existing agent frameworks (LangChain, AutoGPT) failed in production - brittle, looping, and unable to handle messy data. General Computer Use (GCU) frameworks were even worse. My reflections:<p>1. The "Toy App" Ceiling & GCU Trap
Most frameworks assume synchronous sessions. If the tab closes, state is lost. You can't fit 2 weeks of asynchronous business state into an ephemeral chat session.<p>The GCU hype (agents "looking" at screens) is skeuomorphic. It’s slow (screenshots), expensive (tokens), and fragile (UI changes = crash). It mimics human constraints rather than leveraging machine speed. Real automation should be headless.<p>2. Inversion of Control: OODA > DAGs
Traditional DAGs are deterministic; if a step fails, the program crashes. In the AI era, the Goal is the law, not the Code. We use an OODA loop to manage stochastic behavior:<p>- Observe: Exceptions are observations (FileNotFound = new state), not crashes.<p>- Orient: Adjust strategy based on Memory and - Traits.<p>- Decide: Generate new code at runtime.<p>- Act: Execute.<p>The topology shouldn't be hardcoded; it should emerge from the task's entropy.<p>3. Reliability: The "Synthetic" SLA
You can't guarantee one inference ($k=1$) is correct, but you can guarantee a System of Inference ($k=n$) converges on correctness. Reliability is now a function of compute budget. By wrapping an 80% accurate model in a "Best-of-3" verification loop, we mathematically force the error rate down—trading Latency/Tokens for Certainty.<p>4. Biology & Psychology in Code
"Hard Logic" can't solve "Soft Problems." We map cognition to architectural primitives:
Homeostasis: Solving "Perseveration" (infinite loops) via a "Stress" metric. If an action fails 3x, "neuroplasticity" drops, forcing a strategy shift.
Traits: Personality as a constraint. "High Conscientiousness" increases verification; "High Risk" executes DROP TABLE without asking.<p>For the industry, we need engineers interested in the intersection of biology, psychology, and distributed systems to help us move beyond brittle scripts. It'd be great to have you roasting my codes and sharing feedback.<p>Repo: <a href="https://github.com/adenhq/hive" rel="nofollow">https://github.com/adenhq/hive</a>
Show HN: AI agents play SimCity through a REST API
This is a weekend project that spiraled out of control. I was originally trying to get Claude to play a ROM of the SNES SimCity. I struggled with it and that led me to Micropolis (the open-sourced SimCity engine) and was able to get it to work by bolting on an API.<p>The weekend hack turned into a headless city simulation platform where anyone can get an API key (no signup) and have their AI agent play mayor. The simulation runs the real Micropolis engine inside Cloudflare Durable Objects, one per city. Every city is public and browsable on the site.<p>LLMs are awful at the spatial stuff, which sort of makes it extra fun as you try to control them when they scatter buildings randomly and struggle with power lines and roads. A little like dealing with a toddler.<p>There's a full REST API and an MCP server, so you can point Claude Code or Cursor at it directly. You can usually get agents building in seconds.<p>Website: <a href="https://hallucinatingsplines.com" rel="nofollow">https://hallucinatingsplines.com</a><p>API docs: <a href="https://hallucinatingsplines.com/docs" rel="nofollow">https://hallucinatingsplines.com/docs</a><p>GitHub: <a href="https://github.com/andrewedunn/hallucinating-splines" rel="nofollow">https://github.com/andrewedunn/hallucinating-splines</a><p>Future ideas: Let multiple agents play a single city and see how they step all over each other, or a "conquest mode" where you can earn points and spawn disasters on other cities.
Show HN: AI agents play SimCity through a REST API
This is a weekend project that spiraled out of control. I was originally trying to get Claude to play a ROM of the SNES SimCity. I struggled with it and that led me to Micropolis (the open-sourced SimCity engine) and was able to get it to work by bolting on an API.<p>The weekend hack turned into a headless city simulation platform where anyone can get an API key (no signup) and have their AI agent play mayor. The simulation runs the real Micropolis engine inside Cloudflare Durable Objects, one per city. Every city is public and browsable on the site.<p>LLMs are awful at the spatial stuff, which sort of makes it extra fun as you try to control them when they scatter buildings randomly and struggle with power lines and roads. A little like dealing with a toddler.<p>There's a full REST API and an MCP server, so you can point Claude Code or Cursor at it directly. You can usually get agents building in seconds.<p>Website: <a href="https://hallucinatingsplines.com" rel="nofollow">https://hallucinatingsplines.com</a><p>API docs: <a href="https://hallucinatingsplines.com/docs" rel="nofollow">https://hallucinatingsplines.com/docs</a><p>GitHub: <a href="https://github.com/andrewedunn/hallucinating-splines" rel="nofollow">https://github.com/andrewedunn/hallucinating-splines</a><p>Future ideas: Let multiple agents play a single city and see how they step all over each other, or a "conquest mode" where you can earn points and spawn disasters on other cities.
Show HN: AI agents play SimCity through a REST API
This is a weekend project that spiraled out of control. I was originally trying to get Claude to play a ROM of the SNES SimCity. I struggled with it and that led me to Micropolis (the open-sourced SimCity engine) and was able to get it to work by bolting on an API.<p>The weekend hack turned into a headless city simulation platform where anyone can get an API key (no signup) and have their AI agent play mayor. The simulation runs the real Micropolis engine inside Cloudflare Durable Objects, one per city. Every city is public and browsable on the site.<p>LLMs are awful at the spatial stuff, which sort of makes it extra fun as you try to control them when they scatter buildings randomly and struggle with power lines and roads. A little like dealing with a toddler.<p>There's a full REST API and an MCP server, so you can point Claude Code or Cursor at it directly. You can usually get agents building in seconds.<p>Website: <a href="https://hallucinatingsplines.com" rel="nofollow">https://hallucinatingsplines.com</a><p>API docs: <a href="https://hallucinatingsplines.com/docs" rel="nofollow">https://hallucinatingsplines.com/docs</a><p>GitHub: <a href="https://github.com/andrewedunn/hallucinating-splines" rel="nofollow">https://github.com/andrewedunn/hallucinating-splines</a><p>Future ideas: Let multiple agents play a single city and see how they step all over each other, or a "conquest mode" where you can earn points and spawn disasters on other cities.
Show HN: Distr 2.0 – A year of learning how to ship to customer environments
A year ago, we launched Distr here to help software vendors manage customer deployments remotely. We had agents that pulled updates, a hub with a GUI, and a lot of assumptions about what on-prem deployment needed.<p>It turned out things get messy when your software is running in places you can't simply SSH into.<p>Over the last year, we’ve also helped modernize a lot of home-baked solutions: bash scripts that email when updates fail, Excel sheets nobody trusts to track customer versions, engineers driving to customer sites to fix things in person, debug sessions over email (“can you take a screenshot of the logs and send it to me?”), customers with access to internal AWS or GCP registries because there was no better option, and deployments two major versions behind that nobody wants to touch.<p>We waited a year before making our first breaking change, which led to a major SemVer update—but it was eventually necessary. We needed to completely rewrite how we manage customer organizations. In Distr, we differentiate between vendors and customers. A vendor is typically the author of a software / AI application that wants to distribute it to customers. Previously, we had taken a shortcut where every customer was just a single user who owned a deployment. We’ve now introduced customer organizations. Vendors onboard customer organizations onto the platform, and customers own their internal user management, including RBAC. This change obviously broke our API, and although the migration for our cloud customers was smooth, custom solutions built on top of our APIs needed updates.<p>Other notable features we’ve implemented since our first launch:<p>- An OCI container registry built on an adapted version of <a href="https://github.com/google/go-containerregistry/" rel="nofollow">https://github.com/google/go-containerregistry/</a>, directly embedded into our codebase and served via a separate port from a single Docker image. This allows vendors to distribute Docker images and other OCI artifacts if customers want to self-manage deployments.<p>- License Management to restrict which customers can access which applications or artifact versions. Although “license management” is a broadly used term, the main purpose here is to codify contractual agreements between vendors and customers. In its simplest form, this is time-based access to specific software versions, which vendors can now manage with Distr.<p>- Container logs and metrics you can actually see without SSH access. Internally, we debated whether to use a time-series database or store all logs in Postgres. Although we had to tinker quite a bit with Postgres indexes, it now runs stably.<p>- Secret Management, so database passwords don’t show up in configuration steps or logs.<p>Distr is now used by 200+ vendors, including Fortune 500 companies, across on-prem, GovCloud, AWS, and GCP, spanning health tech, fintech, security, and AI companies. We’ve also started working on our first air-gapped environment.<p>For Distr 3.0, we’re working on native Terraform / OpenTofu and Zarf support to provision and update infrastructure in customers’ cloud accounts and physical environments—empowering vendors to offer BYOC and air-gapped use cases, all from a single platform.<p>Distr is fully open source and self-hostable: <a href="https://github.com/distr-sh/distr" rel="nofollow">https://github.com/distr-sh/distr</a><p>Docs: <a href="https://distr.sh/docs">https://distr.sh/docs</a><p>We’re YC S24. Happy to answer questions about on-prem deployments and would love to hear about your experience with complex customer deployments.
Show HN: Distr 2.0 – A year of learning how to ship to customer environments
A year ago, we launched Distr here to help software vendors manage customer deployments remotely. We had agents that pulled updates, a hub with a GUI, and a lot of assumptions about what on-prem deployment needed.<p>It turned out things get messy when your software is running in places you can't simply SSH into.<p>Over the last year, we’ve also helped modernize a lot of home-baked solutions: bash scripts that email when updates fail, Excel sheets nobody trusts to track customer versions, engineers driving to customer sites to fix things in person, debug sessions over email (“can you take a screenshot of the logs and send it to me?”), customers with access to internal AWS or GCP registries because there was no better option, and deployments two major versions behind that nobody wants to touch.<p>We waited a year before making our first breaking change, which led to a major SemVer update—but it was eventually necessary. We needed to completely rewrite how we manage customer organizations. In Distr, we differentiate between vendors and customers. A vendor is typically the author of a software / AI application that wants to distribute it to customers. Previously, we had taken a shortcut where every customer was just a single user who owned a deployment. We’ve now introduced customer organizations. Vendors onboard customer organizations onto the platform, and customers own their internal user management, including RBAC. This change obviously broke our API, and although the migration for our cloud customers was smooth, custom solutions built on top of our APIs needed updates.<p>Other notable features we’ve implemented since our first launch:<p>- An OCI container registry built on an adapted version of <a href="https://github.com/google/go-containerregistry/" rel="nofollow">https://github.com/google/go-containerregistry/</a>, directly embedded into our codebase and served via a separate port from a single Docker image. This allows vendors to distribute Docker images and other OCI artifacts if customers want to self-manage deployments.<p>- License Management to restrict which customers can access which applications or artifact versions. Although “license management” is a broadly used term, the main purpose here is to codify contractual agreements between vendors and customers. In its simplest form, this is time-based access to specific software versions, which vendors can now manage with Distr.<p>- Container logs and metrics you can actually see without SSH access. Internally, we debated whether to use a time-series database or store all logs in Postgres. Although we had to tinker quite a bit with Postgres indexes, it now runs stably.<p>- Secret Management, so database passwords don’t show up in configuration steps or logs.<p>Distr is now used by 200+ vendors, including Fortune 500 companies, across on-prem, GovCloud, AWS, and GCP, spanning health tech, fintech, security, and AI companies. We’ve also started working on our first air-gapped environment.<p>For Distr 3.0, we’re working on native Terraform / OpenTofu and Zarf support to provision and update infrastructure in customers’ cloud accounts and physical environments—empowering vendors to offer BYOC and air-gapped use cases, all from a single platform.<p>Distr is fully open source and self-hostable: <a href="https://github.com/distr-sh/distr" rel="nofollow">https://github.com/distr-sh/distr</a><p>Docs: <a href="https://distr.sh/docs">https://distr.sh/docs</a><p>We’re YC S24. Happy to answer questions about on-prem deployments and would love to hear about your experience with complex customer deployments.
Show HN: Showboat and Rodney, so agents can demo what they've built
Show HN: JavaScript-first, open-source WYSIWYG DOCX editor
We needed a JS-first WYSIWYG DOCX editor and couldn't find a solid OSS option, most were either commercial or abandoned.<p>As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch.<p>Core text editing works today. Tables and images are functional but still incomplete. MIT licensed.
Show HN: JavaScript-first, open-source WYSIWYG DOCX editor
We needed a JS-first WYSIWYG DOCX editor and couldn't find a solid OSS option, most were either commercial or abandoned.<p>As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch.<p>Core text editing works today. Tables and images are functional but still incomplete. MIT licensed.
Show HN: JavaScript-first, open-source WYSIWYG DOCX editor
We needed a JS-first WYSIWYG DOCX editor and couldn't find a solid OSS option, most were either commercial or abandoned.<p>As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch.<p>Core text editing works today. Tables and images are functional but still incomplete. MIT licensed.
Show HN: Rowboat – AI coworker that turns your work into a knowledge graph (OSS)
Hi HN,<p>AI agents that can run tools on your machine are powerful for knowledge work, but they’re only as useful as the context they have. Rowboat is an open-source, local-first app that turns your work into a living knowledge graph (stored as plain Markdown with backlinks) and uses it to accomplish tasks on your computer.<p>For example, you can say "Build me a deck about our next quarter roadmap." Rowboat pulls priorities and commitments from your graph, loads a presentation skill, and exports a PDF.<p>Our repo is <a href="https://github.com/rowboatlabs/rowboat" rel="nofollow">https://github.com/rowboatlabs/rowboat</a>, and there’s a demo video here: <a href="https://www.youtube.com/watch?v=5AWoGo-L16I" rel="nofollow">https://www.youtube.com/watch?v=5AWoGo-L16I</a><p>Rowboat has two parts:<p>(1) A living context graph: Rowboat connects to sources like Gmail and meeting notes like Granola and Fireflies, extracts decisions, commitments, deadlines, and relationships, and writes them locally as linked and editable Markdown files (Obsidian-style), organized around people, projects, and topics. As new conversations happen (including voice memos), related notes update automatically. If a deadline changes in a standup, it links back to the original commitment and updates it.<p>(2) A local assistant: On top of that graph, Rowboat includes an agent with local shell access and MCP support, so it can use your existing context to actually do work on your machine. It can act on demand or run scheduled background tasks. Example: “Prep me for my meeting with John and create a short voice brief.” It pulls relevant context from your graph and can generate an audio note via an MCP tool like ElevenLabs.<p>Why not just search transcripts? Passing gigabytes of email, docs, and calls directly to an AI agent is slow and lossy. And search only answers the questions you think to ask. A system that accumulates context over time can track decisions, commitments, and relationships across conversations, and surface patterns you didn't know to look for.<p>Rowboat is Apache-2.0 licensed, works with any LLM (including local ones), and stores all data locally as Markdown you can read, edit, or delete at any time.<p>Our previous startup was acquired by Coinbase, where part of my work involved graph neural networks. We're excited to be working with graph-based systems again. Work memory feels like the missing layer for agents.<p>We’d love to hear your thoughts and welcome contributions!