Agent Zero

What decides this one for you is the web UI: a terminal, a browser and a running desktop in a single pane, so you watch the model work rather than reading a transcript afterwards. That visibility is worth a lot when an agent is clicking through software that was never meant to be automated, and there is very little else on this board that will do it.

Pick it for tasks a person would otherwise do by hand in a GUI. Pick OpenHands when the work lives in source control, because this is not built around diffs and pull requests.

The risk is self-modification. The project advertises that every prompt, tool and configuration file is inspectable and editable, and the agent works with a terminal in the same filesystem. The constraints you write are therefore data the agent can rewrite, and no separate control plane holds them. A long run can drift from its instructions with nothing left to compare against.

Keep the configuration on a read-only mount and diff it between runs. What it does right: the whole thing is packaged to run inside Docker rather than on the host, so the default posture is containment rather than convenience.

Two design choices deserve attention. 1. The browser is DOM-annotated, so page state reaches the model as structured elements rather than a screenshot or a wall of markup, which is the difference between grounding a click and guessing at one. 2. Delegation gives each subordinate agent its own context, bounding what a single task can read and preventing one long job from poisoning the parent transcript.

No benchmark is published and no verification stage is described, so effectiveness is asserted through demonstrations. The documentation is a repository README, which is thin for a system with this much surface area.

Nineteen thousand stars is genuine distribution, and none of it is monetised. The entity behind it is a Czech limited company, which suggests a founder-scale operation rather than a funded one. Computer use is also the capability every frontier lab is now shipping directly, so the value of an independent harness compresses each time a model vendor ships its own.

Moat: the desktop integration work, which is unglamorous and hard to replicate quickly. Likely outcome: a hosted version, or an acqui-hire by whoever wants the automation layer without building it. Position: use it, expect the roadmap to follow the labs.

The demo is impressive and the operations bill is the story. Sixty engineers each running a desktop container is infrastructure we would have to size, schedule and pay for, and the project offers no unattended mode, so it cannot be scheduled into the pipelines where that cost would be predictable. Single sign-on does not exist because the interface is a local web server.

Support is a small company with no contract on offer, which our security questionnaire treats as a single point of failure. Onboarding is easy, which is not the problem. Not yet.

This is built for people like me. MIT licence, a single docker run that mounts a0_usr so my state survives the image, and LiteLLM sitting in front of the provider layer so anything with an endpoint is fair game, including Ollama on the box under my desk. No key leaves the house if I do not want it to.

Both directions of MCP work, so it consumes my servers and exposes itself as one to other clients. That is the property that lets me wire it into things its authors never considered. Grudging note: I would like tests around the parts I keep patching.