Why we built Kuiper

We started Proxima with a simple picture in mind: a founder asleep at their desk while a small team of droids keeps working around them. One reads the inbox and drafts replies. One triages the backlog. One builds the deck before Monday’s meeting. The founder approves what goes out, and the droids take care of the rest.

We thought the hard part would be the droids. It turned out to be everything they stand on.

The agent was never the hard part.

Deciding what a droid knows, what it can do and how it talks to people was the part we could move quickly on. Glove gave us the agent loop, the tools and the memory. Station made sure a droid woke up when an email landed or a schedule fired, even if a server had restarted in between.

What slowed us down was the layer underneath. A droid that writes code needs a safe machine to run it on. A droid that thinks needs the right model for each job, and a plan for when that model’s provider has a bad afternoon. A droid that makes things needs somewhere to keep them. And all of it has to keep running while you ship new versions of the droid on top.

None of that makes a droid smarter. All of it has to exist before you can trust one with real work.

The same work, again and again.

Sandboxes were the clearest example. Every time we learned something about how droids actually used them, how long jobs ran, how often they needed to resume or how much output they produced, we had to change how the droids reached them. We rebuilt that connection more times than we’d like to admit, and every rebuild was time away from the droids themselves.

Models were the same. Different jobs want different models: a strong one to plan, a fast one to read a long thread. So we built routing, then caching, then cost tracking, then failover. The first time a provider ran out of credit mid-conversation, a user saw the raw error. That’s how we learned we needed a way to hold a turn and replay it once the provider recovered.

Then came storage for the images and documents droids make, background jobs that had to survive a restart, and deploys that interrupted work in flight until we taught every service to finish what it was doing before it exited. Each fix was reasonable on its own. Together they added up to a second product we hadn’t meant to build.

It wasn’t just us.

Look at any team building serious agents and you find the same list: a sandbox for code, a browser for the web, a way to route between models and survive their outages, storage for what agents produce, jobs that outlive a restart and deploys that don’t drop work on the floor.

Every team builds it a little differently, and every team pays for it with time that should have gone into their agents. The frontier moves fast. The teams working there shouldn’t have to rebuild the ground beneath them every time it does.

We’ve done this before.

Glove exists because building an agent shouldn’t mean building an agent framework first. Station exists because background work shouldn’t mean building a job system first. Much of what we learned along the way is already public: we’ve written on the Glove blog about the reasoning behind each piece, usually after a real production run changed our minds.

• The workflow is no longer the productWhy Foundry treats the agent application, not a hand-drawn graph, as the thing that lasts.
• Agents with browsers, sandboxes, and one managed daemonGiving agents browsers, sandboxes and long-running processes, each with its own lifecycle.
• Fresh context belongs inside the agent loopInjecting current state before every model call, instead of baking it into the prompt.
• Every failure in this one was silentBugs that produced valid-looking output, and why the fix belongs in the error message.
• Building the voice stack: what only live calls told usThe problems that only showed up once real people were on the line.
• Classifier models in GloveDeciding what matters without reading it, with far less context and better accuracy.

The browser and sandbox post ends on an honest limit. Foundry can run those resources for you through one managed daemon, but that daemon “is local and stops with Foundry; it does not provide distributed failover.” Glove answers how an agent is built. Station answers how its work gets done. The missing piece was a place for all of it to run that doesn’t stop when your laptop does.

What Kuiper is.

Software is becoming agentware: programs that run code, browse the web, call models and work for days. Kuiper is the platform for running it. Push a Glove Foundry project, a Station project or anything with a Dockerfile, and it runs. Your agent can start isolated sandboxes and real browsers when it needs them. Foundry keeps its memory and schedules; Kuiper keeps the disks underneath, restarts whatever crashes and deploys without losing state. Every agent gets its own HTTPS address from the first deploy, ready for webhooks, plus your domain if you want one, encrypted secrets, logs and one-click rollbacks.

A model gateway, with one API and one bill for every provider, storage for the files and media your agents make, and databases you can attach to an agent are next. They’re the pieces we spent the most time on for Proxima, and the pieces we most want you never to build.

Proxima is our first tenant. Its droids never had a browser, because we never had the time to build one properly. On Kuiper, it’s something a droid can simply ask for.

The promise is short. You build the agent, and Kuiper runs everything under it, so you can spend your time on the part only you can build.