The pilot worked. Now the agent has more users, another connected system, and a queue of tasks that look almost like the example it handled well. Use this checklist for one workflow at a time. Download the rollout worksheet to assign owners, record decisions, and carry unresolved items into the next review.

What should be ready before the first rollout?#

Before the first rollout you need:

an accepted task definition
a responsible owner
a working path through the required systems
a way to inspect and stop the work
a fallback for when the agent cannot finish

Skip automating the entire department. Start with a task that occurs often enough to learn from, with a result someone can inspect and a clear finish line.

Stage	Decision	Concrete output
Scope	What work will this rollout cover?	Task definition, allowed actions, and acceptance criteria
Connect	Which information and actions does it need?	System and permission map
Review	Which actions need a person?	Approval rules, reviewers, and escalation path
Rehearse	What happens when ordinary things go wrong?	Results for normal, exception, and recovery cases
Operate	Who handles unfinished or incorrect work?	Owner, review routine, and stop procedure
Expand	What should change before adding more work?	A decision based on completed tasks and recurring problems

1. Define one finished task#

Write the request and the accepted result in the team's language: "Prepare a renewal brief using the current account record and recent correspondence, save the draft on the account, and ask the account owner to review it."

Name what the agent does on its own, what requires approval, and what is outside the task. Reading account notes and drafting a brief are different permissions from sending an offer or changing billing terms.

Choose the task owner who accepts the work and the service owner who keeps the connections and workflow running. One person can own both responsibilities, with each kept visible.

Record a few recent examples of the current process, including time spent explaining, searching, correcting, and completing the handoff. The rollout review compares against them.

2. Map sources, destinations, and permissions#

List each system the task touches. For every system, name the facts the agent reads and the actions it performs. Mark the authoritative source for facts that appear in several places.

In the renewal example, the CRM owns the account identity and approved terms, while email holds a newer contact request. Decide in advance how to handle the disagreement, so the agent does not promote an old message into the source of truth because it retrieved that message first.

Check the exact operation needed in each connection, the account used, its scope, and the person who can rotate or revoke access. Test with the rollout's intended permissions, not an administrator account.

Include destinations in the map. A completed paragraph in a chat is not a draft saved on the correct account.

Use the connectors pages to inspect the systems involved and the permission questions guide to separate connection access from authorization for a particular action.

3. Make approvals understandable#

Ask for approval where a person has a meaningful decision to make. Show the proposed action, target, relevant source, and material consequence.

A request that says "approve tool call" makes the reviewer reconstruct the task. One that shows the intended recipient and the exact renewal draft gives the reviewer something to judge.

Agree what happens when an approval expires, a reviewer is unavailable, or the proposed action changes. A decision about one recipient or amount must not silently authorize another. Make the fallback explicit: assign another reviewer, keep the draft pending, or return the task to its owner.

Do not add approval to every step as a substitute for defining scope. The approval design guide covers reserving attention for decisions that deserve it.

4. Rehearse the failures you expect#

Run the ordinary task first, then change one condition at a time: a missing record, a conflicting source, an unavailable connection, a duplicate request, and a write whose outcome is uncertain.

For each case, inspect the destination system as well as the agent's final message. An agent can report failure after a write succeeded, or report it finished when it only produced a draft.

Write the expected next step before running each case. If a message send times out, the correct recovery is to check whether the message exists before trying again. If a source is stale, repeating the same search without changing anything repeats the mistake.

Keep the results in the evaluation scorecard and resolve failures in the actions you plan to enable. If a path is not ready, narrow the initial scope and make the remaining manual work visible.

5. Decide what the next task should remember#

When a person corrects the agent, ask whether the correction applies to this task or to future work. "Use this contact for today's renewal" and "this is the account's new primary contact" have different lifetimes.

Name who reviews reusable knowledge and where it is corrected or removed. Keep its source and scope visible. A remembered answer without a date or source becomes the next task's confident mistake.

Treat methods the same way. A successful sequence of steps becomes a reusable procedure after someone checks when it applies. Save the exceptions alongside the happy path: which accounts need a different review, which source takes precedence, and what to do when information is missing.

Test reuse with a second related task and a deliberately different task. The first should benefit from the correction, and the second should not inherit facts that do not apply to it.

6. Give the team a way to operate the workflow#

Write a short operating note with the owner, where results appear, how to find action history, how to report a problem, and how to stop new work.

A stop procedure needs more than a button name. Identify queued tasks, in-progress calls, and actions that already reached another system. Stopping further work does not undo an email or a record update, so assign follow-up for effects that need correction.

Review a sample of completed tasks and every consequential exception during the initial rollout. Look for recurring corrections, unnecessary repeated calls, stalled approvals, and results that people still copy into other tools. Fix the recurring cause instead of asking reviewers to absorb it.

For costs, name the budget owner and the task owner, who differ when one team operates shared tooling for several departments. The budget ownership guide gives a model for those responsibilities.

7. Expand one dimension at a time#

Add a new task type, connected system, user group, or action only after reviewing the existing workflow. Changing all four at once makes a new failure hard to explain.

Carry forward the acceptance criteria and add cases for the new scope. A workflow that drafts internal notes has not shown it can send customer messages, and a connection that reads records has not shown safe updates.

Keep a brief decision record: what improved, which problems remain, what changes next, and who owns the change.

What if the rollout is not saving time?#

Look at where people still intervene:

Searching for missing context: improve source access.
Correcting the same mistake: review what the next task retains.
Moving results between apps: repair the handoff.
Approving routine steps: reconsider the rule.

If none of these fits, the task is too broad or the agent is a poor fit. Narrow the workflow or revisit the build, buy, or connect decision.

For a Deixic rollout, start with your existing agent, the systems the task needs, and the decisions your team wants to keep. Use enterprise procurement for deployment and data-handling questions, and bring the worksheet to a workflow demo.