An agent can draft the invitation. Who is allowed to send it?

Start with one invitation

A hiring manager selects a shortlist. An assistant reads the interview plan and drafts invitations. That sounds like a small task until the assistant also gets permission to send messages, move applications and edit offers.

Decide which of those operations it actually needs. For this illustrative workflow, it may read the selected applications and draft an invitation. It may not choose who advances, send without approval or change compensation.

OWASP recommends least privilege and human approval for privileged operations. OpenAI advises keeping tool approvals enabled for MCP operations. The recruiting design below is a proposed application of those controls, not a description of Pebble’s agent capabilities.[owasp][openai]

Give the task a permission table

Scroll sideways to read the full table.

“Help with recruiting” is not a useful permission description. Specify application identifiers, permitted operations and allowed arguments. Enforce those limits in the tool layer; a prompt alone should not grant or remove access.

If one integration bundles reading, sending and editing together, use a narrower wrapper or a different workflow. The drafting task does not need every power the integration happens to expose.

Approve the operation the person can see

Show the candidate, destination, exact message, interview round and scheduling details. Show that the hiring manager selected this candidate. The reviewer should be able to edit, decline or stop the proposal.

Bind approval to that payload. Changing the recipient or message requires another review. Otherwise the person approves one invitation while the model sends another. This is a design requirement to implement and test, not a safeguard to assume a framework supplies.

The sequence diagram separates proposal, approval, state check and execution. Notice the return path: a changed candidate status or interview plan sends the proposal back to review. It should not be treated as a minor detail the agent can fix while sending.

“Before sending: is this still the selected candidate, the approved message and the current interview plan?”

A timeout is an unknown result

The send call times out. It might have failed before sending. It might have sent successfully and lost the response. Retrying immediately can send two invitations.

Use an operation identifier and service-supported duplicate protection where available. Otherwise inspect the result before retrying. Record “attempted”, “completed” and “unknown” separately. The assistant’s statement that it sent a message is not a substitute for the service result.

Keep a manual route for unavailable tools and approvers. Report the blocked task to its owner. Do not broaden access or choose a different candidate action merely to complete the run.

Test the cases that an ordinary demo skips

• Decline the draft: no send or stage change should follow.
• Edit the recipient after approval: the old approval must not apply.
• Withdraw the candidate before execution: return to review.
• Return an uncertain tool result: inspect it without blindly repeating the operation.
• Remove the approver: wait or escalate to the named owner.

Use invented records and a test destination. Inspect the actual events and service results. NIST calls for documenting human oversight and system limits; a focused failure test gives the team something observable to document.[nist]

You should be able to answer three questions after the test: who approved, exactly what was approved and what actually happened. If any answer depends on believing the assistant’s narrative, the execution record is incomplete.