the "agent per row" framing is what makes this click for me too. most agent frameworks think in terms of orchestration graphs or message queues, but modeling it as "each row has a little worker that can act on its own state" is a surprisingly intuitive primitive.

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.

ok nice reply. i think i was where you were in 2021 around doing stuff in sprocs. i think pple generally follow a cycle of going overexcited about throwing everything in the database and then going "actually the database is a pretty bad production compute environment" and re-separating concerns back to different levels.

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)