Busabase × OpenHandsKnowledge base for OpenHands
OpenHands can run software tasks locally, in sandboxes, or through a remote Agent Server. Busabase records what the run actually established, who reviewed it, and which downstream workflow may rely on the result.
Current OpenHands surfaces
One ecosystem has several runtimes. The task record should identify the one that ran.
OpenHands now separates Agent Canvas, the Software Agent SDK and Agent Server, Cloud, Enterprise, and Sandbox Server. The SDK defines conversations, tools, events, workspaces, and security policies; clients and deployment layers consume those interfaces.
Control center
Browser client for conversations and automations across backends.
Execution API
Agent behavior plus REST/WebSocket access to conversations and workspaces.
Managed operation
Hosted execution, collaboration, access control, usage, and budgets.
Isolation plane
Creates and manages environments that host Agent Server.
Event history versus accepted outcome
A persistent conversation proves what happened. It does not decide what became true.
The OpenHands SDK can persist message history, actions, observations, tool outputs, execution state, metrics, workspace context, and activated skills. Its event log is excellent execution evidence. A business or release state still needs a named owner and a decision outside the run.
Chronological execution evidence
Append-only messages, actions, observations, and state changes
Produced artifact
Files, patches, tests, reports, and commands in the chosen environment
Reviewed operational meaning
Outcome, evidence references, owner, decision, and downstream state
A run ledger
Track the goal, execution boundary, evidence, and decision as separate fields.
Do not paste an entire event stream into one long text field. Link the persisted conversation and extract the small set of facts required to compare runs, investigate failures, and hand accepted work to another system.
| Field | Meaning |
|---|---|
| run_id | Stable link to the OpenHands conversation or automation run |
| goal | Outcome the run was asked to produce |
| workspace_ref | Repository, revision, sandbox, and environment |
| execution_state | Queued, running, paused, waiting, finished, error, or stuck |
| evidence_refs | Events, files, commits, test logs, and observations |
| proposed_outcome | Agent's concise interpretation of the result |
| decision | Accepted, conditional, rejected, rerun, or superseded |
| owner | Person accountable for that decision |
| next_action | Downstream work unlocked by acceptance |
Action safety and data authority
Confirming a risky command and accepting a task result protect different boundaries.
OpenHands separates confirmation policy from security analysis. AlwaysConfirm, NeverConfirm, and ConfirmRisky determine when execution pauses; analyzers classify action risk. Busabase review begins after or alongside that control and asks whether the run's interpretation should update a canonical record.
Direct SDK execute_tool() calls bypass the normal agent loop's analyzer and confirmation checks. Callers must apply their own safeguards.
Evidence-driven state transitions
Let events propose status changes without letting delivery logs make the decision.
A webhook or callback can open a Change Request when an OpenHands run changes state. The delivery log proves the event arrived. Review verifies whether the event, workspace output, and evidence justify the proposed operational state.
| Runtime event | Record proposal | Human job |
|---|---|---|
| conversation.finished | Attach final response and evidence refs | Propose ready_for_review |
| conversation.error | Attach error and last successful observation | Propose blocked |
| waiting_for_confirmation | Attach pending action and risk context | Assign human decision |
| rerun.completed | Link prior run and changed inputs | Propose superseding outcome |
Connect the maintained surface
Use current Skills and MCP docs; keep legacy runtime settings out of the workflow.
OpenHands supports AGENTS.md, portable Agent Skills, project and user skill scopes, and configurable MCP tools. The current product architecture is based on Agent Canvas and the Software Agent SDK/Agent Server. Follow the maintained Busabase connection page for CLI and MCP setup, then verify which backend and workspace own the run.
Questions about autonomous run records
OpenHands knowledge base FAQ
Does Busabase replace OpenHands conversation persistence?
No. OpenHands persistence stores the event history and execution state needed to resume or inspect a conversation. Busabase stores the reviewed interpretation that other teams and systems may rely on.
Should every OpenHands event become a record?
No. Most events remain in the run log. Create or update a record only for meaningful state transitions, exceptions, evidence, or outcomes that need ownership outside the runtime.
Is a finished conversation an accepted result?
No. Finished describes execution state. Acceptance depends on the goal, evidence, tests, business impact, and responsible reviewer.
Can OpenHands use Busabase as an Agent Skill?
OpenHands supports the Agent Skills specification and project/user scopes. A Skill can teach the workflow and invoke supported tools, but it does not grant permissions by itself. Access still comes from the configured environment and credential.
Which OpenHands configuration should the page use?
Use current Agent Canvas, SDK/Agent Server, Cloud/Enterprise, and current Skills/MCP documentation. Avoid treating legacy V0 config.toml or trajectory settings as universal V1 behavior.
Start with one autonomous task
Give the next OpenHands run an explicit acceptance contract.
Define the goal, workspace, evidence fields, and reviewer before execution. Let OpenHands produce the work and event trail; let the owner decide which outcome becomes reusable state.