For integration teams adopting a new agentic tool, expect one or two early adopters to thrive right away. The rest? Expect resistance and frustration: this is change, after all 

Even our own Professional Services team approached our AI-native evolution with skepticism and workarounds. They, like your teams, are on deadlines. They felt drag compared to their “old” way of working. Getting to where we are now, with our services team celebrating massive acceleration every week, was not an accident. 

What follows is the advice I'd give a leader whose integration team is about to begin the adoption of agentic tools.

We had every advantage

My team, Digibee Professional Services, builds integrations for customers every day on the Digibee platform. Often, we’re pulled in when our customers’ teams are overburdened and face immoveable deadlines. 

Our colleagues in R&D are the ones who make sure the tools we work with are best-in-class.  As LLMs became more capable, they knew we needed to reimagine and rearchitect our platform. This new, AI-native version centers on AI agents called Digibee Digital Workers who are experts in integration. They don’t just accelerate building workflows, they improve quality by driving discovery and design through specifications.

The company needed testers, and we were the obvious choice. We know the platform better than anyone, and some of us eat lunch with the engineers who build it.

That makes us an unusual case. Most integration teams buy from vendors and rarely meet the people who build the product. We had the head start: deep product knowledge, a direct line to R&D, and every reason to care. Changing my team’s approach was still a challenge, because agents change the job itself. No amount of product knowledge makes that shift for you. If a team with our head start hit friction, expect yours to as well.

Train before you turn it on

We gave our teams access to Digital Worker Mode, the AI-native side of the platform, and waited for feedback. None came. I learned that the majority of my team members had opened it out of curiosity and tried a quick task. It didn’t do what they do faster than they do it. So, they quietly returned to their familiar ways of working.

The mistake was ours. We had given the team a short presentation, but little else: no expectation setting on usage, no in-depth training, and worst, no sense of the fundamental change in how they work. We’d seen the massive impact of digital workers for our design partners. We wrongly assumed my team would be eager to jump in.

Many organizations make some version of this mistake. A Gartner analyst noted that chief human resource officers "have overrelied on empowering employees to chart their own exploration of AI… and have overlooked the role of the manager in driving effective use of AI tools." Just like we did.

This stung. We’re known for our rapid time-to-proficiency and self-paced learning with the Digibee Academy, but we skipped that step with our own coworkers.

Luckily, our Forward Deployed Engineering (FDE) team had already designed onboarding for customers. We gave our team the same initial three-hour “test drive” session. This was step one: showing them not just how the new platform works, but how they should work within it. Of course, that alone wasn’t enough to get my team members to change their habits.

If you're adopting agentic products from a vendor, ask what training and change management comes with the tool.

Judge the tool after the learning curve, not during it

Integration engineers will tell you that using a new tool in their work will take longer than the way they do it now. In our experience they're right: the first time, and maybe the second or third. Judge a tool in that window and it loses. 

So agree on a review date before you start, and define what success looks like. Measure not only speed, but also quality, rework, and the team's capacity shift from execution to strategy. Give people time to learn, but don't ignore serious problems along the way.

The payoff will come. A member of my team, working on a migration project, used a digital worker to produce a detailed specification. The project plan, based on years of similar assignments, had budgeted 12 days to review data, design the architecture, and refine the business requirements. She finished in three hours. "The digital worker gave me the specs I longed for customers to build," she said.

That’s one project, not a trend, but that big win was followed by smaller ones. My team’s use of the tool keeps advancing and evolving.

Be an active partner, not a recipient

Our training stumble had a second layer. Agentic products aren’t off-the-shelf purchases. They must be onboarded to every enterprise’s unique context, estate, and operating patterns. This takes dialogue with the team using them. We hadn't clearly established that expectation. Instead of seeing themselves as shaping digital workers, some on my team saw a tool that wasn't meeting their needs.

So we changed how we treated them. We made sure my team understood that they were partners, not just recipients. Their feedback would shape how digital workers functioned within their environment, and sometimes beyond.

They started writing detailed reports on their experiences, just like customers do with our FDE’s. My team asked why digital workers required uploaded specs instead of automatically scanning previous workflows. Now they do. One team member’s input resulted in a skill that proposes different ways to configure workflows. It’s now popular among customers.

