The hardest part of getting AI to work inside a company is not the first team that succeeds with it. It's the second.
McKinsey's The State of AI in 2025 survey interviewed nearly 2,000 executives across more than a hundred countries. Among the highest-performing companies, roughly three in four say AI is already scaling across the whole organization. Among everyone else, it's one in three. The gap isn't about having AI — it's about getting what worked in one area to reach the others.
Boston Consulting Group measured the same problem from a different angle. In research published in October 2024, only 26% of companies had built the capability to move past proof of concept and generate real value; 74% still hadn't shown a concrete gain. For anyone making decisions, the message is direct: the bigger risk isn't the first pilot failing. It's the first pilot working and the company being unable to repeat it.
It's worth noting what that number isn't: it isn't lack of interest, budget, or good isolated results. Companies that fall behind usually already have at least one case working well somewhere. What's missing is a path for that case to leave the corner where it was born.
Where the Method Gets Stuck
An operations team, through trial and error, builds a way to use AI to review a type of contract that used to take a full day. It works. Someone mentions it in a meeting. A manager from another area likes it and asks to "learn how you do it." What happens next, in most companies, is a phone call, an improvised explanation, and an attempt to rebuild from memory what made it work.
The copy rarely comes out the same. The exact reference document is missing, the connection to the right system is missing, the fine-tuning that only emerged after several attempts is missing. The receiving area ends up with a weaker version — and, often, gives up before getting close to the original result.
This phenomenon has a name and decades of research behind it. Gabriel Szulanski, of the Wharton School, published a 1996 study in the Strategic Management Journal on why good internal practices resist moving from one part of a company to another — even with no secrecy, no political rivalry, and nobody trying to hide anything. He called the effect "internal stickiness."
The study points to three barriers that outweigh simple lack of will. First: the receiving team rarely had enough contact with the context to absorb the method on the first try — it only hears the result. Second: it's almost never clear which exact step caused the gain — even the team that built it struggles to separate what matters from what was just a way of doing things. Third: the transfer depends on a personal relationship between whoever discovered it and whoever would use it next, and that relationship is rarely anyone's actual job.
With AI, these three barriers get heavier, not lighter. A good method isn't just text you can copy — it's a configured agent, a script of questions, access to a specific document, a connection to a system. Watching over someone's shoulder isn't enough to reproduce any of that.
In Brazilian and Latin American companies, this pattern shows up in a very concrete way: the tax team solves something well, sends a voice note or a screenshot to a colleague at another branch, and that's where it stops. There's no official place for that method to keep existing beyond the conversation that described it.
The Attempt That Doesn't Travel
The most common responses treat the wrong symptom. Training the whole company on the AI tool teaches the tool, not the specific configuration a team spent weeks getting right — you end up with people who know the product and nobody who has the method ready to use.
A manual or a wiki page doesn't solve it either: it describes in text what was, in practice, a combination of access, system connections, and fine-tuning. Whoever reads it has to rebuild the discovery from scratch, running into the same three barriers from Szulanski's study.
A company-wide presentation sparks interest and leaves nothing reusable the next day. And a central committee that has to approve every share, meant to protect quality, often turns into a queue instead of a distribution channel — the more a single group has to approve everything, the slower what works reaches the people who need it.
None of these attempts fail for lack of effort. They fail because they only carry the story of a result, never the reusable thing itself.
What Has to Be in Place
Getting a method to travel from one area to another depends on mechanisms, not goodwill.
A catalog of what already exists. Agents, scripts, and workflows a person builds stay visible for search by whoever has a reason to use them — instead of buried in the creator's personal history.
Reuse with a defined reach. What worked can be made available to specific people, groups, or roles — it doesn't stay only with whoever created it, nor does it become open access for the whole company with no criteria.
What's personal stays personal. Each person's memory and history aren't exposed by default when something is shared; only what they choose to make available leaves individual use.
Approval to promote something to official use. Moving a personal setup to team-wide or company-wide use goes through a human review step — not an informal heads-up in a meeting.
A trail of who started using what. Leadership can see, area by area, what got adopted and where it came from, instead of relying on a rumor that "finance has something good."
This is how Skyller was designed: what one person creates can be made available to others by role and by group, with personal memory preserved and promotion to official use depending on approval.
What Changes When the Method Travels
When reuse with permissions actually works, one area's discovery stops being an isolated fact and starts adding to the whole company's capability. The gain isn't just the time saved by using AI — it's the time no longer spent rediscovering something that already exists on another floor of the same building.
That also changes how budget approvers think about it. Instead of every area negotiating its own license and reinventing its own configuration, one team's effort becomes the starting point for the next. Skyller, for example, ships with more than 100 pre-configured agents by area, so whoever starts later doesn't have to build from zero what another company — or another team down the hall — already solved.
There's also a less-discussed effect: a team that sees its own method being used by other areas has a concrete reason to keep it up to date. When one person's effort dies in their own drawer, keeping it well-maintained brings her no return at all.
Companies with several branches or units feel this gain more strongly, because today they pay the cost of rediscovery over and over — each unit solving, in isolation, the same problem headquarters or another branch already solved months earlier.
Questions to Unlock What Already Works
Before approving another license or another pilot, it's worth bringing these questions to whoever leads operations and technology.
- Has anyone in the company already solved something well with AI that another area doesn't know about? Ask each area's leadership to name one case from last quarter, then check how many colleagues in other areas have even heard of it.
- What happens if that person leaves tomorrow? If the method walks out with her, it never existed as a company asset — only as a personal file.
- Who can access what was shared, and who decided that? If sharing means "publish it for everyone," check whether that reach actually matches what each role should see.
- Is there an approval step before something personal becomes an official default? Without one, the quality of what spreads across the company depends on luck.
