OpenHands is now a control center for agents working across real repositories

01Start with the repository as it exists now

OpenHands has changed shape, and a useful review has to begin there. The current repository README presents Agent Canvas as a self-hosted developer control center for coding agents and automations. It can run the open-source OpenHands agent, but it is also designed to work with other agents through compatible protocols and backends. The current quick-start recommends Agent Canvas, while documentation for the older local GUI and CLI is grouped under deprecated or legacy material. Articles that describe only the earlier interface no longer capture the main repository.

This newer framing is important because a control center has different responsibilities from an agent library. It needs to start and resume conversations, connect to execution environments, retain enough state for ongoing work, and coordinate triggers or integrations. It also becomes a place where multiple trust boundaries meet. Source code, model providers, agent processes, GitHub, Slack, and other services may all be reachable through one operational surface. The feature set is attractive precisely because the system can do consequential work, so the deployment model cannot be treated as an afterthought.

02What an agent can actually do

A coding agent becomes materially different from a conversational assistant when it receives an environment in which it can run commands, edit files, and start servers. OpenHands documentation calls that environment a sandbox. Within it, the agent can inspect a repository, search for relevant code, make changes, run test or lint commands, and observe the result. That action loop is the reason the project is useful for maintenance work such as dependency changes, issue investigation, test repair, or repetitive repository chores.

Execution does not make the output correct. It makes the work inspectable. A serious evaluation should look for the sequence of files read, commands issued, failures encountered, and changes produced. The best tasks have an objective finish condition, such as a focused test suite or a generated artifact with a known schema. Vague requests encourage broad edits and weak stopping criteria. OpenHands can provide the workspace and transcript, but the repository owner must still define what evidence counts as completion.

03Docker, process, and remote are not interchangeable

The official sandbox overview lists Docker, process, and remote providers. Docker is the recommended local option and runs the agent server inside a container, which gives useful separation from the host. Process mode runs as a regular host process and the documentation labels it unsafe but fast because there is no container isolation. Remote mode moves execution to another environment and is used by managed or hosted setups. The same interface can sit above all three, but their failure and exposure profiles are plainly different.

A container is not a complete security policy. Mounted directories remain available inside the container, passed environment variables remain readable to the process, and outbound network access can carry data elsewhere. A remote sandbox introduces its own image, patching, tenancy, identity, and cleanup questions. Teams should decide what the agent can mount, which commands it may execute, which domains it may contact, how long an environment survives, and how credentials are injected and revoked. Provider selection is a security decision before it is a performance choice.

• Use a disposable checkout and a narrow credential set for the first evaluation.
• Prefer container or remote isolation over host process execution for untrusted tasks.
• Record who can start an agent, approve external actions, and retrieve its transcript.

04Agent Canvas separates the desk from the worker

One of the more useful ideas in the current repository is the separation between the Agent Canvas front end and agent backends. The README describes running agents locally, in Docker, on virtual machines, or within company infrastructure, with optional managed services as additional choices. A user can focus on the task while the execution location changes. That makes the interface relevant to teams that want a common operating surface without forcing every repository or security zone into the same machine.

The separation also creates a protocol boundary worth understanding. State has to survive reconnects, backend capabilities need to be represented accurately, and errors must travel back to the person supervising the task. When a team mixes agents from different vendors, similar buttons do not guarantee identical permission, context, or tool semantics. A disciplined rollout starts with one backend, documents its capabilities, and adds another only after the team knows how transcripts, artifacts, cancellation, and credential handling behave.

05Automations turn a session into an operating system concern

The repository positions automations as a way to trigger recurring or event-driven work through services such as GitHub and Slack. This is a meaningful step beyond opening a conversation manually. A scheduled report can continue when a laptop is closed, and a webhook can start work when an issue or repository event arrives. The upside is continuity. The downside is that an agent can now act when no developer is watching the first command.

Every automation needs a narrow trigger, an input schema, an execution identity, a timeout, and a terminal report. It should also say which outputs are drafts and which actions may change an external system. A dependency-update automation, for example, can reasonably create a branch and run tests, while merging or publishing should remain separately authorized. Idempotency matters because webhook delivery can repeat. OpenHands supplies the automation surface, but production safety comes from designing the job as carefully as any other background worker.

06Model choice changes cost and behavior, not authority

OpenHands supports bringing a model rather than binding the repository to a single provider. That flexibility is useful for comparing capability, latency, price, regional availability, and data-handling terms. It can also complicate evaluation because a task that succeeds with one model may fail with another even when the agent tools are unchanged. Reproducible tests should therefore record the model identifier, major configuration choices, repository revision, and sandbox image alongside the result.

Changing the model must not silently change the agent's authority. Permissions should be enforced by the control plane and execution environment, not by a prompt asking the model to be careful. A more capable model may choose better files or recover from errors more effectively, but it should still encounter the same network restrictions, mount boundaries, and approval gates. Keeping capability separate from authority is the foundation for comparing models without turning each experiment into a new security design.

07The real evaluation unit is a reviewed task

A flashy demo can show that an agent writes code. It cannot establish that the system improves a team's delivery process. A better evaluation uses a set of representative tasks with known outcomes: repair a contained defect, add a validation rule with tests, update a dependency, explain a failing build without editing, and prepare a small documentation correction. Measure whether the agent found the right context, respected scope, produced a reviewable diff, ran the agreed checks, and reported uncertainty honestly.

Human review remains central. Generated code can be syntactically valid while weakening authorization, swallowing an error, or changing an interface another service depends on. The transcript helps a reviewer see the route taken, but it does not replace reading the final diff and test output. Teams should also track abandoned runs and costly loops, not only successful completions. OpenHands is most compelling when it makes delegated work observable enough to improve, constrain, and sometimes reject.

08When OpenHands earns a place in the stack

OpenHands deserves consideration when a team wants agents to do bounded repository work in persistent, selectable environments and wants one surface for conversations plus automation. It is especially relevant to platform engineers studying how local, container, and remote agent execution can coexist. The MIT license keeps the source approachable, and the official documentation exposes the major sandbox tradeoffs rather than pretending every execution mode is equally safe.

It is excessive for a developer who only wants completion or an occasional suggested patch. It is also a poor fit for organizations that cannot yet control secrets, isolate workloads, or review agent output. The current Agent Canvas direction widens the project's usefulness, but it also widens the operations bill. Adopt it as infrastructure for supervised engineering work, not as a promise that unattended agents can own a repository without clear limits.