As I build more and more of my own tooling, I keep running into the same unglamorous part of tool creation: the plumbing. The part that makes software maintain itself, talk to the tools around it, run jobs, and prove that it ran.

It usually shows up in a specific way. I'll make a project for myself, or to share, and test it for a bit, then want to put it in front of people to see if it's useful. The moment I do, I'm in the maintenance cycle: publish to a cloud provider like Vercel, then decide how I'm going to keep it running as a solo developer, or as someone keeping a small piece of software alive for a community. In practice, that means wiring up Cursor automations or cloud workflows, and then I'm stuck inside those ecosystems. Every time, I end up fighting the information architecture of the tools the big model companies are shipping. It feels rushed, and it keeps drifting away from how I actually want to work with the machines around me.

Because what I keep wanting isn't really to task anything. It's for the tools and machines I already use to work together to pass a piece of work between Cursor, a browser, a model, my laptop, a friend's mini, a little box at home without me hand-stitching every handoff, and without losing sight of it along the way. Less dispatching jobs into a black box, more keeping a shared space where I can see what's happening and step in.

The more I sit with that, the less it feels like orchestration and the more it feels like wanting a different relationship with the hardware itself. Something more playful the machines around me as participants I work alongside, the way you'd jam with a set of instruments, rather than compute I delegate to and wait on. Maybe what I'm really reaching for is less a tool and more a small protocol: a way to collaborate with hardware.

That's the distinction underneath all of this. Most of the tools I use today are built around delegation you hand a task off, it goes away, it comes back done (or not). That's useful, but it doesn't feel collaborative; there's no moment when I'm working with anything. What I want is for the work to stay somewhere visible and shared, where I and the next tool, or the next person can pick it up.

So I've started building it from the ground up, as two tools:

  1. Inbox — the shared surface, where I stay in the loop: reviewing and approving the work as it moves.
  2. Relay — the plumbing underneath: the protocol that lets a job find a machine that can run it, hand off to the next, and report back.

Some of what's been bothering me is just naming conventions; some of it is that I need to build more of my own tools. Either way, this is part one of why I'm starting with the plumbing with Relay when I'd usually jump straight to the tool. If the shared ground is right, the more playful, collaborative part can finally sit on top of it.