UniHarness

The deciding trait is that where the agent works is a setting rather than a rewrite. The same agent code drives a machine on your desk, a virtual machine beside it or something rented far away, so you can start permissively while developing and tighten later without touching the logic. Most harnesses make that choice once, at the beginning, in code.

What you are getting is plumbing rather than a finished tool: no interface, no conveniences, a library and a protocol. Pick it if you are building. Pick a terminal agent if you wanted to start working today.

The default path is the problem. Offering a native target alongside two confined ones makes the weakest option the fastest to set up, requiring neither a virtual machine nor an account with a remote provider, and the row does not describe a warning or a policy preventing it. Developers choose the option that works immediately.

What it does right is make the choice visible. The target is a named component rather than an implicit consequence of how you launched it, so a reader of the configuration can see which machine is exposed.

1. Treating the computer as an interface rather than an ambient capability is the correct abstraction, and it is the one most harnesses skip: substituting the execution environment becomes a configuration change instead of a rewrite. 2. Excluding the harness's own credentials and source from the agent's view closes the most obvious self-escalation path, where an agent reads the keys that drive it.

2. No evaluation is published. The claim is architectural and can be verified by reading the protocol rather than by running a benchmark.

A company publishing infrastructure with no product attached is either recruiting, standard-setting or clearing an internal tool off a shelf, and the row gives me no way to tell which. The star count is respectable and unattached to anything that would fund a second year of maintenance.

Moat: the protocol idea, if anyone adopted it, which is the same conditional that ends most standards attempts. Likely path: the abstraction is copied by a project with users and this stays the citation. Position: read the design, borrow it, do not wait for a roadmap.

The remote execution option is the one that would matter to us and it introduces a vendor. Source leaving our estate to be worked on inside somebody else's environment is a data-residency question with a contract attached, and this row hands me the dependency without the paperwork that would resolve it.

Otherwise: no identity integration, no provisioning, no audit record, and a Python library rather than a product. It does run headless, so it could sit in delivery tooling. Approved with conditions: the local virtual machine target only, until the remote provider clears review.

Using the virtualisation I already have rather than shipping a container runtime is the right instinct. A local virtual machine gives me a real boundary without a new daemon, a new image registry or a new thing to keep patched, and the permissive licence means the whole protocol is mine to extend with a target of my own.

The omissions are the usual pair. No MCP client, so my servers are invisible to any agent built on this, and no local endpoint for the model, so the isolated computer is talking to a cloud the whole time it works.