Agency Tool Company
Join the waitlist

JOURNAL

Field Notes.

Launches, lessons, best practices and musings

ANNOUNCEMENT

Agency Tool Co. Launch

Introducing Agency Tool Company and ATC Deploy — shipping software to robots wherever they are, 20x faster than a docker pull.

2026-07-24 · 8 MIN

ANNOUNCEMENT

DATE2026-07-24

READ5 MIN

AUTHORATC TEAM

Agency Tool Co. Launch

Agency Tool Company builds fast, reliable infrastructure for the people bringing robots to life, from researchers and engineers in the lab to technicians and fleet managers in the field. ATC Deploy ships software to those robots wherever they are. It can deploy an update 20 times faster than docker pull or scp, add security, and work with the operating system and runtime you already use.

Today I’m excited to share Agency Tool Company and our first product, ATC Deploy.

We started Agency Tool Company because Davis and I have spent much of our careers building and deploying robots, and repeatedly found that janky tooling was the bottleneck to improving the robot.

The update that took until 2 a.m.

Davis and I founded Scythe Robotics and spent eight years taking an autonomous mower from early experiments to hundreds of machines working across the country. We fielded generation after generation, first near our shop and later at customer sites thousands of miles away.

Yet for years we still relied on a rollout tool I had cobbled together for our first few robots. It did the job when the fleet was small. Later, a routine update could leave engineers awake until 2 a.m fighting failed updates and special snowflakes. Some customers had to pull their robots out of sheds and connect them at an agreed time so we could push new software.

We knew we needed something better. We also had ML models to train, blades to test, machines to build, and customers to serve. Customers don’t see how the software-deployment-sausage is made. So the rollout system fell to the bottom of the list, again and again.

This story plays out across robotics. Nearly every team has stitched together web, cloud, or IoT tools and made them kind of work. Engineers know which scripts to run and which errors to ignore. Fleet managers learn to call the one person who understands the whole thing. Everyone knows it needs work. Everyone has a robot to build.

Robots are not cloud servers

A robot may work in a field, a warehouse, or underwater. Its network may be slow, costly, or flaky. Its software may include a 3 GB CUDA layer, a 20 GB model, an operating system image, and custom code for every motor and sensor. It may need several full versions on the machine so it can switch back without calling home.

Tools built for servers miss this reality.

A layer interrupted during docker pull starts again from zero so a robot might download most of the same 3 GB layer 15 times: RIP, LTE bill. Mender can’t ship a blob larger than 10 GB. Sorry, model weights. And neither can do arbitrary delta updates, stage several complete versions on one machine, and switch between them as one safe step.

Even the tools made for robots force you to send every update through the cloud. Sorry, but if my robot is three feet in front of me, then dammit I don’t want to push across the internet and back. And, ahem, I certainly don’t want to rewrite my drivers in Go or Swift just to fit my deployment tool.

Robots are not the cloud. They are not just large IoT devices either. Robotics teams deserve tools that work with their reality.

We lived this problem

At Scythe we saw every stage of a robotics company: research, prototypes, field tests, production, and support for autonomous machines spread across the country. Each stage exposed a new piece of infrastructure that was hard to build, easy to neglect, and shared by almost every other robotics team.

That is the waste at the heart of this problem. Some of the world’s best engineers spend their time rebuilding the same half-finished tools multiple times across companies. Each system ties together parts that were not made for robots. Each one depends on scripts, unwritten rules, and a few people who know how to keep the house of cards standing up.

Meanwhile, robot engineers and fleet managers wait. They need delta updates, clear rollout rules, atomic releases, control over attached hardware, and security built in from the start. These are not side concerns. They set the pace at which a team can learn, improve its machines, and put more of them to work.

We started Agency Tool Company to build this common foundation once, and build it right.

Start with software delivery

We are starting with software delivery because every robot needs it. OTA is how new behaviors, fixes, and models travel from the people building a robot to the machines doing the work.

