7 Things to Prepare Before Setting up an AI Agent

You don't have to choose the technology before asking for help. You do need to explain the job, the information it may use and the actions you're willing to let it take.

This preparation is about what you bring to a setup conversation. It isn't a tutorial for connecting an agent yourself.

1. One Job with a Clear Result

"Help with customer service" leaves too many decisions open. A smaller starting point is: "Read new support requests, suggest a category and draft a reply for someone to approve."

Describe what starts the job, what comes in, what a finished result looks like and who uses it next. Bring one ordinary example and one difficult example. Explain what a person does with each today, including the parts that rely on judgment.

If the current process is unsettled, say so. An agent setup should not silently become the decision-maker for a policy the business has not chosen.

2. Approved Information and Secure Access

List the current records the job needs: the service policy, relevant request fields and the system that holds the latest customer conversation. Name which source wins when versions disagree, and who maintains it.

Ask how access will be granted, restricted and removed. Share only what the task needs through an approved secure route. Keep passwords out of the brief.

3. Limits on What the Agent May Do

Separate reading from changing. An agent might be allowed to read a service guide but not edit it. It might draft a reply but not send it. It might suggest a refund but not issue one.

List actions that always need approval, along with actions that are outside scope. Include messages to customers, record changes, purchases and commitments. "Use your judgment" is too broad when the wrong action could cost money or affect a customer.

4. Examples, Including Awkward Cases

Prepare examples where information is missing, two records disagree, a customer asks for an exception or an earlier action may already have happened. State what you want the agent to do: ask a person, leave a draft, stop or take another specifically approved step.

Use invented or permitted redacted records for early tests. Keep the original source available to the person who will review the result, without giving the setup provider unrelated customer information.

5. Checks for a Useful Result

Choose checks that someone can repeat. For the support example: the correct category, a reply based on the current policy, no invented promises and no message sent without the required approval.

6. A Plan for Stopped or Failed Work

Test the failure path as well as the successful one. What happens when the source is unavailable? Who hears about a stopped task? How will the business prevent a retry from sending the same message twice?

A passing test is evidence about the cases tested. It doesn't grant broader authority or prove the system will handle every future request.

7. An Owner After Setup

Agree who reviews early results, updates the approved information and responds to errors. Ask what documentation and access you keep if you stop working with the provider. Don't leave responsibility hidden inside the setup work.

Use the Pack in Your First Setup Conversation

Bring an invented support request about canceling a service. Show the approved cancellation policy and an example of the reply you would accept. Then introduce a request the policy doesn't cover.

Ask the provider to explain what the agent would read, what it would produce and where it would stop. If the answer depends on access to another system, record that dependency. If it depends on your team choosing an exception policy, keep that as a business decision.

Leave with the seven preparation items checked or explicitly open. Keep the setup proposal separate from permission to switch on live actions. For the later implementation stage, this workflow setup lesson explains how task boundaries, testing and monitoring fit together.

---