Bringing AI Agents into Customer Implementation: People Innovate, Collaborate and Approve

Implementation teams spend a surprising share of their week on work that isn't really implementation. Chasing answers after discovery calls. Rewriting the same status update for the third customer this week. Checking who has logged in. Sorting support tickets. Lining up spreadsheet columns before a data migration.

AI agents are starting to take on some of that preparation work. Not by running projects on their own, but by drafting, flagging and preparing, so the people on your team can spend more time on judgment and on the customer.

But the human role is bigger than checking an agent's work. People play three parts: they innovate, deciding where agents add value, designing how they're used and improving that over time. They collaborate, working side by side with agents and with the customer's own team. And they approve, signing off at the checkpoints before anything reaches the customer.

Here's a practical, grounded look at where agents can help, and how those three roles keep people at the center of the work.

What we mean by an "agent"

An AI agent is software that can carry out a multi-step task: read a set of notes, pull information from your tools, and produce a draft or a flag for someone to review. The important word in that sentence is draft. In customer implementation, an agent's output should be a starting point for a person, not a finished action. And it's people who decide which tasks are worth handing to an agent in the first place.

Five places agents can take on real work

1. Discovery follow-ups. After a discovery call, there are always open questions: missing contacts, unclear requirements, documents the customer promised to send. An agent can read the call notes, list what's still missing and draft a follow-up email. Your implementation lead checks it, edits it and decides whether to send it.

2. Plans and status updates. Agents are good at turning scattered inputs into a first draft: a project plan built from your standard structure, or a weekly status update summarizing what moved, what's blocked and what's next. The lead reviews the draft for accuracy and tone before anything goes to the customer.

3. Adoption monitoring. After go-live, an agent can watch usage signals and flag patterns worth a look, such as a team that stopped logging in or a key feature nobody has touched. It doesn't decide what to do about it. It raises the flag so a person can.

4. Support triage. An agent can read incoming tickets, suggest a category and priority, spot duplicates and draft a first response. A human confirms the priority and approves or rewrites the reply.

5. Data mapping preparation. Before a migration, an agent can compare the customer's export with your import format, propose which fields line up, and highlight gaps, odd formats and likely duplicates. Someone who understands both systems reviews every proposed mapping before any data moves.

What makes it work: people innovate, collaborate and approve

The pattern in all five examples is the same. The agent drafts, flags or prepares. People do the rest, in three roles that feed each other.

Innovate. Your team decides where agents add value and where they don't. They design the approach: which tasks, which inputs, what a good draft looks like. And they keep improving it, based on what the agents get right and wrong. An agent doesn't choose its own job.

Collaborate. Agents work alongside your implementation lead and the customer's team, not in a separate lane. The lead brings context from conversations an agent never heard. The customer's admins and project owners add what only they know about their business. The agent's drafts become a shared starting point for that work.

Approve. At each checkpoint, a person reviews, corrects and signs off. Only then does anything reach the customer or touch their data.

Approval matters for three reasons:

• Agents make mistakes. They can misread notes, get facts wrong, miss context or sound confident about something that isn't true. Review isn't a formality. It's where those errors get caught.
• Customer relationships are built on trust. One wrong number in a status update, or a reply that misses the point, can undo weeks of good work.
• Accountability stays clear. The customer should always know that a real person stands behind what they receive.

So: no autonomous customer-facing sends. Emails, updates, replies and data changes go out only after a person has approved them. And what you learn at each checkpoint feeds back into how your team uses agents next time.

Data security and data sovereignty

Implementation work touches some of a customer's most sensitive information: contacts, contracts, usage data and full data exports. Bringing agents into that work raises the bar for how you handle it.

• Know where data is stored and processed. Find out where any AI tool keeps and processes the data you give it, and match that to what you've promised the customer. If a customer expects their data to stay in a region, such as EU data staying in the EU, make sure the tool and its setup support that.
• Give agents the least access they need. Scope each agent to the specific project, fields and actions its task requires. An agent preparing a data mapping doesn't need access to every customer's records.
• Keep sensitive customer data out of public or consumer AI tools. Use tools set up for business use, under agreements your company has reviewed, not a personal chatbot account.
• Check the vendor's terms and set retention rules. Read the data-processing terms, look at which security certifications the vendor holds, and confirm whether your data can be used to train their models. Decide how long prompts, outputs and files are kept, and delete them when they're no longer needed.
• Keep an audit trail. Log what each agent accessed, what it produced and who approved it, so you can answer the question "what happened to our data?" clearly.
• Get the customer's approval first. Before any of a customer's data goes into an AI tool, tell them what you plan to use, why and where it will be processed, and get their agreement.

From the implementation side

The same principles map onto the phases of a rollout:

• Keep real data out of testing. The test environment is built with sample or masked data, never real customer data. Production data comes in only once the production environment is built, and stays in the region and environment agreed with the customer.
• Scope access per project. Each agent gets access only to the one project it supports, and only for as long as that project needs it.
• Let the customer decide what's in bounds. The customer approves which of their data any AI tool can touch, and that decision is recorded in the project plan.
• Do the checks before the tools. Data-processing agreements and vendor security reviews are done before any AI tool is used on the project, not partway through.
• Close it down at the end. When the project hands off to customer success, project data is kept or deleted according to the agreed retention rules, and agent access is removed.
• Keep the record. Audit logs show what each agent accessed and what each person approved, so your team and the customer can review it later.

None of this removes risk entirely, but it reduces it and keeps the customer in control of their data.

If you work with customers in the EU, the GDPR shapes much of this, and other regions have their own rules. This is general guidance, not legal advice, so talk to your legal, privacy and security teams before you roll agents into customer work.

How to start without creating new risk

• Decide where agents fit. Treat this as your team's design work, not a tool rollout. Agree which tasks are worth trying and what good output looks like.
• Start internal. Begin with work that never leaves your team, such as summarizing call notes or proposing a ticket category. Build confidence there first.
• Pick one repetitive task. Choose something your team does often and finds tedious. Don't try to automate the whole project.
• Keep the approval step visible. Make it obvious in your workflow what was drafted by an agent and who approved it.
• Limit access. Give an agent only the data and tools it needs for its task, and be careful with customer data.
• Improve it together. Look at what the agent gets wrong, and adjust how you use it with the people doing the work. If review keeps taking longer than doing the task yourself, that task may not be a good fit.
• Bring your customers in. Be open about using agents for preparation work, involve their team in shaping it, and explain the human review behind it.

What agents shouldn't do

Some parts of implementation are fundamentally human: understanding what a customer is really worried about, negotiating scope, delivering bad news well, and deciding when a project needs to change course. Agents can help you prepare for those moments. They shouldn't handle them. And they don't replace the implementation lead, the customer success manager or the customer's own sign-off at the end of testing. Those stay with people.

From experience

Over 15+ years in implementation and delivery roles at SAP, Ericsson and HP, Alex Bitang saw how much of a project's success came down to clear communication and careful preparation, and how much time that preparation took. Agents can take on more of that groundwork. Deciding where they help, working through the project with the customer, and signing off on what goes out should stay with people.