A practical build pattern for personal AI agents: capture the approval, store the consent receipt, compare live state before execution, and re-prompt when the facts no longer match.
Use-case guide
Approval queues are good at asking the user for a decision. They are weaker at proving that the decision is still valid when the agent resumes work later. The fix is to wire stale consent checks directly into the queue output and the tool-dispatch path.
When the user approves a queued action, write a receipt with the visible evidence, allowed action, excluded action, recipient, account, channel, expiry, and state fingerprint. The receipt should be structured enough for an agent to compare later, not just a chat transcript.
For a text message AI assistant, the receipt might include message draft, recipient, thread id, tone constraints, and the exact condition that allows sending.
Recipient changed, amount changed, page changed, expiry passed, user edited context, or tool class changed.
The guard must run before the tool call, not after the action has already happened.
Fresh approval should show what changed and why the old receipt no longer applies.
A computer-use cache can preserve screenshot and page state for browser tasks. For AI agent website-building, the receipt should include page diff, source list, build output, target domain, and rollback route before deployment.
Build sequence
This sequence keeps approval UX simple while making the execution path stricter.
Send only consequential, ambiguous, public, paid, irreversible, or policy-borderline actions into the approval queue.
Convert the approval into structured fields that can be compared later: evidence, scope, expiry, actor, recipient, and environment.
Before dispatch, compute the current state from the message thread, browser, file, account, generated artifact, or task memory.
If the live state differs in a protected field, stop the run and request fresh approval with the changed facts highlighted.
After execution, attach receipt id, log range, replay link, output, and rollback owner so future resumes can enforce the same guard.
Operator note
If an agent can resume after a queue approval, it needs a fresh-state check before touching the outside world.
FAQ
The pattern is simple, but it needs to be built into the execution path rather than left as policy prose.
Put it between planning and tool dispatch. The queue records permission; the guard decides whether that permission still applies to the actual tool call.
Changes to recipient, account, amount, domain, page state, message thread, generated output, privacy boundary, time window, or tool capability should trigger fresh approval.
Yes, but it is easier when approval receipts are structured from the start. A transcript-only approval history will usually need a migration step.
The NIST AI Risk Management Framework helps frame governance controls, and the OWASP Top 10 for LLM Applications helps frame unsafe action and authorization risk.
Wire the queue to the guard, wire the guard to dispatch, and wire the result back to the receipt. That is the control loop personal AI agents need.