being opinionated doesn't mean you can attack people you compete or don't like every other week
980 karma · joined June 23, 2011
Making agents multiplayer is mostly a context problem. You could be using ChatGPT or a Slack bot, or a web interface and the agent needs to know you, your conversations in Cowork etc. so it can enable multi channel collaboration with your agents and your colleagues. We're working on it at https://lobu.ai
TUI renderer is the one using the memory heavily so your terminal takes the heavy lifing. If you're managing the buffers and out-of-screen context good enough, Typescript can be pretty efficient.
For such announcement, I would expect them to give me clues on when I should use this model and in which cases it's the best one.
The benchmarks that they share doesn't indicate that it's cheaper to run than other models, or can fit in my local machine, or excels in a specific vertical.
After reading the comments here and X, I can see it being the top-3 multi-modal open-source model though.
That's why we built https://lobu.ai which is a multi-tenant implementation for proactive agents like OpenClaw. It has entity based memory for building the org context layer and every channel/user gets its isolated container.
If you have bunch of files and don't have any structure, yes filesystem is great but the moment when you need consistency & performance (which you need sooner rather than later) use databases.
Investing early doesn't hurt when you build a product that you know will have many writers.
The hard problem is giving a shared agent durable organizational memory and a real isolated environment where it can safely access company systems and perform work. The agents need a durable log of what everybody at the company is doing, prevent data leaks with proper access control and isolate the runtime to give everybody both private & shared space.
It’s also not tied to Claude or Slack. We see Slack as one interface and the models as part of the harness. It's usually better to combine multiple providers to review the work.
I wrote a post arguing that agent loops are becoming the better model. The thing is, a lot of “agent + cron job” setups today are basically doing what traditional SaaS already does — reacting to one event without much broader context. The loop approach only really starts to pull ahead when memory is persistent and shared across different parts of the business.
We use materialized views for append-only timeseries data for https://lobu.ai and the retention policies define how we DROP the tables so we don't DELETE/UPDATE any rows in the tables.
The long term storage is Iceberg on S3 that's ingested via Postgresql replication, suitable for OLAP use-cases. Postgresql only stores the dimensional OLTP data the users can update and the hot append-only event data.
I also tried DuckLake but that required us to move away from PG-first approach. I was thinking of using Debezium to create Iceberg on S3 for our append-only PG tables and use DuckDB. I will try Streambed out as well!
Clickhouse is also great for OLAP for sure
I think if you grow enough to look for these extensions, it's usually better to bet on purpose-specific tooling. For example, I use DuckDB/Iceberg combination extensively for columnar data and connect DuckDB to PG when I need it.
The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.