OpenHands / OpenHands/software-agent-sdk

[Feature]: Optional reviewer-facing evidence gates for software-agent actions

Open
#4,259 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
1.1k
Forks
539
Avg merge
1d 19h
Merged PRs (30d)
137

Description

Is there an existing feature request for this?
  • I have searched existing issues and feature requests, and this is not a duplicate.
Problem or Use Case

OpenHands-style agents can write code, use command lines, browse, and operate in sandboxed environments. The final diff, terminal result, or browser outcome can be reviewed, but it can still be hard to answer a separate reviewer question:

The agent produced an output — but was it allowed to take that action?

This matters for higher-impact software-agent actions such as shell commands, file modifications, workflow/config changes, browser actions, or tool calls where a reviewer may want to see what evidence was checked before the action happened.

The use case is not to replace sandboxing, evals, or code review. It is to add a lightweight reviewer-facing audit artifact that makes agent action decisions easier to inspect and replay.

Proposed Solution

Add an optional reviewer-facing evidence-gate artifact around agent actions.

A possible flow:

agent proposes action
→ optional pre-action evidence gate
→ ALLOW / BLOCK / ESCALATE
→ reviewer-facing stop reasons + checked evidence
→ tool call / shell step / browser action / code change

The artifact could include:

action type,

triggering task,

checked evidence or context fields,

decision: ALLOW / BLOCK / ESCALATE,

stop reason if blocked or escalated,

replayable decision record.

This could start as a lightweight trace/log/export artifact rather than a hard runtime enforcement feature. The goal is to help reviewers inspect why an agent action was considered acceptable, risky, or requiring escalation.

Alternatives Considered

A reviewer can currently inspect the final diff, terminal logs, browser results, or conversation history. Those are useful, but they do not always provide a structured answer to whether the agent had enough evidence or permission to take a specific action.

Other alternatives include custom wrappers, external policy tools, or manual review checklists. The limitation is that they are usually inconsistent, not replayable, and not connected to the actual agent action trace.

Sandboxing, evals, and code review are still important, but they solve a different problem. This proposal is only about an optional reviewer-facing decision artifact around agent actions.

Priority / Severity

Medium - Would improve experience

Estimated Scope

Unknown - Not sure about the technical complexity

Feature Area

Agent / AI behavior

Technical Implementation Ideas (Optional)

A minimal version could start as an optional structured trace event emitted before selected high-impact actions. It does not need to block execution by default. The event could later be exported in logs or displayed in a reviewer UI.

Additional Context

Related experimental project: https://github.com/safal207/pythiaLabs

Example snapshot output:
https://github.com/safal207/pythiaLabs/blob/main/docs/examples/agent-action-audit-snapshot-example.md

Workflow intake template:
https://github.com/safal207/pythiaLabs/blob/main/docs/examples/agent-action-workflow-intake-template.md

PythiaLabs explores deterministic evidence gates for high-risk AI-agent actions and replayable reviewer artifacts. This issue is only a question/proposal about whether a similar optional artifact would be useful around OpenHands-style workflows.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the linked docs/examples/agent-action-audit-snapshot-example.md and docs/examples/agent-action-workflow-intake-template.md to understand the proposed artifact and workflow. Then identify the SDK action-trace entry points that could emit an optional pre-action event. Done means the scope is agreed and a replayable reviewer-facing decision record is defined without making enforcement mandatory by default.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
ai
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.