Jake

Background

Early in my career, I built deployment infrastructure at AWS for large fleets of EC2 instances. I stood up cellular architecture and operational tooling that ran globally. This is where I learned the rigor and risk assessment needed to make large systems observable, recoverable, and safe to change.

Then I moved to Rippling and joined during the growth from Series B to G. I built new products at a fast pace, staying nimble because growth kept stressing early design decisions. I earned a reputation for shipping reliable software quickly across insurance and payroll products. That work led to a fast promotion to staff engineer. The systems I owned stayed stable, I communicated honestly about their state, and the results were measurable. One project I am proudest of: I was the founding engineer for a new payments platform, taking it from zero to production across dozens of countries.

Move fast without breaking things

“Invert, always invert” — Charlie Munger

The systems I work on must not fail. At AWS, an outage would halt thousands of site deployments. In payroll, a failure would mean a missed payment or an unexpected value in a paycheck (that'd be bad news). In response, I built a strong habit of risk assessment, which I describe as “move fast without breaking things.” A startup must move fast. It is existential. The secret is to move fast with discipline, and the crux of that is a simple logical tool. Instead of picturing the happy path of a product, I imagine the worst case failure that could happen. Once I know that failure, I only have to add a few simple guardrails, and the system can move forward without running off a cliff.

I applied this directly to payments infrastructure. Every payment has to be auditable, recoverable, and reconcilable, because the cost of getting it wrong is real money going to the wrong place. Each payment started from a fixed record of intent that set what it was supposed to do before any money moved. Invariants held at runtime, the plainest being that money out of a process can never exceed money in, and observability kept the state of every payment legible. When something fell outside what the code explicitly permitted, the system did not guess. It escalated for human review rather than proceeding, because the person closest to a problem can often resolve a case the system cannot.

The problems I've been solving in payments show up again when you think about AI agents in production: how do you bound what the thing is allowed to do, how do you design escalation paths when it's unsure, how do you enforce invariants at runtime, how do you recover when it goes wrong, how do you keep an audit trail that's actually useful.

I think of agent infrastructure as distributed systems work more than research work. Models are going to be wrong sometimes. What matters is whether the platform around the model can still enforce the properties you care about when that happens.