This is the next phase after training. Once your team understands the basics of their new agents, tell them their job is to find where the agents fail.

In preparation for this, ask your vendor for four things:

1. A playbook for onboarding AI to your organization.
2. A named contact who answers.
3. A direct channel for reporting what breaks.
4. A way to see what changed because of your report.

Answer the objections you can't dismiss

Beyond skepticism, my team raised a technical objection: Core integration work demands deterministic workflows that follow proven patterns. When a flow breaks, orders may not ship, or people may not get paid. My engineers know how to build error handling for their client accounts. They didn't want an agent introducing unfamiliar or incorrect patterns.

We explained that Digibee Digital Workers keep the user in control. Users dictate what the agent should build by crafting a high-quality specification. They are responsible for reviewing and, wherever needed, adjusting or correcting the design captured in the spec. This is how they control what the digital workers ultimately build.

Your team's objections will differ. Ask for them in the first training session, repeat the strongest version back, and deliver the most honest answer you have. When possible, give them an answer they can put their hands on themselves.

Challenge teams to question their defaults

A tool that earns its place still competes with whatever people reach for without thinking.

I’ve watched this happen. A customer sent one of my engineers documentation to review. They reflexively opened Claude. This engineer had used digital workers, and knew that they handle this task well, but they defaulted to their old path out of habit.

So we gave the team one question to ask at the start of any new task: “Can I start this with a digital worker?” If yes, try it. If not, understand why. The goal wasn't to force the new solution into every situation, but to shift the default away from old habits.

Be visibly persistent

Some of my engineers have been on my team for five years. They’ve developed a way of doing things, and they’re good at it. One workshop and one question to ask before a new task won't disrupt half a decade of routine.

I kept the workshop's lessons alive in a dedicated Slack channel, with a lively, practical infographic every few days. I posted a total of 16 in the series: "Don't stop at the happy path" and "Ready to generate is not ready for production" among them. They lean on the engineers' own instinct to distrust output they haven't checked. The team also saw themselves in these learnings, and knew they were part of the positive change.

Budget for this. Gartner estimates that every 100 days of implementing AI demands 25 extra days of training and up to 200 days of change management. Plan in months, not weeks.

I’ve started supplementing these reminders with success stories from across the company. Our Field CTO told us about the time a digital worker said his proposed architecture wouldn't work under the constraints it had to fit. It was right, and he changed course.

Another early win came from a large retailer we serve. They had a contract-driven deadline to migrate to a new ecommerce solution in just 20 days. An architect on their team had begun trying to solve this with Claude, but hadn’t made much progress. We urged him to try Digibee Digital Workers instead. With our AI’s specialization, his team achieved the migration in 15 days. 

Before your rollout starts

Your integration team will adopt an agentic tool eventually. Before they do, take these steps.

• Set expectations before you set up accounts. Tell your team, and the leaders above you, that AI agents change how engineers work, and the tool is the smallest part of that. Adoption will be uneven: one or two people will take to it fast, and the rest will take longer. Expect friction before impact, and plan in months, not weeks. 
• Say what you expect of usage (try the agent first on every new task, for instance) and what engineers keep: the judgment and the decisions.
• Train people before you grant access. Show them how the tool works and how to work with it. Name its limits yourself, before the team finds them on a deadline.
• Agree on a review date and a rubric before the first task. Measure speed, quality, rework, and how much capacity shifts from execution to strategy. Check on that date and not before. Budget the time for everyone, including the people you expect to take to it easily
• Start with analysis, not construction. Point the agent at customer documentation and ask for confirmed facts, assumptions, and open questions. Engineers can judge the result in minutes, and nothing ships.
• Bring engineers in early. Give them a channel to report failures, a vendor contact who answers, and fixes they can see.

The friction ends. The gains don’t. Once the repetitive work moves to the agent, engineers spend more time on architecture, hard problems, and the decisions that matter. That’s where the long-term value of adoption comes from, and teams reach it only if they get through the early weeks.

[Get early access to the first AI-native integration platform →]