How Reason Machines Built an Autonomous Software Engineer on Blaxel

Adi Singh and Sven Myhre had been running agents hard in the terminal for years. They were early adopters of cloud-based coding tools, heavy users of whatever the space had to offer, and still frustrated. The pace of progress wasn't matching what they thought was possible.

"We didn't see the space evolving to the pace that we'd want to," Adi says. So they built what they wanted to exist.

Reason Machines is a YC-backed company building what they call the autonomous software engineer: a cloud-native agent that takes a task, works through it without interrupting the developer, opens a PR, and in many cases merges it.

To make that work, they needed infrastructure that could match the model: always-on agents and persistent environments that don't vanish between tool calls. Blaxel became the sandbox provider that made it possible.

The Problem with "Agents" That Still Wait for You

Before getting into the infrastructure, it's worth understanding what Reason Machines is actually building, because it shapes every technical decision they make.

Most coding agents today are still interactive: they suggest, pause, and ask. Adi describes the boundary between an agent that suggests and one that ships as a single word: asynchronous.

"If you're able to spew your thoughts and tasks onto an agent, where instead of it interrupting you on unnecessary guards or permission levels, it's able to orient itself to the next task without stopping up, that's the kind of agent you want."

Reason Machines tracks a specific metric for this: how many tasks can a user send in one session before the agent forces them to stop and answer something? The goal is to push that number as high as possible. If an agent has ten tasks queued and one requires external input, it should continue with the other nine.

They've also shipped an auto-PR agent that reviews pull requests against the team's own instructions and merges to staging or production automatically. It was met with skepticism early on. It's now a core feature, and Cursor has since shipped something similar.

The architectural implication: an agent that actually ships code needs a runtime that can match it. Sandboxes that cold-start on every task, or that lose state between steps, break the whole model.

What Runs Where

Reason Machines uses what they call a "brain enhanced architecture." The agent itself lives in a persistent shell environment separate from whatever device it's operating on. That environment is always on. When the agent needs to execute code, run tests, or interact with a file system, it reaches out to a compute provider and attaches.

Blaxel is their primary sandbox provider in that chain. When the agent needs access to Bash, a REPL, or any process that requires an actual machine, it connects to a Blaxel sandbox. The connection happens in around one to two seconds. From there, the agent has full access to the environment: files, processes, the terminal.

The separation matters because the agent's brain is always running independently. It doesn't have to restart when a sandbox spins down, it just reconnects when it needs compute again. The state that matters lives in the agent layer. The sandbox is where execution happens.

How Reason Machines Found Blaxel

Before Blaxel, Reason Machines was running their own setup: Incus, Firecracker, and a self-managed Kubernetes cluster. They were handling sandbox provisioning, skill snapshots, and file storage persistence on their own. It worked, but it was overhead they didn't want to own.

They met the Blaxel team outside a YC event. The conversation was fast.

"We were discussing a provider at that time," Adi says. "We had a long chat about why Modal was quite expensive. And then Blaxel seemed to have everything."

What closed it was a specific feature. Reason Machines was working on computer use at the time, trying to figure out how to stream a real development experience back to users so it felt like local development, not a laggy remote desktop. The Blaxel team mentioned preview URLs: live URLs that stream the actual process running in the sandbox, not a VNC session.

"We spent last week building that in house," Adi recalls. "So that felt like an easy choice."

They started evaluating that night.

The Architecture in Practice: From Issue to PR

When a task arrives in Reason Machines, whether assigned manually or triggered by an automation the agent set up itself, the flow runs without developer intervention.

The agent evaluates whether it needs a sandbox at all. For tasks it can complete through API calls to GitHub or other services, it doesn't spin up compute. For anything requiring code execution, file access, or testing, it connects to a Blaxel sandbox.

Once in the sandbox, the agent works through the task and generates a before-and-after recording of the feature it built. That recording gets embedded in the PR. Adi is direct about why: "People are not looking at code anymore. You want to have embedded videos before and after."

The PR itself starts as a draft. Teams can configure hard rules: no merges over 500 lines, required tags, whatever conditions the PR has to meet. If the merge bot is active and the rules are satisfied, the PR merges automatically. The developer never has to open the application.