ATC Deploy ships what you use today:

  • Your own operating system image
  • Docker (OCI) images
  • Any file or directory tree

You do not need to rebuild your system around us.

Say an engineer recompiles their ROS2 workspace and rebuilds a Docker image with a new dependency. They then run:

$ atc ota push user@robot

ATC Deploy automatically finds what bytes changed between the two artifacts, send just them to the machine, and restarts the software through user-defined hooks. The new code is running in less time than docker push alone would have taken.

We designed ATC Deploy from three principles:

  1. 01It should be simple. One curl | sh install and one configuration file get a team going.
  2. 02Networks fail. Every update resumes where it stopped and sends only the data that changed. That matters when robots use slow links, costly links, or no link at all (USB drive updates, anyone?).
  3. 03The tool should fit the robot, not the other way around. ATC Deploy works with Docker, tarballs, ROS, ROS 2, LeRobot, DimOS, Nix, and whatever else you’re using to bring your bots to life.

Built with teams in the field

We are fortunate to have the incredible teams at Burro, Tempo, and Gather AI as our launch partners. They build different robots for different industries, but all three have crossed the hard line from a promising machine to a useful one.

Burro has deployed more than 750 robots around the world, where they work each day alongside people in agriculture and other outdoor industries.

Tempo machines are already grinding at customer sites across several US states and Canada.

Gather AI’s drones are counting inventory in warehouses across the country where they’re having incredible impacts on efficiencies. For one customer, they provide unmatched 99.9% inventory accuracy and for another, they raised measured productivity fivefold by scanning whole warehouses in a fraction of the time people need to count them by hand.

This is what real robotics progress looks like: machines leaving the lab, earning trust, and doing valuable work each day. These teams should spend their time making those machines better, not rebuilding the same delivery system.

Robots are hitting their stride

The enabling technologies of robotics have improved at a remarkable rate. Embedded computers are cheaper and far more powerful while the HW & SW ecosystems have matured dramatically. And of course, modern robotics AI like VLAs and world models can now routinely solve problems that looked insurmountable when we started Scythe.

You can see the result in our launch partners. They have useful robots working in agriculture, construction, and logistics today, and each one has huge growth on the horizon. The companies that will define the robotics industry are being started today.

But a new model or faster computer does not, by itself, make a reliable robot fleet. The foundation still matters. Customers expect a machine to work every single time they need it. A bad update can stop that machine hundreds of miles from the engineer who sent it. A flaky deployment system will make your team nervous and slow to push improvements to customers.

That is why ATC Deploy is our first step.

Next comes ATC Build. Validation is the bottleneck in robotics — the real world does not, unfortunately, unit test very well, and what can be tested in software needs to actually run on the target platform, which isn’t available in AWS or GitHub Actions today.

ATC Build will put that hardware into a team’s build and test system with a one-line change. Engineers will test code on the right computer before they send it into the field. We’re early, but the validation cloud for NVIDIA Jetson and other embedded compute platforms will be a huge unlock in robotics teams’ productivity.

Robotics does not live only in bytes, of course. Teams also need better hardware building blocks and over time, we will build those out too, on top of the same Build and Deploy foundation.

Why Agency Tool Company exists

It is still so early in the robotics wave. People spend countless hours counting boxes, grinding floors, hauling loads, mowing grass, and doing other work that robots can help carry. We have barely begun to see how much better these machines can make our lives.

Agency Tool Company exists to give people more control over how they spend their time by helping the world build more useful robots. We are taking the lessons learned by the pioneers of this industry and turning them into tools, so the next generation can skip old pain and move faster.

We are starting with Deploy. Build comes next. From there, we will keep working down the list of hard, common problems that hold robotics teams back.

If you build or operate robots, join our waitlist. We would love to learn what slows your team down. If you know a team that should use ATC Deploy, send them this post or put us in touch.

It’s time to build robots.

Want this on your fleet?

Join the waitlist