Automation Multiplies Both Reach and Responsibility
OpenHands Agent Canvas does more than keep a person connected to a coding agent: it can also help work begin from a schedule or an external event. This chapter follows an automation from trigger through permission, dispatch, agent execution, run history, and linked conversation, then compares the deployment and extension choices that determine what unattended work can reach. The practical judgment is not whether automation is convenient, but whether its repeatability is matched by enough authority control, visibility, and evidence.
An automation is a trigger-driven conversation lifecycle
A chat begins with a person’s message. An automation begins with a condition that may occur when no one is watching: a scheduled time, a webhook event, or another event pattern accepted by the service. The resulting work may still become an agent conversation, but it has more stages before and after the agent receives a prompt.
The Automation model represents those stages explicitly. A time-based trigger carries a schedule and timezone. An event trigger carries a source, an event key or pattern, and optionally a filter over the webhook payload. The automation record then binds that trigger to a prompt and, when needed, a repository, branch, model, plugins, timeout, and enabled state. The record is not itself an agent process. It is a durable instruction about when and how a future run may be dispatched.
Canvas provides the operator surface for that instruction. The automations view can check backend health before fetching records, group or filter them, show whether they are enabled, and expose actions such as edit, delete, run now, import, and export. A user can inspect recent runs and open a linked conversation. Those controls make an unattended process legible, but the scheduling and webhook machinery remains in the Automation service, while the Agent Server and SDK execute the conversation it dispatches.
Permission and enablement add a distinction that chat often hides. A user may have general permission to manage automations, while the creator of a particular automation can retain an owner-level ability to edit it. A non-creator may be allowed to turn an enabled automation off but not turn it back on. The interface therefore does not treat “can see this record” and “can cause this record to run” as the same authority. The exact authorization policy belongs to the backend, but Canvas reflects the difference in its operator actions.
A run then acquires its own lifecycle. It can be pending, running, completed, failed, cancelled, or skipped. It may carry a linked conversation ID, a command ID for the execution path, error detail, phase information, timestamps, and sometimes accumulated LLM cost. A phase label can tell an operator that a run is provisioning a sandbox or performing another intermediate operation. That information is more useful than a single spinner because it helps locate where a delayed or failed transition occurred.
The link to a conversation is especially important. It lets the operator inspect the work that a trigger caused through the same Canvas surface used for interactive sessions. But a linked conversation does not make the automation equivalent to a chat. The automation still has a trigger, an enabled state, a permission path, dispatch logic, and run history.