"You would not have to enter the application at all," Adi says.

Persistence Under Pressure

The hardest thing Reason Machines has had to manage isn't the agent logic. It's the economics of sandboxes at scale.

When Reason Machines opened up free tiers, usage spiked in ways they didn't anticipate. Users, including other developers stress-testing the product, would spin up large numbers of sandboxes in parallel. Ara's first base task when evaluating competitors is 100 parallel agents. Their users do the same thing.

"We thought that sandboxes could be provided as almost a free service," Adi says. "We didn't quite see that it would be necessary to gate that."

The challenge is keeping sandboxes available without paying for idle compute. Blaxel's auto-suspend behavior became a meaningful part of how they solved it.

Agents spend a lot of time reasoning before they act. During that reasoning window, the sandbox isn't doing anything. Blaxel's auto-suspend kicks in during those gaps, and the sandbox resumes when the agent is ready to execute again.

"Closer to 10 to 15% of our usage was actually been able to save there, just because we were able to snapshot and keep the sandboxes on auto idle," Adi says. The sandbox doesn't get moved to volume storage, because Reason Machines needs it back fast when the agent's next tool call lands. But the idle time between calls is real, and capturing it matters.

"As I see that agents will reason and think more before doing this, this sleep state that you can provide in between tools where they don't need the machine makes having a provider that makes sandboxes turning off and on with persistence way more important."

What Blaxel Handles That Reason Machines Doesn't Have To

Adi is clear about Reason Machines' build-versus-buy philosophy: limit the services you pay for, and when you use one, check whether it covers what you'd otherwise build yourself.

By that standard, Blaxel earns its place in the stack.

Preview tokens are one example. The primary use case is obvious: you get a live URL for whatever the sandbox is running. But Reason Machines found a second use. Preview tokens can carry embedded secrets, which became their first authenticated security policy. The token determines which workspace member has access to files and secrets inside the sandbox.

"These are great features that just come out of the box," Adi says.

Templates were another. When Reason Machines was early and still figuring out what their users actually needed, Blaxel's template library (covering headless browsers, noVNC, and other browser options) gave Adi a fast way to understand what primitives existed and which ones mattered for their use case.

"By seeing the templates, I was able to quickly understand: oh, I need to know what these things mean. Like I need to know that a headless browser is an alternative to Chromium that you can run in a sandbox very efficiently."

The Sandbox as Infrastructure Pillar

Adi frames Blaxel's role in Reason Machines' stack the way most companies think about their auth provider or their database.

"In our tech stack of what we think is like an auth provider, a database provider, a frontend provider, the basically the fourth and like pillar of this turns into being our sandbox provider. And I think every single agent company will have these four pillars, and this fourth one is actually new."

That framing is worth sitting with. For the generation of companies building autonomous agents, compute that can execute code in isolation, resume fast, and hold state isn't a nice-to-have. It's a foundational dependency: the same category as storage or auth.

Reason Machines' usage has also evolved in a way that illustrates how quickly that dependency scales. They started evaluating Blaxel for small, lightweight workloads: sub-gigabyte containers for automation tasks. They thought they'd need the smallest possible sandboxes.

"Little did we know now that every single thing we provide is like eight gigabytes and above. People are running way more agent compute than we thought."

What's Next

Reason Machines is running hackathons across university campuses, including a keyboard-less event where participants built products entirely through voice, with Ara handling the code. The YC community in San Francisco has become a primary customer base, with Ara's office a short walk from the YC building in Dogpatch.

On the infrastructure side, they're continuing to optimize idle costs and working through the remaining rough edges in sandbox lifecycle management. The bigger picture is that Reason Machines is betting on a world where the autonomous software engineer isn't a concept but a standard part of how engineering teams work. In that world, the infrastructure underneath has to be reliable enough that developers stop thinking about it entirely.

"Blaxel is the simplest to get started on," Adi says. "Being simple matters."

If you're building an autonomous agent and want to understand how Blaxel's sandboxes fit into a production stack, the documentation covers the full architecture. You can reach the team at [email protected].