OpenHands / OpenHands/software-agent-sdk
[Feature]: Optional reviewer-facing evidence gates for software-agent actions
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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