What this service solves
Let an assistant prepare a narrowly defined system change and put the decision in a person's hands. The approver sees the target record, proposed values, and the intended effect before allowing a low-risk write. Approval is tied to those exact details.
What you get
Reviewable action proposal
The approver can inspect the exact proposed change and accept or reject it before execution.
Action trace
Accepted, rejected, and failed decisions can be matched to the proposal and the destination's observed outcome.
What’s included
Constrain the tool action and permissions
Define the single allowed write, destination, and authorized fields. Limit the agent's permissions to the agreed scope.
Show the proposed change to an approver
Show the record and values in the approval step. Require fresh review if the proposal changes before execution.
Log accepted, rejected, and failed outcomes
Record whether approval was granted, rejected, or followed by a failed action. Make the result clear enough for the owner to investigate or follow the recovery instructions.
How implementation works
Define allowable action
Agree on permitted inputs, authorization, acceptance rules, and the exact change the assistant may propose.
Test review and execution paths
Exercise approved, rejected, changed, and failed proposals in the test system, including the expected response to an interrupted write.
Evaluate and hand off
Review the evidence and hand off the action limits, decision steps, and how to inspect the trace.
Technical considerations
- Permission boundary
- Agree on one write operation, its allowed record and fields, and the credentials used in the authorized test environment. Confirm the destination supports the required permission boundary before committing to the action design.
- Approval and execution records
- Bind the human decision to the exact proposal details. Keep the approval outcome distinct from the destination outcome so an operator can tell whether a failure happened before or after approval.
Systems, inputs & prerequisites
A test system, approval owner, approved scope, sample inputs, and rollback instructions.
- A test destination, allowed record and fields, the approver's role, and recovery or rollback instructions.
- Sample requests that should succeed, requests that should be rejected, and an example of a change made while approval is pending.
Starting scope & pricing
Base scope
One agent, up to three skills, one low-risk approved write operation, and one destination.
Illustrative workflow
Propose
The assistant identifies the allowed task and shows the proposed owner.
Approve
A designated person verifies the record and proposed owner.
Write & log
The authorized change runs against the chosen destination and returns a recorded outcome.
Validation & handover
- Review a representative proposal and verify that the allowed record and field values shown to the approver match the write observed in the test destination.
- Exercise a rejected proposal and one that changes before execution. Confirm the rejected proposal leaves the destination untouched and changed details require a new decision.
- Observe a destination failure and review the proposal, decision, and outcome together. Walk the operator through checking destination state before using the approved recovery path.
Limitations & possible extras
Limitations
Additional write operations, destinations, and broad or consequential permissions require their own review. Platform and model usage may be billed separately.
Approval must be bound to the exact proposed action. Broad access or consequential writes require separate scoping.
Possible extras
Model and platform usage, additional write paths, and security review.
Questions about this service
Can an approved proposal be edited before it runs?
A change to the proposed record or values creates a new decision for the approver. The previous approval applies only to its reviewed proposal.
What if the destination record changes while approval is pending?
Agree on how to detect a relevant change and whether the proposal should expire or return for review. The check depends on the state or version information the destination exposes.
What should the operator do if execution times out?
Use the action trace and verify the destination before retrying. If the result remains unclear, follow the agreed recovery instructions with the owner.
Does adding a second destination use one of the three skills?
The starting scope allows up to three skills for one agent, one low-risk approved write, and one destination. A separate destination or write operation requires its own review.