[swyx]

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)

[tibbar]

Oh, like, I wouldn't actually use this specific implementation. I used to work at a shop with thousands of lines of Oracle triggers that you had to edit inline in the web browser with no version control and I shudder to think of returning again.

I'm more interested in the data flow. exa.ai got famous for promising search with massively parallel execution of LLMs on candidate results. In practice, it's never worked that well for me, but the model is very cool and has worked for me e.g. in open source work, searching for bugs across files.

Mapping N items to "N agents with state" feels like an absurdly powerful construct to me. Maybe this is just a well-known pattern that everyone has seen already, but given how much better agents have gotten in the past year, crossing the threshold from "toy" to "arguably superhuman" on many tasks, I think it just hits different.

[swyx]

ok gotcha. yeah i guess my background with temporal.io got me used to "every workflow instance can have a shit ton of long running state that gets persisted and rehydrated at will". check those out if you like N:N+state, whether or not it includes agents is an impl detail

[tibbar]

Haha, I guess we see this in reverse: I see the specific framework as the implementation detail (I use, and enjoy, temporal!) I think it's the part about automatically launching a metric ton of agents that is (to use the term again) mind-bending to me.