We built the agent, then we deleted it

Agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing and nothing carrying over to the next one. Next.js ended this for the web, and eve is doing the same for agents.

That is Vercel, announcing eve this week. An open-source framework where an agent is a directory of files, and the runtime (durable execution, a sandbox, approvals, channels, evals) comes in the box.

I read it with a strange double vision. In May I wrote a careful plan for almost exactly this, and then I deleted the code.

The plan was a Telegram bot: a FastMCP server, a per-engagement SQLite database, a scheduler on a Hetzner machine, a daily brief that arrived whether I asked for it or not. I was proud of it. Then I deleted the code and replaced the whole runtime with a markdown file that routes through the tools I already pay for. eve, this week, ships the Telegram channel I had been hand-rolling, as a single file.

So this is not a review. It is the view from someone who turned off this road on purpose, and what I think it means.

The industry is settling on a shape

Look at how eve lays an agent out.

agent/
  agent.ts          # the model it runs on
  instructions.md   # who it is
  tools/            # what it can do
  skills/           # what it knows
  subagents/        # who it delegates to
  channels/         # where it lives
  schedules/        # when it acts on its own

A file’s name and place in the tree are its definition.

That is the whole bet, and I think it is correct. Agents have a shape, and the shape is a folder in git. Vercel is not guessing at demand here. A year ago, agents triggered less than 3% of the deployments on Vercel. Now it is around 29%, and they expect half soon. When the work has clear per-action value the economics are not subtle either. Their sales agent costs about $5,000 a year to run, returns 32 times that, and one engineer maintains it part-time.

For that kind of job, where a machine should act around the clock and each action pays for itself, eve is a serious, well-made answer. I am not arguing with any of it.

I got to the same shape from the other side

Here is the part that gave me the double vision. I have been building this for client work, by hand, for months. One companion per engagement, and each one is a directory:

companions/<engagement>/
  SKILL.md      # who it is, and what it routes
  config.md     # the IDs it is scoped to
  persona.md    # the relationship
companion-core/
  conventions/  # what every companion knows
  modes/        # brief, prep, remember, reconcile

Same instinct: a file’s place is its meaning. I even hand-rolled the exact Telegram channel eve now ships as one line. Then I deleted it, because the channel and the schedule were the parts I did not want.

This week, prompted by the launch, I started pulling the shared shape out of my companions into one place. Vercel describes the same move for their hundred agents:

Today they live in one monorepo… Because they all share the same shape, a hundred agents run with the same tools and the same conventions as one.

That is what I am doing, at a smaller number, for the same reason. The convergence is real, and it is the best signal that the folder-in-git idea is right.

Where I turn off the road

The difference is one word. I do not build agents for this work. I build companions, and I keep them as a Claude Code skill: no runtime, no channels, no schedules.

An agent executes. It runs on its own clock, and the better it is, the less you are in the room. A companion accompanies. It runs beside you, when you call it, and the better it is, the sharper your own judgment gets.

For the kind of slow, relationship-shaped client work I do, the value was never autonomy. It was continuity. A companion that holds the thread and hands it back is worth a great deal. The same tool answering the client for me, in a voice that drifts a little further from theirs each week, is worth less than nothing.

The economics flip with the word too. An agent meters tokens on every run, and the bill grows with autonomy. A companion rides the subscription I already pay and spends nothing when I do not call it. The agent’s cost grows with use. The companion’s value grows with use. For the sales agent working leads at three in the morning, the first model is obviously right. For the work I do, the second one is.

The one thing I am stealing

eve is sharp about keeping an agent honest:

An agent your team depends on is production software, and a change to its instructions can break it as surely as a change to its code.

So they write evals and run them in CI as a deploy gate. I am taking that outright.

But it catches the wrong failure for a companion. An agent breaks when you change it. A companion breaks when the world changes under it and it does not notice: a new account appears, a service gets renamed, the plumbing moves to another host. I have proof in my own notes, where a companion’s architecture section went stale months ago and simply stayed stale.

So a companion needs a different pass. Not a regression gate, a freshness pass. Something that reconciles the world it has written down against the world as it is, and reports where they drifted. An agent is kept honest by tests of what it does. A companion is kept honest by checking whether it still knows your world.

What I kept

I did not lose the idea when I deleted the code. I lost the runtime, and the runtime turned out to be the part I did not need. eve is the right tool for the case where the machine should act. I build for the case where a person should act, better, with something quiet beside them that remembers.

Same folder of files. A different job, a different bill, a different way to stay true.

The word I chose was companion, not agent. eve, of all things, made me more sure of it.