Work

• Look after the team.
• Say out loud what’s broken.
• Don’t build anything that only works if somebody burns out keeping it running.

I lead engineering teams building the systems that connect people to large fleets of robots, where human–computer interaction, simulation and real-world operations meet.

• 10+ years. Building robotics software and the teams behind it at Amazon Robotics, since 2016.
• 1 → 80 sites. Sort center automation, from the first site to 80 across North America and Europe by 2021.
• 12.5 billion. Packages processed in 2025 by the sortation software and robot fleets I have worked on.

2017–2019 · The first robotic sort center

Pegasus drive units, each carrying a small conveyor deck, took over zip-code sortation at DEN5, the Denver sort center. The job was getting a new kind of floor to run for real: a package onto a drive, the drive to the right chute, and fewer packages sent to the wrong place.

2019–2021 · From thousands of packages to billions

The same system, launched at 80 facilities across North America and Europe, went from sorting thousands of packages to billions. Most of that was the unglamorous part: fleet orchestration that behaves the same at every site, and launch tooling good enough that a new building does not need the people who built the first one.

2022–present · Proteus and the open floor

Proteus is an autonomous mobile robot that works on the open floor, around people, instead of inside a fenced field. That changes what the software has to guarantee. In 2025 the sortation platforms processed 12.5 billion packages.

• Robotics at scale. Software for large-scale robotic and virtual systems, where a design choice is multiplied by every site it ships to.
• Human–computer interaction. Interfaces between operators and autonomy: making complex systems legible to the people who run them.
• Systems architecture. Clear contracts, deterministic behaviour and failure modes you can reason about. The same instincts are behind PhotoVault and Mimir.
• Organizational transformation. Growing teams and changing how they work, including bringing AI-assisted engineering into day-to-day practice.

In the summer of 2015 I interned at WINLAB, the wireless research lab at Rutgers. The project was Cyber-Physical Mario Kart: the game, but with real karts on a real floor.

I led a small team of interns, high-schoolers among them, to the first working prototype. It was the first time I had to make software and machines agree with each other, in front of people, on a deadline. I have been doing some version of that ever since.

Cyber-Physical Mario Kart (video) · WINLAB summer 2015 projects

None of this is original. It is what I keep coming back to after ten years of shipping software that has to work on a real floor, with real people standing next to it.

Look after the team.

Systems are built and kept running by people, and they only stay up while those people can. My first job is that the team has what it needs: context, focus, and a workload somebody could keep up for years. A team that trusts each other will ship more than one that is watched.

Say out loud what’s broken.

A problem you hear about early is cheap. A problem that gets hidden to keep a status report green gets expensive fast. So the job is to make bad news safe to say, to say it myself first, and to treat whoever raises a problem as the person who helped.

Don’t build anything that only works if somebody burns out keeping it running.

Nothing should run on heroics. If a launch needs a hero, the launch plan is wrong. The fix is boring: automate the repeated step, write down the thing only one person knows, and make on-call something a person can do and still sleep.

Build for whoever is on shift.

A robot doesn’t care how elegant the design was, and neither does the person on the floor when it stops. Software for physical places has to be legible to the people operating it: what it is doing, why it stopped, and what to do next.

An honest failure beats a plausible success.

I want systems that stop and say so, not ones that quietly degrade. “It finished” is not the same as “it worked”, so verify the result, keep the behaviour deterministic where it matters, and choose failure modes you can reason about at three in the morning.

Adopt new tools, keep the judgement.

I have been bringing AI-assisted engineering into how my teams work day to day. It is a real change in how fast a small team can move. It does not change who is accountable for what ships: a person still has to understand it and stand behind it.

Copies a shoot to several drives and proves every copy is identical before the card is wiped.

A photographer comes home with memory cards that hold the only copy of the work. Every file has to be copied to several drives and shown to be identical before the card is wiped. Having lost entire cards worth of photos before, I treat a shoot as safe only once it exists, verified, on more than one destination drive. "The copy finished" is not verification. The operating system keeps recently written data in memory (the page cache) and will happily read back bytes that never reached the disk. Camera file numbers roll over, so two different photos can end up with the same name. And nothing tells you when a card is actually safe to format.

