Background Agents (Open-Inspect)

The deciding trait is the shape of the output. You hand over a task and what comes back is a pull request against a real branch, produced in an environment that had a shell, a browser and the language runtimes it needed. That is a different relationship from watching an agent type: you review a result instead of supervising a process.

It only works when the task was clear enough to hand a contractor, and it is self-hosted, so somebody owns the deployment. Pick it for a queue of small, specified work. Pick an interactive tool for anything still being figured out.

Those two properties are in tension. A system whose security model assumes every participant is trusted should not have entry points that outsiders can influence, and event-driven automation on alerts and repository events is exactly such an entry point: the content that starts a run can be written by whoever filed the issue or triggered the error. Prompt injection is not hypothetical when the prompt arrives from a stranger's stack trace.

What it does right is state its tenancy assumption in writing, so an operator can act on it.

1. Attribution embedded in version control history is durable in a way that an application log is not: it survives the tool being uninstalled, and it answers the accountability question inside the system reviewers already use. 2. That is the correct place to record it, and almost nobody in this category does.

2. Parallel work is fanned into separate sandboxes rather than threads in one environment, which keeps side effects from interleaving. No evaluation is published, so the architecture is documented and the throughput claim is untested.

Rebuilding a well-regarded internal system in the open is an extremely efficient way to acquire attention, and nearly three thousand stars is the proof. It is also a strategy with no second act built in: the demand it demonstrates is for a hosted product, and what exists is a repository somebody else has to deploy.

Moat: the reference-implementation position, which lasts until a funded competitor ships the managed version. Likely acquirer: none for the code, and a hiring conversation for the author. Position: run it, and expect the hosted alternative to arrive first.

Personal subscription tiers are the part that stops this at the purchasing stage. Access routed through an individual consumer plan has no volume agreement, no data processing terms I have reviewed and no way to attribute spend to a cost centre, and it usually violates the provider's own terms when a company uses it. That leaves fewer usable models than the list suggests.

Everything else fits: work arrives in the review process my teams already run and reaches them through the chat and issue tools they already use. Approved with conditions: contracted API access only, and no personal plans.

Giving the agent a complete environment rather than a sanitised tool list is the right call. It gets the same interpreters, the same version control and the same editor a person would have, which means anything I could script by hand it can also run. Permissive licence, my infrastructure, my control plane, no vendor in the middle.

The gap is protocol. There is no client here, so every tool server I already operate has to be reimplemented as something inside the sandbox instead of attached from outside. That is the one piece of work this design hands back to me.