The Bottleneck in Agentic Coding Isn't the Model Anymore. It's the RAM.

A coding agent writes a patch, runs the tests, reads the failure, changes the patch, and tries again. On a whiteboard, that loop looks almost free. In production, every turn may need a clean filesystem, a checked-out repository, language runtimes, dependencies, test services, network rules, logs, and enough memory to keep the whole thing alive while the model decides what to do next.

That box around the model is becoming the expensive bit.

The clearest example this week came from Agent37, a YC F26 startup that launched on Hacker News with a narrow pitch: cheaper sandboxes for AI agents. Its team says workloads are constrained by RAM more often than CPU. A sandbox may spend much of its life waiting for the next model response while its Python processes, repository state, and dependencies continue occupying memory. Pack enough short-lived jobs onto a machine and unused CPU is little comfort when there is no RAM left for the next one.

Agent37 moved away from hyperscaler virtual machines and onto bare-metal servers from Hetzner and OVH, using gVisor for workload isolation. The team also argues that hyperscaler margins make conventional VMs a poor fit for a workload that constantly creates and destroys execution environments. That is a vendor's account of its own design, not an independent benchmark, but the architecture points at a real change in agentic coding. Generating another candidate patch is easy. Running it safely, cheaply, and with useful feedback is where the engineering piles up.

The Harness Owns the Outcome

For the first stretch of the coding-agent boom, model capability dominated the conversation. Could the model write a function, understand a repository, or reason through a stack trace? Those questions still matter. But they no longer explain the full gap between a clever demo and a system that can work on a repository for hours without making a mess.

The gap lives in the harness: prompts, memory, tool permissions, sandbox lifecycle, test commands, retry rules, logs, and escalation paths. The model proposes an action. The harness decides what it may touch, runs it, captures the result, and turns that result into the next useful observation. Weakness in any one of those steps wastes the model's reasoning. A perfect patch is useless if the environment cannot install the dependencies. A useful test failure is lost if the tool truncates the log. A productive search turns into thrashing if the harness fails to recognise that the fifth retry repeated the first four.

The October 12 paper "Self-Evolving Agent Harness" pushes that idea further. Its authors study agents that improve the software around the model across runs. The agent can revise prompts, memory, workflows, and tool use rather than relying on another round of model training. That shifts improvement into a layer a small engineering team can inspect and change.

It also creates a nasty ownership problem. If an agent edits the instructions and tools used to judge its own work, a bad change can corrupt both the task and the feedback loop. The paper calls for independent safeguards and continual validation outside the part of the harness that evolves. In practical terms, the agent can tune its workflow, but it cannot quietly rewrite the definition of a passing test.

That boundary matters more than another clever prompt. The harness has to preserve a trustworthy signal while the agent experiments. Otherwise, more attempts merely produce more ways to declare victory too early.

Cheap Execution Changes the Search Strategy

Sandbox cost shapes agent behaviour. When every clean run is slow or expensive, the harness pressures the agent to get the patch right quickly. That sounds efficient, but it favours cautious local edits and discourages experiments. A cheaper execution layer can test more candidate changes, discard the failures, and keep the one that survives verification.

The useful unit of progress is a completed, observable experiment rather than raw generated code.

That experiment needs a known starting state, an action, captured output, and a verdict. It may be a unit-test run that takes seconds or a machine-learning experiment that takes hours. Either way, the agent needs the result before it can make a better next decision. More model tokens cannot substitute for a missing environment or an unreliable verdict.

The October 14 paper "MLExpert: Towards a Generalist Agentic Model for Autonomous Machine Learning Engineering" treats these feedback loops as part of the learning problem. Its 35-billion-parameter mixture-of-experts model uses Windowed Interaction Reinforcement Learning, which groups the agent's decisions and the resulting experimental feedback into longer interaction windows. The target is competent behaviour across a sequence of experiments, rather than one impressive answer in isolation.

That is a useful picture of where coding agents are heading. A serious agent will be judged by whether it chooses a sensible experiment, reads the outcome correctly, and adjusts without losing track of the goal. The model still matters, but the quality and cost of the execution loop determine how often that ability can be exercised.

Cheap sandboxes do not mean running a thousand blind guesses until one test happens to turn green. That would reward accidental success and burn infrastructure. The harness still needs budgets, duplicate-attempt detection, and escalation when the search stops producing new information. Lower cost gives the agent room to explore. Good controls keep exploration from becoming thrashing.

Build the Box Before Chasing the Benchmark

If I were improving a coding-agent stack now, I would measure the execution layer before swapping models. I would want to know how long a clean sandbox takes to start, how much memory a typical repository consumes at idle and under test, how often setup fails before the agent's code runs, and how many retries repeat an earlier action. Those numbers reveal whether the bottleneck is reasoning or plumbing.

I would also make every run legible. The harness should retain the patch, command, exit status, relevant logs, resource use, and reason for the next attempt. When the retry rate crosses a threshold, it should stop and ask for a different tool or human input. "I am stuck" is a valid action. It is cheaper than twenty more versions of the same failed patch.

Shared-memory sandboxes, gVisor, and bare metal are one possible implementation, not a universal recipe. Teams with stricter isolation requirements may accept higher costs. Workloads with heavy compilation may hit CPU before RAM. Long-running services may behave nothing like short test jobs. The point is to profile the actual loop instead of assuming the model call dominates it.

The next practical gains in agentic coding will come from running more useful experiments per pound, while keeping the verdict trustworthy. Start by instrumenting one task end to end. Measure sandbox startup, peak RAM, idle time, test duration, repeated attempts, and setup failures. Then you will know whether your next investment belongs in a better model or a better box.