Platform 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 everything people will pay us for sits on top of the platform you build and own.

(We’re also hiring a full-stack Founding Engineer — more product-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. Turning Beads from a single-player experience into a platform — one store, many people and agents hitting it at once, scaling from a single developer to teams and organizations.

Hosted Gas City. Today it lives on one machine. The job is making the same thing true when the machine is in the cloud — polecats in containers, scaling as wide as needed. New scale, new constraints, and the future of agentic development, built by you.

Enterprise table stakes. Billing, permissions, SSO — everything needed to sit side by side with the tools companies already use.

The through-line under all three is reliability. You’ll define our SLOs before customers define them for us: observability, backups, and a security baseline that holds up when the first enterprise asks hard questions — and yes, being paged by your own code.

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.

How we work

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 at home 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 will operate what you ship.

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 storage, runtimes, or reliability is what matters, if you can follow a problem through code, tests, review, and production. A particular cloud vendor and Rust are useful but not prerequisites.

We use coding agents heavily. That is a plus, not a substitute for judgment: we care whether you can verify what an agent produced, find the edge it missed, and say clearly what remains uncertain.

Someone whose merged PRs we may have…