Stop Tuning the Agent. Build the Environment.

We spent a year arguing about skill. Whether the human had it, whether the model had it, whose fault it was when the agent failed. That argument is mostly over. The harnesses converged. Read, write, bash, compact, remember: whatever vendor’s logo is on the terminal, the loop underneath looks the same. When the agent itself becomes interchangeable, the interesting problem moves up a layer, to the place nobody was looking. The agent was never the hard part. The environment was. Everything is an environment.

The Agent Is a Commodity Now

Look at any two agent tools side by side and try to find the part that actually differs. The context window compaction. The memory that persists across turns. The bash-read-write-edit toolset. The planning loop. These used to be differentiators. Now they’re table stakes, and they arrived at the same answer independently, the way every text editor eventually grew the same five features.

That convergence is good news, and most people are reading it wrong. They treat it as a shopping problem: which agent is smartest this month, which benchmark moved, which model to standardize on. You can burn a quarter on that evaluation and the answer will be stale before the procurement paperwork clears.

The leverage isn’t in picking the agent. It’s in the substrate you drop it into. I made this argument narrowly when I wrote about why you should own the harness instead of renting it. This is the same argument one level out. Owning the harness was step one. The environment wrapped around that harness, the thing that decides whether the agent can actually do its job, is step two, and it’s where the real engineering hides.

A Sandbox Is Not a Dev Box

Here’s the distinction that most teams get wrong on day one. Running code is not the same as building software, and the environment you need for each is different.

A sandbox is bare. Spin up a stripped Linux box, run an untrusted snippet, throw it away. That’s the right tool when the agent needs to execute something risky in isolation, and the security landscape for it has matured fast, from hardened containers to microVM isolation with Firecracker and gVisor. If all you want is “run this and tell me what happened,” a sandbox is enough.

But hand that same bare box to an agent and ask it to build a web app, and watch it fail in slow motion. It can’t open a port. It can’t serve the thing it just wrote. It can’t screenshot its own work to see whether the layout broke. Push into anything data-heavy or model-heavy and it gets worse: no accelerator means you’ve asked the agent to profile something on hardware that physically cannot run it.

The job was never “give the agent a computer.” It’s provisioning the right computer, on demand, with the ports and the tooling and the horsepower the task actually needs, and doing it without a human babysitting every spin-up. That’s an environment problem. No amount of prompt engineering fixes a box that can’t bind to port 3000.

CI Thinking Breaks

Most enterprises already have a mental model for “run code on a machine somewhere.” It’s called CI, and it’s the wrong model. Reaching for it here is the most expensive mistake I see.

CI is a job. Clone the repo, run a deterministic suite, report pass or fail, discard the machine. It’s stateless by design, and that design is a feature: every run starts clean, so nothing leaks between them. Cattle, not pets.

An agent doesn’t work like a job. It works like a session. It spins up, works for a while, hits a decision it can’t make alone, and asks a human. Then it waits. Not for seconds, for days, until someone reviews the pull request and answers. Nobody keeps a machine hot for three days waiting on a code review. So the session has to outlive the box it started on. That forces questions CI never had to answer: how do you snapshot a process mid-thought, freeze the file system mid-build, and resume it cold two days later as if nothing happened?

The shape of the work is different, so the infrastructure has to be different. If you bolt agents onto a CI brain, you’ll spend every session fighting the fact that your platform wants to throw away the exact state you need to keep.

The Environment Drifts

CI can treat machines as disposable because a discarded run costs nothing. Rerun it. You lose a few minutes.

You cannot do that to an agent. It may have worked for a day. That progress is expensive, sometimes irreplaceable, and “just rerun it” throws away real work. Worse, the ground moves while the agent stands on it. It checks out the code, starts working, and by the time you come back, the main branch has changed underneath it. Now the environment itself has to resync. Maybe the code it’s now merging against needs a library that wasn’t installed when the box booted.

This is the quiet killer, and it has a name: drift. You write a setup script once, the code keeps moving, and the environment slowly stops matching reality. The script that installed the right dependencies in January is subtly wrong by March, and nobody notices until an agent produces confidently broken output because its world diverged from the repo’s.

The fix is the one the broader industry already landed on for humans: treat the environment as code and version it next to the source. Development containers encode the whole environment (OS, runtime, tools, services) as a file that lives in the repo, so the environment and the code move together instead of drifting apart. Do that, keep the image warm, re-bake it on a schedule, and sync to the latest commit at boot. The agent starts at most a little behind main and catches up in seconds instead of inheriting an environment that rotted weeks ago.

The Security Boundary Flips

Here’s where the enterprise instinct is not just insufficient but pointed the wrong way, and in a regulated shop that misdirection is dangerous.

The classic threat model for running code is the outsider. You harden the perimeter because you’re afraid something gets in and exfiltrates your secrets. Every control you’ve built assumes the danger is external.

