Plan a connected action before it runs

Define one action and its intended result

Start with the result the person making the request needs. You may need a draft for review, a colleague may need a task recorded, or a customer may need a supported update completed. Name the specific change, service, account, and destination. “Handle this request” leaves too much room for disagreement about what should happen.

Check that the selected connection actually offers the action and that it fits the agent’s role. A connection may support reading information without supporting a particular write. Discussing an action in AI Chat is not evidence that it has run.

• Name the exact action and destination.
• Describe the result that would count as success.
• Confirm that the configured connection supports the action.

Check the inputs and the permission to use them

Identify the information the action needs and where each value comes from. Names can be ambiguous: two projects may share a title, or two customers may have similar details. Resolve the intended destination before making a change.

Use the account and role appropriate to the job. Check whether the action reads information, changes it, or sends it to someone else. Keep the scope limited to the records and information required for that task, and stop to resolve missing or conflicting inputs.

• Confirm the target account, project, or record.
• Review the values that will be written or sent.
• Check the connection permissions and the agent’s selected role.
• Identify any required input that is still uncertain.

Put review before the consequential step

Decide what a person needs to inspect before the action proceeds. For a message, that may be the recipient and final text. For a record update, it may be the target and the proposed changes. The review should describe the concrete action, not ask for a vague approval of the whole workflow.

Use the approval behavior available for the configured tool and workflow. Where approval is required, inspect that request before allowing the action to continue. An earlier discussion or draft should not be treated as permission for a different destination, larger scope, or new external effect.

Example: plan the creation of a project task

Suppose a configured project connection supports creating tasks. The plan could be: “Create one task in the Support Operations project to review the current onboarding checklist. Use the agreed owner and due date. Show the destination, title, owner, date, and description for approval before creating it.”

Define the expected result separately: “After the action, report the task identifier or link returned by the service. If the owner or date is missing, ask for it. If the result is uncertain, check whether the task exists before trying again.”

This is an example plan, not an executed action or a claim that every connection supports task creation. Substitute the actual service, supported action, and confirmed values for your workflow.

Decide what happens if the result is uncertain

A delayed response does not always mean an action failed. Before repeating a write, check the destination or the result reported by the service. Repeating a creation or send can produce duplicates even when the original request appeared to stop halfway through.

Plan recovery before the change. Some updates can be reversed using the previous values; some created items can be removed; a sent message may not be retractable. Confirm what the service actually allows and record enough information to find the affected item.

Finish by checking the intended outcome and reporting what happened, what remains uncertain, and any follow-up needed. Keep a proposed action, an approved action, and a confirmed result distinct throughout the conversation.