Maybe I'm behind the times but I don't understand.
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>
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!
it also maps well to how a lot of real world problems actually work: you have N entities, each with their own context, and you want something watching each one independently. the traditional way to do that is a job queue polling the database, but if the database is the compute layer, you skip a whole class of sync/consistency problems.
probably not production ready for anything serious, but i've seen this pattern before where "weird" database experiments end up influencing real tools later. json columns were an antipattern until jsonb became a legitimate design choice. triggers were considered dangerous until supabase made realtime features out of them. the boundary keeps shifting.
use sprocs lightly for simple fast stateless things. every other attempt at stuffing a lot of compute into the database that i'm aware of has basically failed to gain adoption (the personal awesomeness/happiness of the guy who created it aside)
Not to mention that the data layer seems like the one where you want to keep things most deterministic.
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.
My bet is we converge on a super minimal model<>computer architecture.