Product Engineer

We build the open-source stack teams use to run coding agents ee repos under  
beads , the work graph that agents and humans share (~26k stars);
gastown (~17k); and gascity , agent orchestration. We’re taking Beads and Gas City to the cloud. The commercial side is Gasworks : the hosted control plane teams use to run agent fleets without babysitting them. If you know our open-source stack, imagine that as the agentic platform for a team or an organization.

Over the last six months we’ve talked to customers, held workshops, and started design partnerships. Now we’re scaling the team and the product toward revenue. You are one of our first engineering hires, and you own the product those customers actually see, touch, and pay for.

(We’re also hiring a Founding Platform Engineer — more infrastructure-oriented — and a Founding Forward Deployed Engineer — more customer-oriented. Exceptional candidates have experience across all of these areas.)

You own large slices of the system, end to end. Not “contribute to.” Own: you pick the approach, you ship it, you operate it, you answer for it.

Beads Team Server. The shared work graph, and the human-facing operating surface around it. A team system: one store, many agents and humans writing concurrently; project and identity boundaries; agent and API access; provisioning; and a view that makes the state legible — what is running, what is blocked, what merged, what changed, and what it cost.

Hosted Gas City. Now do the same for agent orchestration: what’s running, what’s stuck, and how to get more out of each token.

The open-source queue. We are stewards of the OSS repos, and we intend our commercial products to be built on top of the community’s work rather than beside it. You’ll be a maintainer, representing the needs of the community and the compatibility of those needs with our roadmap.

We are a small, flat organization. You work 1:1 with me (Julian, CTO) and with everyone else at the company. We all wear multiple hats and push toward the same goal.

We run our own product on itself. Gas City factories write our design docs, implement them, review the PRs, and drive them to main. Nobody here cares whether a line was typed by you or by an agent — we care about building the processes and frameworks that get us as much leverage as possible while maintaining quality. We learn what works and what doesn’t, and we build those learnings back into the product.

We are factory operators, and the goal is to improve the efficiency of our factory every day.

This is mostly Go, but the job is bigger than a language. You should be comfortable designing and debugging systems where state, concurrency, and failure matter: transactions and migrations, idempotency, retries and fencing, reconciliation loops, process and session lifecycle, and observability. You should be willing to operate what you ship.

There are two natural ways into the work. You might come from the Beads side — storage engines, SQL, Dolt, backups, API contracts. Or from the Gas City side — Kubernetes, controllers, runtimes, scheduling, SRE. You do not need to arrive with both backgrounds, but you do need to be curious about the other half and able to cross the boundary.

The current terrain includes Go, Dolt and SQLite, Kubernetes, gRPC and protobuf, S3/GCS-style object storage, Docker, and Linux process tooling. There is also Rust and Type Script/React around the wider product.

You do not need every item on that list, and we are not hiring for keyword coverage. Deep experience in one of the storage, runtime, or reliability areas is enough if you can follow a problem through code, tests, review, and production. A particular cloud vendor…