Hi HN,
Been hacking on a simple way to run agents entirely inside of a Postgres database, "an agent per row".
Things you could build with this: * Your own agent orchestrator * A personal assistant with time travel * (more things I can't think of yet)
Not quite there yet but thought I'd share it in its current state.
This is mind-bending. I can't imagine that it performs well enough to be particularly fit for production just yet but..... wow.
I don't understand why claw is a data type for columns in these examples, it doesn't seem to store any actual per-row state. Is it not possible to hook extensions onto "with" clauses or something similar?
This... does not seem like separation of concerns.
Not to mention that the data layer seems like the one where you want to keep things most deterministic.
Nice. These are the kind of boundary pushing projects I like to see. It challenges assumptions of where application logic should live. The implications around cost, latency, and recovery are going to be interesting.
It feels like we're a week away from the Claw hype supplanting AI hype. Companies will start renaming things ClawX to get on the hype bandwagon.
i love postgres and pgvector... this is exactly to my tastes
this is fucking awesome
We need your help! Can you please use your creativity to build resilience to climate change in your community instead of experimenting with more ways to spend computing power?
What's the advantage in putting agents in the persistence layer rather than the application layer? This seems to me strictly less flexible, scalable, secure, easy to work with... I am having a hard time imagining why I would want to integrate with APIs or write an agentic harness in the database rather than in application code?
Maybe I'm behind the times but I don't understand.