Summary
Add a reusable approval-review capability that can evaluate a proposed agent action before Junior performs it. This is not needed for current tools yet, but gives us a boundary for future autonomous or dangerous actions.
This would be similar in spirit to Codex Auto-review/Guardian: it runs only when an action reaches an approval boundary, not on every user message or tool call.
Motivation
As Junior becomes more autonomous, some actions may need an explicit safety or authorization decision before execution. Examples include:
- Confirming creation or modification of a scheduled task
- Performing destructive or difficult-to-reverse operations
- Sending data to a new external destination
- Making broad permission or configuration changes
- Executing an action whose side effects are only indirectly implied by the user request
We do not have an immediate product requirement for this today, but adding these actions later without a common review boundary could lead to approval logic being implemented independently in each feature.
Proposed Shape
Introduce a small approval-review interface around exact proposed actions:
- A feature constructs a structured description of the action, its target, and material side effects.
- Deterministic policy decides whether the action needs review.
- A reviewer receives the exact action plus relevant conversation and actor context.
- The reviewer returns an explicit allow/deny decision with a short rationale.
- The action executes only after an allow decision; denial is returned to the agent as a normal rejected-action result.
The reviewer could initially be user confirmation. A model-based reviewer could be added later for cases where authorization and risk must be interpreted from conversation context.
Design Constraints
- Do not run review logic on every input; invoke it only at explicit action boundaries.
- Review the exact action and payload rather than a vague desired outcome.
- Keep deterministic policy checks outside the model.
- Propagate actor, destination, conversation, and authorization context explicitly.
- Fail closed if a required review cannot complete.
- Make denial non-circumventable: the agent should not retry an equivalent action through a different mechanism.
- Preserve an audit record of the request, decision, rationale, and reviewer.
- Allow future user override only for the exact denied action after the risk is presented.
Initial Scope
Capture the contract and likely integration point only. Do not wire existing tools through it until a concrete action, such as scheduled-task registration, needs the capability.
Open Questions
- Should the contract live alongside tool execution, durable task dispatch, or as a small shared service?
- Which actions require deterministic user confirmation versus optional model review?
- How should approvals work when an action executes asynchronously or on a later schedule?
- What context must be persisted so a delayed action can be reviewed against the original user authorization?
- How should Slack and local-agent surfaces present and resume denied or pending actions?
Summary
Add a reusable approval-review capability that can evaluate a proposed agent action before Junior performs it. This is not needed for current tools yet, but gives us a boundary for future autonomous or dangerous actions.
This would be similar in spirit to Codex Auto-review/Guardian: it runs only when an action reaches an approval boundary, not on every user message or tool call.
Motivation
As Junior becomes more autonomous, some actions may need an explicit safety or authorization decision before execution. Examples include:
We do not have an immediate product requirement for this today, but adding these actions later without a common review boundary could lead to approval logic being implemented independently in each feature.
Proposed Shape
Introduce a small approval-review interface around exact proposed actions:
The reviewer could initially be user confirmation. A model-based reviewer could be added later for cases where authorization and risk must be interpreted from conversation context.
Design Constraints
Initial Scope
Capture the contract and likely integration point only. Do not wire existing tools through it until a concrete action, such as scheduled-task registration, needs the capability.
Open Questions