Agents Need a Computer of Their Own

The important shift in coding agents did not happen in a chat box.

It happened when agents got a harness.

OpenAI Codex, Claude Code, Open Code, Cursor, and a long list of local tools all point in the same direction. A useful coding agent needs the repo. It needs a shell. It needs tests, logs, package managers, framework conventions, and enough room to inspect before it edits. The best agents are not autocomplete with better manners. They are workers inside a development environment.

That part is settled.

The next question is where that environment lives, how long it lasts, who can steer it, and how the team keeps quality high when more people can create software changes.

That is where agents need a computer of their own.

Not because local harnesses are wrong. They are right. But serious team workflows need the same idea with durability, isolation, collaboration, secure shared context, and a clean handoff into review.

What local harnesses got right

Local agent harnesses work because they meet software on its own terms.

They do not ask the model to guess from a prompt. They let it read the codebase. They let it run commands. They let it edit files, inspect errors, and check its work. That is why developers adopted them so quickly. The interaction feels much closer to pairing with someone who can operate the project than asking a model to produce code-shaped advice.

For focused developer work, local is excellent. You are already there. Your editor is open. Your branch exists. The app may already be running. The agent can act while you watch, correct, and commit.

But the local harness is usually tied to one person’s machine and one person’s attention. That is a natural limit.

The moment the agent should run because CI failed, or because a review comment came in, or because a production error appeared overnight, the shape changes. The work should not depend on a developer’s laptop being open, clean, current, and available.

The moment a designer or product lead wants to contribute directly, the shape changes even more.

They should not have to install the right Node version, copy secrets, start three services, switch worktrees, remember which branch is safe, and learn the team’s Git habits before they can make a meaningful change. That work is invisible when you already know it. It is a wall when you do not.

Agents can lower that wall, but only if the development environment is already there.

A computer per run

In Trevize, every session and loop boots a real development environment for that run.

That means the agent gets the basics a developer would expect: source code, shell access, local services, Docker Compose when the repo needs it, and a browser through a VNC desktop for UI work. It can run the app. It can watch logs. It can open the preview. It can check the diff before it asks anyone to review it.

The point is not that the cloud is magically better than your laptop. The point is that the run has a workspace that belongs to the work, not to the human currently supervising it.

A checkout redesign can have its own app preview. A Sentry fix can have its own branch and test run. A dependency upgrade can run in isolation from the feature you are building locally. A risky refactor can happen without filling your working tree with half-finished edits.

That matters more as systems spread across repositories. Modern products are rarely one repo and one process. The frontend may live in one place, the API in another, background jobs somewhere else, with a database and a queue between them. Trevize supports preview processes across multiple repositories, so the run can work against the product as the team actually builds it.

Secrets are part of that too. Local setup often turns into a quiet ritual of copying values, asking for access, or running with half the real environment missing. In Trevize, secrets are shared securely at the workspace or project level and injected at runtime. They never touch the sandbox disk. The agent can use what it needs to run the software, without turning every contributor into a secrets administrator.

Software work is messy. Giving each run its own computer contains the mess.

Contribution should not require local setup

Developers are used to the setup tax. They may not enjoy it, but they can usually pay it.

Designers, product leads, support engineers, and domain experts should not have to.

A designer might notice that an empty state reads badly in the real product. A product lead might want to tighten the onboarding flow after watching users struggle. A support engineer might know exactly which copy would prevent the same ticket from coming in again. These are real software contributions. Today they often become comments, mockups, tickets, and meetings because the path from insight to working change runs through a local development environment.

That is a strange bottleneck.

In Trevize, those people can join a session, describe the change, watch the preview, and steer the agent while it works. They do not need to know which repo owns the page. They do not need to switch branches. They do not need to understand worktrees. They can stay close to the product behavior and the agent can handle the mechanical parts of the change.

This does not remove engineers from the loop. It removes local setup as the price of admission.

Durability is the missing layer

The computer matters, but it is only half the story.

The other half is the workflow around it.

Local harnesses are often session-shaped. You start them, steer them, and stop when the task is done. That is perfect for many jobs. It is not enough for work that should keep moving after you close the lid.

A durable workflow gives the run memory and shape. It knows why it started. It knows which signal triggered it. It records what it tried, which commands ran, which tests passed, which files changed, and where the work stopped. If the run needs to resume, it resumes from the workspace and the workflow state, not from a vague summary.

