6 posts tagged with "agents"

Tokenmaxxing now gets the hangover treatment. A few months ago, the same behavior looked like aggressive AI adoption. Now the press writes the behavior up as runaway cost. Pylon's bill jumped into enterprise pricing. Fortune called tokenmaxxing a bad ROI metric. WSJ covered the companies that treated tokenmaxxing as survival. Satya Nadella admitted that the habit is addictive.

The obvious lesson: tokens are not output. A leaderboard that rewards the person with the most burned model context is a speedometer on the wrong machine. The leaderboard tells you that activity happened. The leaderboard does not tell you whether the spec improved. The leaderboard does not tell you whether the code survived review, or whether the next run got easier.

But the opposite lesson is also wrong. "Tokenmaxxing is dead" becomes nonsense if the phrase means "stop spending frontier tokens." The useful version is narrower. Spend the expensive tokens where the tokens improve the harness, not where the tokens become the scoreboard.

AGRO runs each coding agent inside a Docker container. The agent can thrash around in the sandbox and never touch your laptop. The question "container or full VM?" had a settled answer: the container wins. Last week, I researched the next contender. Should a Firecracker microVM replace the container under the agent?

The honest answer was no. The microVM is not weak. Firecracker exists for a job that AGRO does not do yet: untrusted agents for many tenants on shared hardware. For the job that AGRO does, the microVM fits worse. The research made the case for the container as the default even stronger. A microVM takes away the instant, live-editable sandbox that you get when you point the harness at a repo. The research also made me lay out three ways to box in an AI agent. The three boxes are a full VM, a container, and the microVM between the two. Here is the whole mental model.

A few weeks ago, I read Every's compound-engineering guide. The guide gave a name to a practice that I had built without a name. That discovery deflated me a little. The guide states the core idea: "each unit of engineering work should make subsequent units easier—not harder." Most codebases drift the other way. Each feature adds complexity. The more you ship into a codebase, the worse the codebase gets.

I read the line and thought: that idea is the entire point of the harness. The idea is not a feature that I should add. The idea is the constraint that already shapes each file in the harness.

This post is about a concrete, working instance of compound engineering. The post skips the abstract philosophy. The post shows the files that make the idea true. The post also shows the documented failure modes, because I want to be useful, not breathless.

For two years, I called every part of my setup "an agent." The model that typed in my terminal was an agent. The shell script that ran the model was an agent harness. The container around both was also "the agent." I tried to describe my setup to a colleague. The word stopped working in the second sentence.

Then I drew the setup on a whiteboard. The boxes had different shapes. Four shapes did four jobs. My setup felt fragile for one reason. I used one word for four different parts, and I tripped over that word each time I reasoned about the setup.

Here are the four words.

If you know Ralph loops, you know the punchline: context rot silently kills productivity. The quality of the model does not matter. After the working window fills past ~70%, output quality drops off a cliff. When you notice the regression, you have lost half the session.

Few people mention the next fact: Claude Code does not show context usage by default.

In the middle of a hot loop, your window can be 90% full, and the terminal shows no sign. Your next response is mush. You blame the model, you run /clear, and you lose the thread. All the context data that you needed was on stdin, and no script rendered the data.

/statusline renders that data.

Archived. This post shows the April 2026 multi-agent model. AGRO now gives one repository one sandbox. The image contains no agent CLI. You install each agent with agro harness install <id>. This page keeps the post for history.

Last week I ran ls ~/.nvm/versions/node and counted 14 Node versions. pyenv held three Pythons. A Rust toolchain from one Tauri experiment in 2023 was still there. npm did not list my ~/.local/share/pnpm/global directory. My laptop held years of old dependencies.

Codex started the problem. I wanted to try the OpenAI CLI next to Claude Code. The Codex install asked for Node 20. The Gemini CLI install asked for Node 22. Pi, the agent runtime that I wanted for the glue, asked for a clean Python 3.11 venv. Each agent CLI added new dependencies and a new chance to break the other two.

I stopped and put the whole setup in a container. Now my laptop runs Docker and one binary. Each agent CLI lives inside a sandbox, and I delete the sandbox in seconds.

The project is AGRO. The pattern is BYOH: Bring Your Own Harness. The next sections show the change to my workflow.

Three commands for each agent​

Run these commands on the host:

agro sandbox install docker --name my-agent   # create and start the sandbox
agro shell my-agent                           # open zsh inside the sandbox
agro destroy my-agent                         # delete the sandbox and its volumes

The sandbox is a Debian container with gh, tmux, Node, and the rest of the toolchain. In April 2026, the image also contained Claude Code, Codex, the Gemini CLI, and Pi. Today, the image contains no agent CLI. Inside the sandbox, install each agent that you use:

agro harness install claude
agro harness install codex
agro harness install pi

Each install lands in ~/.local in the home volume, so the install survives a container recreate. Then sign in to each agent once. See the Quickstart.

You no longer upgrade brew first. A CLI for Node 22 no longer breaks on Node 24. The host stays clean, and the sandbox does the work.