Flip to an agent and the geometry inverts. The untrusted process is already inside. You put it there on purpose. It can read any secret sitting in its own environment variables, and it will, because you handed it a shell and told it to be resourceful. I’m not going to fear-monger about a rogue agent plotting against you. The realistic failure is dumber and far more common: an agent stuffs an API key into a URL parameter to make a request, and that URL lands in a log, and now your credential is sitting in plaintext in a log aggregator that fifty people can read.

You have a process you can’t fully trust and you’ve handed it your secrets. The fix is architectural, not a policy memo. Secrets should never live in the environment the agent can see. Inject them through a proxy or a sidecar at the moment of use, so the agent can make the authenticated call without ever holding the credential in a variable it can print. This is the same principle a bank already applies to every other untrusted input; the discipline just has to extend to a process you invited in. If you’re serious about agents touching anything sensitive, this is not optional, and retrofitting it after an incident is the expensive path.

A Fire Door Between Planning and Doing

The early agent designs put everything in one process. The agent held the plan and executed the risky tools in the same place. It’s convenient, and it’s fragile, because one bad tool call takes down the whole thing.

Picture an agent told to load a ten-gigabyte file into a box with two gigabytes of memory. The tool blows up. In a collocated design, it doesn’t just fail the tool, it drags the agent’s entire state down with it. A day of context, gone, because one operation was greedy.

Orchestration solved this problem long before agents existed, and the pattern transfers cleanly. Separate the thing you never want to fail from the long tail of things that might. Keep the agent (the part holding the plan, the context, the expensive accumulated state) in a control plane. Let it reach out and run the risky read-write-bash work in a disposable data-plane box. When something corrupts, it corrupts the box, not the agent. You throw away the box and the plan survives.

This isn’t a novel invention; it’s the control-plane / data-plane separation that already runs your networks and your clusters, applied one layer up. Architects recognize this on sight. The mistake is assuming the agent framework handles it for you. Most don’t. You have to draw the boundary yourself.

Build for the Fleet, Not the Demo

Two failures separate an environment that works in a demo from one that works at scale, and both are unglamorous.

The first is cold starts. If every agent spin-up runs a setup script that installs the runtime, the dependencies, and the tooling from scratch, you pay a two-to-ten-minute tax on every single task. That tax is invisible in a demo and fatal in production, because a paved road nobody wants to drive on is just an expensive decoration. Warm images and sub-second boots aren’t a nice-to-have. They’re the difference between a platform people use and one they route around.

The second is that agents turned out to want exactly what humans always wanted. Good documentation. Clear error messages. Sane defaults. Predictable interfaces. The thing that helps a new hire figure out the next step is the same thing that helps an agent figure it out, which means your internal platform ergonomics are now being read by machines at industrial volume. Sloppy errors and stale docs used to cost you one confused engineer. Now they cost you a fleet of agents making the same wrong guess in parallel.

And that word, fleet, is the blind spot. Everyone over-invests in tracing a single agent, watching one run step through its reasoning. Almost nobody measures the fleet. When background agents are opening a meaningful share of a team’s pull requests, the interesting question isn’t “what did this one agent do.” It’s “what is this software factory producing, and how would I even know if it started producing worse.” That measurement problem is wide open, and it’s an environment problem too.

Everything Is an Environment

“Everything is a skill issue” was a claim about the human. Get better at calibration, prompting, orchestration, and the failures shrink. It’s true, and I’ve argued it, but it’s the argument for one person at one keyboard. It doesn’t survive contact with an organization running agents at scale. I made that case in Everything Is Skill Issue: the bottleneck there was organizational, not technical.

This is the technical half of the same coin. Once the org says yes, the thing that decides whether agents actually deliver isn’t the model you licensed. It’s the environment you built for it: fast to start, stateful enough to survive a multi-day review, secure enough to hold secrets it can’t see, isolated enough that a crash costs a box and not a day, and measured at the fleet level instead of one hero run at a time.

I’ll be honest about why enterprises are bad at this. It’s plumbing, and plumbing doesn’t demo. Nobody gets promoted for a warm image cache. And our environments were built, lovingly, over decades, for humans, one careful engineer at a time, not for a hundred ephemeral agents spinning up and tearing down every hour. That mismatch is the real work of the next two years, and it’s mostly unbuilt.

The moat was never the agent you pick. Everyone will have the same agent. The moat is the environment you build for it, and that’s a thing you have to earn one unglamorous layer at a time.

If this landed, read Everything Is Skill Issue, on why the real bottleneck is organizational rather than technical, and Banks Don’t Need Another Agent. They Need a Context Layer., on the part of the environment that regulated shops keep skipping.

Find me on X @orestesgarcia or LinkedIn.