Not the same as full spaces, but it gives the same vibe of always having a particular app on a particular hotkey.

I try to limit my multi-tasking though, so I can imagine where full spaces would be useful.

It's really well done, and hilarious.

Originally I had Cloud Scheduler running a heartbeat task every X mins, and the one of the heartbeat tasks was to look for any overdue scheduled tasks and fire them off. So they were not very precise in timing, but a very simple setup.

I made the move to Cloud Tasks so I could heartbeat less often. Now the cleanup happens in the heartbeat - ensure all scheduled tasks have a matching cloud task pending.

Feedback on PRs was an interesting challenge - since we can get it from Slack replies, Github comments, CI failures and we want to be fairly reactive. I ended up leaning on Firestore realtime queries, the harness on the agent VM is subscribed and can interrupt the agentic loop to feed in new feedback as it comes in. All gets very complicated to OSS, but it has helped to get quicker feedback loops going.

I didn't want to be on the hook for supporting an open source version though, so never made it public. Good on you for putting it out there.

A few differences I can quickly spot, fwiw...

I went with Firestore over Postgres for the lower cost, and use Cloud Tasks for "free" deduping of webhooks. Each webhooks is validated, translated, and created as an instant Cloud Task. They get deduped by ID.

We see a lot of value in a scheduler. So running a prompt on a schedule - good for things like status reports, or auto log reading/debug.

I prefer to put my PEMs in to KMS instead of Secret Manager. You can still sign things but without having to expose the actual private key where it can be snooped on.

I run the actual jobs on spot VMs using an image baked by Packer with all the tooling needed. You don't run in to time/resource limits running them as Cloud Run jobs?

Run a copy of this in the same VPC. Monorepos would definitely help, but that's not the structure we have. I didn't want to rely on API limits (or stability) at GitHub for such a core feature.

Using this we've had agents find dead APIs across multiple repos that can be cleaned up and the like. Very useful.

Something very useful that will be harder for you most likely is code search. Having a proper index over hundreds of code repos so the agent can find where code is called from or work out what the user means when they use an acronym or slightly incorrect name.

It's quite nice to use and I'm sure someone will make a strong commercial offering. Good luck

Related: https://ijmacd.github.io/rfc3339-iso8601/

Sometimes you need them all from source to debug across the stack, when you don't you might need a local container to avoid pollution from a test env, sometimes it is just fine to port-forward to a test env and save yourself the local resources.