The situation and the decision
Original fictional worked example, not a client project or deployed system. A service team wants an assistant to move a booking after reading a customer request. The calendar can update successfully while the notification fails; a retry could create a duplicate change.
Decision: begin with a draft-and-confirm pilot. The assistant proposes a specific change. An authenticated person reviews it; a deterministic service checks authority and current state before making the write. Fully autonomous changes remain outside this example’s pilot.
Why this boundary
- Suggestion only avoids external writes but leaves the user to repeat the change manually. It is a useful fallback if the action service is unavailable.
- Draft-and-confirm adds a review step while testing whether the assistant understands the request and can propose the right target and change. This is the selected pilot boundary.
- Autonomous action removes the review step but needs stronger evidence about authority, ambiguity, conflicts and recovery than this example assumes. It is deferred, not declared impossible.
Authority stays outside the model
The model receives only the minimum booking context needed to propose a change. It cannot select an arbitrary customer account or grant itself a new permission. Retrieved messages and tool results are data, not instructions to expand its authority.
- Authenticate the requester and derive the permitted account and booking from the application session. Do not trust model-supplied tenant identifiers.
- Expose narrow tools such as read_booking and propose_booking_change, rather than a general SQL or arbitrary HTTP tool.
- The action service validates ownership, allowed fields and current permissions on every write. A user’s confirmation cannot authorise an action they are not permitted to perform.
Approve the exact change, not an open-ended instruction
Show the existing booking, proposed slot, affected person, notification consequence and any unresolved question. Bind approval to that proposal and its booking version. Recheck availability at commit time; if the booking changed after the preview, invalidate the approval and ask the person to review the new situation.
Separate a committed change from a delivered notification
- Create an operation identifier and an idempotency key for the approved change. A repeated request should return the known operation state rather than repeat the write.
- Record the booking change and pending notification together where the application supports a transaction/outbox. Notification delivery can then retry independently.
- Expose states such as proposed, awaiting approval, committed, notification pending, completed and needs review. “Completed” requires the defined confirmation evidence, not a confident model message.
Recover without hiding uncertainty
If the write times out, query the operation state before retrying. If the booking committed but the notification failed, keep the booking state visible and retry only the notification under a bounded policy. After the retry limit, show a manual follow-up action and its owner.
If an undo is possible, preview the compensating change and require fresh authority and confirmation; do not assume cancellation reverses downstream effects. If status cannot be determined, stop automated action and report the uncertainty to a person rather than claiming success.
Evidence required before widening the pilot
- Evaluate ambiguous requests, wrong-account attempts, stale approvals, unavailable slots, prompt injection in retrieved text, duplicate clicks and timeouts after a committed write.
- Check proposal correctness and permission enforcement separately from conversational fluency. Treat any unauthorised write as a release blocker.
- Use synthetic bookings and dry runs first. Agree acceptance criteria, review ownership, a bounded retry policy and a kill switch before a limited pilot; this example invents no measured pass rate.
- Retain only the operational evidence needed for review, with redaction, access controls and a defined retention policy. Do not log full customer messages by default.
The handoff artifact
A useful brief would contain the selected boundary, state transitions, tool permissions, approval/version rules, failure table, evaluation cases and named review responsibilities. Open dependencies include the calendar’s idempotency/transaction support and the organisation’s identity, notification and retention policies.
Turn the idea into a bounded pilot brief