> It's similar to when we wrote all our business logic in eg pl/sql [...]

What do you mean with "when"? /s

I dread companies who still have logic in their databases when it's not necessary. <insert sad face>

I can only speak for my own mind ;) but the most advanced thing I'd seen prior in this regard was Google Sheets' =AI function, which is pretty convenient (if awkward) when you want to map values to LLM output.

What I specifically found "mind-bending" about this is that I don't have a clear concept of the limits of what an agent can do. In the limit case, it's basically like an independent employee, right?. So the concept of having a dedicated person sitting on each row of my database and transactionally performing any task I can describe is ... well, it IS a bit boggling to me.

Another way to look at it is: this is an extremely powerful construct for managing fleets of agents. I trust Postgres to execute all the stored procedures I ask it to. So with this tool I can easily spin up arbitrarily many agents. And state management is very simple, because they can directly edit their associated row!

IDK, the more I think about it the more fascinated I am. I'm sure there is some open source SAAS or something that has similar semantics and can do all this more efficiently, but now I know that this is a category of thing one could potentially build/use. Pretty nifty!

You could replicate and separate your llm-postgres from the system-of-record-postgres.

And IMO that's what should be done.

Don't get me wrong, I like the idea and all that, but this is another pgsql "solution" that is tied to the database layer, when it should be in the application layer.

I like to be database agnostic, and while I prefer PostgreSQL on production, I prefer SQLite on the dev layer. You should never have to HAVE TO use a specific database to make your APPLICATION work.

Is it? pgvector is primarily about indexing, I think? This feels more similar =AI in Google Sheets.

Interesting to hear you say that, I was thinking (but hadn't said) that using WalEx to dispatch to some workers where the agent lived would be a better solution. The worker would then update the row (or more likely insert a new one in a different table with more constraints/different columns). I would be curious to hear what advantage you see in a `claw` type/`agent` column? I can't make heads or tails of it but I regard you as knowing a lot more about Postgres than me.