The AI Agent Rollout Checklist: Start With Authority, Not Model Choice

A practical checklist for teams deciding whether an AI agent is ready to handle real work.

A capable model is not the same thing as a safe workflow. Before choosing a model, decide what that authority looks like.

A familiar problem is showing up in AI projects: a team buys access to a capable model, connects it to company tools, and only then asks what the system is actually allowed to do.

That order is backwards.

AI products are increasingly designed to handle multi-step work rather than one-off questions. OpenAI describes agents as systems that can operate independently, orchestrate tool calls, interact with environments, and work toward a solution for minutes or hours.^[1] Google’s Gemini Live update describes voice-triggered tasks that can run in the background across Docs, Sheets, Drive, and the web.^[4]

The practical implication is simple: an AI agent is not just a smarter chatbot. It is a software process with authority.

1. Define the job in terms of an outcome

Do not begin with “Which model should we use?” Begin with “What result should be produced, for whom, and under what conditions?”

A useful pilot has a narrow outcome, such as:

• prepare a weekly sales summary from approved sources;
• classify incoming support requests and draft suggested replies;
• identify stale documentation and open review tasks; or
• create a first-pass test report for a software change.

The narrower the outcome, the easier it is to measure quality and contain mistakes. OpenAI reports that, in its May 2026 sample, more than 70% of users asked Codex to complete a task estimated to take a person more than one hour.^[1] The figures are directional because the task durations were model-estimated, but the pattern is useful: teams are delegating larger units of work, not merely asking for larger answers.

My interpretation: the unit of adoption is shifting from “a useful response” to “a completed workflow.” That makes workflow design at least as important as model selection.

2. Write an authority boundary

For every action, place it in one of three buckets:

1. Read: the agent may inspect the source.
2. Propose: the agent may prepare a change, but a person must approve it.
3. Act: the agent may execute the change automatically.

An inbox assistant might be allowed to read messages and propose labels, but not delete mail. A documentation agent might open a review ticket automatically, but not publish a policy change. A deployment agent might run tests, but require approval before production release.

Google’s description of Spark includes long-running, scheduled jobs that continue even when the user is not actively using the app.^[4] A scheduled process needs an explicit answer to a basic question: what happens if the context changes after the task was created?

Set limits for:

• the tools the agent can call;
• the data it can access;
• the people or systems it can contact;
• the maximum number of steps or spend;
• the actions that always require approval; and
• the conditions that stop the workflow.

If these rules cannot be explained in a short page, the pilot is probably too broad.

3. Measure successful work, not model bravado

A lower token price is useful, but it is not the same as a lower operating cost. A workflow that is cheap per request can become expensive when it needs retries, human correction, or manual recovery.

Track at least five measures:

• Completion rate: How often does the workflow reach the intended outcome?
• Correction rate: How often must a person repair the result?
• Approval rate: How often does a reviewer accept the proposed action?
• Time to completion: How long does the end-to-end task take?
• Cost per successful task: What does a completed, accepted outcome cost?

Google positions Gemini 3.7 Flash as a model for coding and agents, highlighting improved planning and tool calls and an introductory price of $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026.^[3] Those numbers may make experimentation easier. They do not tell you whether the workflow is reliable enough for customers.

My interpretation: the useful comparison is not “Which model is cheapest?” It is “Which configuration produces an accepted result at the lowest total cost and risk?”

4. Keep a record of the agent’s path

A final answer alone is not enough for a long-running workflow. When something goes wrong, the team needs to know:

• which source the agent read;
• which tool calls it made;
• what instructions and approvals it received;
• where it paused or retried; and
• what changed in the external system.

This record supports debugging, customer support, security review, and improvement. It also discourages a dangerous operating habit: trusting an agent because its final explanation sounds confident.

Sophos’s 2026 AI Security report says AI is accelerating familiar attack operations, identifies AI-assisted social engineering as operational, and calls out the credential and identity layer around enterprise AI services as a target.^[5] The report does not claim that every agent deployment will be attacked, but it reinforces why identity, permissions, and activity logs belong in the initial design.

5. Design the stop button before the start button

Every agent pilot should have a tested way to pause or terminate work. Define who can stop it, what happens to in-progress actions, and how the team confirms that access has actually been revoked.

Also define recovery:

• Can a changed record be restored?
• Can a sent message be recalled or followed up?
• Can a human see pending actions before they execute?
• Can the workflow resume safely after an outage?

OpenAI’s discussion of Private Safety Processing makes a related point: risks can develop across a sequence of interactions, including a system continuing after it has been told to stop.^[2] Agent safety is temporal. A single prompt check may not be enough when the system can accumulate context and act repeatedly.

6. Start with a reversible pilot

Choose a workflow where mistakes are visible and recoverable. Use copied or limited-scope data first. Give the agent read access before write access. Require approval for external communication and irreversible changes.

A good first pilot should answer three questions:

1. Does the agent reliably complete a bounded task?
2. Can the team explain and audit what it did?
3. Can a person stop or undo it when the situation changes?

If the answer to any of these is no, adding a more capable model is unlikely to solve the core problem.

Sources

[1] OpenAI — How agents are transforming work
[2] OpenAI — Zero Data Retention and Private Safety Processing
[3] Google — Introducing Gemini 3.7 Flash
[4] Google — Gemini Live productivity features
[5] Sophos — AI Security 2026 report