Interesting, it's not mentioned anywhere in the https://github.com/dbos-inc/dbos-transact-golang README. By contrast, Postgres is mentioned right at the top.

I recommend updating the README to mention SQLite somewhere, with maybe a link to https://docs.dbos.dev/golang/reference/configuration#using-s... ?

Reminds me of the DBOS, everything's a database, ethos. https://www.dbos.dev/

Sounds like you want an orchestration.

Let's assume handoff happens when one "agent" finishes its work on one task, i.e. "submit a PR".

At that point you want to exit the agent/clear context etc (any context the next actor needs should be in the handoff artifact).

And the orchestrator calls the next agent with the artifact.

Claude can do this with subagents. If you want to get more serious, I'd look at "durable workflows" and check out what the pi people have to say: https://earendil-works.github.io/absurd/ https://earendil-works.github.io/absurd/patterns/pi-ai-agent...

you should also look at dbos https://www.dbos.dev/

And then do a search for these terms on HN and get some idea of their shortcomings vs a 'real' orchestration tool like Airflow or Dagster

If you don’t use serverless but instead a few (vertically scaling) servers, and your ORM / query builder supports pooling (all node libraries I’ve used have a pooler)…

Having a setup with just a simple docker deploy, running a monolith, not using pgbouncer so you can use LISTEN/NOTIFY to implement your own job queue:

https://www.dbos.dev/blog/postgres-listen-notify-scalability

This gives me warm fuzzy feelings, also making me relatively cloud-agnostic in the process, even though devops is not my strong point.

Most projects I do don’t need something more complex or vendor locked-in than this.