It also lets the work survive ordinary failure. Model providers have outages. Agents run into usage limits. A long task can hit a cap halfway through a refactor. A preview process can crash. A durable workflow can pause, retry, swap steps, or continue later from the last good state. Without that layer, the team is left with a half-edited branch and a transcript explaining what might have happened.

This is what makes background work possible.

A failing check can trigger a loop. A review comment can trigger a loop. A new Linear issue can trigger a loop. A runtime error can trigger a loop. The agent is not waiting for someone to paste context into a terminal. The workflow already knows what the signal means and what kind of run to start.

In Trevize, blueprints define those loops. A blueprint sets the steps once: analyze the signal, inspect the codebase, make the change, verify it, and open a pull request. Each run gets its own environment. Each run follows the same shape. The details vary, but the handoff stays predictable.

That repeatability is what turns a clever harness into team infrastructure.

It also gives teams a place to encode judgment.

Collaboration needs shared state

There is another reason local-only work hits a wall: real product work is multiplayer.

One developer may understand the code path. A designer may care about the edge case in the UI. A product lead may know why the odd behavior exists. The agent needs a place where those people can steer the same run without passing screenshots and terminal output around.

That is what Trevize sessions are for.

In a session, the team and the agent share one thread and one workspace. People can join while the agent works, ask for a change, watch the app preview update, and compare the result against the goal. The important part is not the chat surface. The important part is that the conversation, files, preview, commands, and diff all belong to the same durable run.

Shared state also makes forking useful.

If the team is not sure which approach wins, fork the session. Try a one-page checkout in one workspace and keep the two-step flow in another. Let both agents run. Compare the previews. Keep the branch that works. Drop the one that does not.

That is much harder when the work is trapped inside one person’s local process. It is natural when runs are first-class objects with their own computers.

Blueprints are quality control

When only engineers can create pull requests, a lot of quality control is implicit.

People know the conventions. They know which tests matter. They know when a change is risky. They know which files should make them nervous. Even then, teams still miss things.

When agents make it possible for more people to create software changes, that implicit layer is not enough. You do not want an uncontrollable pile of pull requests landing in engineering’s lap, each with a different shape, a different level of verification, and no clear signal about what needs attention.

This is one of the main reasons Trevize has blueprints.

A blueprint is not just a prompt template. It is a quality gate for a category of work. The team can define how the agent should investigate, which checks it must run, what evidence it should include, and when it should stop. A copy change, a UI tweak, a dependency update, and a production bug fix should not all follow the same path. Blueprints let teams make those paths explicit.

They also make review faster.

If a blueprint requires tests, preview screenshots, lint output, or a written note about the affected repositories, reviewers do not have to ask for the same basics every time. If the run labels the pull request with a risk assessment, reviewers can sort the queue with more context. A low-risk copy fix and a high-risk auth change should not feel identical in GitHub.

Local harnesses can do some of this when a careful developer drives them. The hard part is doing it consistently across everyone, every repo, and every kind of contributor. Blueprints move that discipline from personal habit into the workflow.

The merge boundary still matters

More durable does not mean less controlled.

An agent with a real computer can do a lot. It can edit files, run tests, open browsers, create branches, and respond to review comments. That does not mean it should merge its own work.

Trevize draws the boundary at the pull request. Loops and sessions both stop there. The agent can prepare the change and show its checks. A human reviews it and decides what ships.

That boundary is not just a safety feature. It is what lets agents fit into the workflow teams already trust. GitHub pull requests already carry diffs, comments, checks, approvals, and history. Trevize uses that existing review layer instead of inventing a new path around it.

When a reviewer asks for changes, that comment can become another signal. The agent can reopen the run, update the branch, verify again, and push the revision. The human keeps judgment. The agent keeps momentum.

The practical test changed

The old test was whether the model could write code.

The current test is whether the harness can operate a repo.

The next test is whether the work can survive as part of the team.

Can it run when triggered by CI, an issue, an error, or a review comment? Can it keep its state through outages, limits, and interrupted runs? Can someone else join and steer it? Can the team fork the approach without trampling the original? Can the output land as a normal pull request, with checks and review intact?

And just as important: can a designer or product lead contribute without becoming a part-time build engineer? Can engineering define the quality bar once, then trust every run to meet it before review?

That is the layer Trevize is building.

Agents need a computer because real software work happens in a real environment. They need durable workflows because team work has memory, signals, handoffs, and review. They need blueprints because wider contribution only works when quality control gets stronger, not weaker.

Local harnesses proved the model. Trevize makes it durable enough to run around the clock, collaborative enough for the whole product team, and bounded enough that humans still decide what ships.