The work is done by a headless engine written in Python: it has no window of its own, and a macOS app is planned to sit on top and talk to it in JSON messages, one per line. Every byte goes through a single verified writer. A file is identified only by its SHA-256, a checksum, which is a fingerprint worked out from the file's bytes, so its name and timestamp never matter. A local SQLite catalog (a small database in a single file) records which drives hold verified copies of which shot. The trade is that nothing is taken on faith: every copy is read back from the drive and checked again, rather than assumed to be good.

• Never writes to source media: the card is only ever read.
• One verified write path: write to a temporary file, flush it to the drive, read it back, compare checksums, then rename it into place in one step so a half-written file never appears under its real name.
• The read-back bypasses the operating system's cache (F_NOCACHE), so verification checks the physical blocks on the drive rather than what is still sitting in memory.
• A RAW file (the camera's unprocessed original), its JPEG, sidecar and derivative files are grouped into one capture and named by a fixed rule, so the same input always gets the same name and counter rollover collisions are impossible.
• Reads Lightroom catalogs (.lrcat files, which are SQLite databases) to reconcile what is already imported.
• Tells you when a card is safe to format, then reconciles everything onto an offline master drive.

Python · SQLite · SHA-256 · F_NOCACHE · JSON-lines · Lightroom .lrcat · SwiftUI (planned)

A private gateway to cloud AI: models only see what my own rules have cleared.

I want to use powerful cloud AI models without my private data leaving my machine unless my own rules allow it. Hosted models are useful but extremely leaky. Left alone, a chat app will send private context, unvetted images and unbounded spend to whichever provider it is pointed at. And when something fails, the model will guess rather than say so: ask about a screenshot that never attached and it may invent an answer anyway.

Mimir is a daemon, a program that runs quietly in the background, acting as a policy proxy: a middleman that every request passes through. It alone holds the provider keys, the budget and the privacy rules, and my chat app talks to it as if it were a model provider. Decisions that matter are made by deterministic code, plain rules that give the same answer every time, before a model is called, not by asking a model to behave. The trade-off is that it is strict on purpose: at the monthly budget cap requests stop instead of quietly degrading, and a missing image is an error, not a guess.

• Every message is classified before anything leaves the machine; private messages are answered locally with no model call.
• Names and contact details are pseudonymized, swapped for stable aliases, on cloud requests and restored in the reply.
• A deterministic vision guard: if a message refers to an image that is not attached, it refuses instead of letting a model guess.
• Multi-model routing across four named slots, from cheapest-and-fastest to slowest-and-deepest.
• A hard monthly budget with a cost ledger; at the cap, requests stop rather than degrade silently.
• Honest failures by design: explicit error blocks instead of plausible-sounding answers.

Python · LiteLLM · Policy proxy · SQLite ledger · Pseudonymization · Vision guardrails · Self-hosted

• Amid Amazon’s Robot Surge, Proteus Charts a New Path Forward (CNET, 2026-06). CNET visits BOS27, the robot development facility in Westborough, Massachusetts. Travis Hearn, a QA engineer and a colleague of many years, explains how Proteus moves around people.
• Cutting-edge opportunity, delivered (Amazon News, 2019-06). Pegasus drives go to work at the Denver sort center.
• Look back on 10 years of Amazon robotics (Amazon News, 2022-06). Ten years of the robotics program, and the first look at Proteus.
• Amazon’s tiny robot drives do the heavy lifting (Amazon Science, 2022-06). How the Hercules, Pegasus and Xanthus drive units work.
• Amazon deploys over 1 million robots and launches new AI foundation model (Amazon News, 2025-07). The millionth robot, and the DeepFleet model that coordinates them.
• Amazon unveils new Proteus robot in €10 billion European investment (Amazon News, 2026-06). The next-generation Proteus and its expansion into Europe.

Coverage of programs I have worked on, in the publishers’ own words. Everything else on this site is my own view, not Amazon’s.

What I find most interesting in robotics is coordinating many independent machines with partial information under hard real-world constraints. The global energy grid has the same problem. I am steering toward Distributed Energy Resources (DERs): coordination, control and software for solar, storage and flexible load.