The field of AI adoption is full of people who meant to come back.
They bought the tool, got approval, tried to connect an account, hit a problem they could not immediately explain, and moved on to work where they had a clearer line of sight into what needed to happen and what the return on their time would be.
The intention was real, and so was the opportunity, but the problem did not become less ambiguous while it sat there. When they returned a week later, they had forgotten what they tried, what failed, which account they were using, and what the error message said, so starting again felt harder than the first attempt and the work was deferred one more time.
The value on the other side can be immense, but getting there often requires an unpleasant amount of setup, troubleshooting, trial and error, and learning, much of which looks unproductive while it is happening and has no guaranteed payoff.
The following example combines patterns I have seen across several real setups. It is not a story about two named clients, and the time estimates are illustrative.
Two executives, one broken connector
Imagine two senior executives at the same company, using the same AI platform, with the same approval from IT to connect Outlook and Calendar and the same basic goal: they want AI to help them prepare for meetings without spending twenty minutes searching through email, calendar invitations, old notes, and whatever else they vaguely remember discussing with the person six weeks ago.
Both executives open ChatGPT, go to connect Outlook, follow the instructions, and hit the same problem. The sign-in process opens Microsoft inside a different browser session, that session is not logged into the correct work account, and neither executive initially understands why the connection keeps failing.
They ask ChatGPT what is going on, and ChatGPT gives them the sort of answer that is technically reasonable and emotionally useless: check your permissions, confirm the account, sign out, sign back in, and try again.
Helpful. That narrows it down to approximately everything.
The first executive looks at the clock and sees that their next meeting starts in ten minutes, they have a proposal to review before lunch, and there are four other tasks on their list where they already know what needs to happen. They close the app, tell themselves they will circle back on the weekend, and move on.
This is a completely rational decision because they are choosing visible work with a known finish line over an ambiguous technical problem that could take another five minutes or consume the rest of the morning, and there is no evidence yet that solving it will create enough value to justify the time.
Saturday comes, and they genuinely try again, but now they remember only that something went wrong with Outlook. They do not remember whether the issue involved the browser, the Microsoft account, a permission, or something else entirely, and they have lost the context from the troubleshooting they already did, which means they are not resuming the work so much as starting it again from a slightly more annoyed position.
They close it one more time, still intending to come back.
The second executive hits the same wall and gets just as frustrated, but they make a different decision about the next thirty minutes. Their next meeting is internal and can be moved, the one after that is a coffee chat with someone they know well, and they have seen enough examples of AI improving real work to believe that learning how to use it across the organization matters more than preserving every block on today’s calendar.
They are also thinking beyond personal convenience because their competitors are experimenting with the same tools, some of those competitors will find ways to do meaningful work faster or at a lower cost, and this executive does not want to be standing in front of the board a year from now explaining that the company understood the opportunity but never found time to get through the setup.
They ask ChatGPT to stop giving solutions for a moment and instead explain what is known, what remains uncertain, and what they should test next. After confirming that IT approved the connection and that they are using the correct Microsoft account, they eventually notice that the login is opening inside a browser session that is not logged into their work account.
They open ChatGPT.com in the browser they normally use for work, try the connection from there, and sign in through the correct Microsoft session.
Boom. It works.
Maybe that took twenty minutes, or maybe it took forty, involved a Google search, required another AI tool, or ended with a call to someone who had seen the issue before. Most of the experience felt terrible because there was no progress bar telling them they were 80 percent finished, and for much of the time they did not know whether the next attempt would solve the problem or produce another vague error.
Even after all of that, they have not created value. They have connected a pipe, and something useful still has to flow through it.
The executive has heard someone mention a technique called reverse prompting, which sounds much more sophisticated than it is, so they ask ChatGPT about it and explain the outcome they want:
Before a meeting, I usually spend twenty minutes searching through email, calendar invitations, CRM notes, and old documents so I can remember who I am meeting, what we discussed, what I owe them, and what I need to ask. I want to spend five minutes reviewing a useful briefing instead.
Ask me whatever you need to understand before you build this. Correct me if I am asking for the wrong thing, tell me which information you need access to, and help me create something we can test on my next meeting.
ChatGPT asks which meetings it should prepare for, how far back it should search, which sources it should trust when the records disagree, what information should never appear, and whether the executive wants a quick summary, unresolved issues, suggested questions, or all of the above.
The first briefing is too long, the second misses an important email, and the third includes questions that could have been written for any meeting with any person at any company. The executive gives more precise feedback, shows ChatGPT what was missing, removes the generic material, and tests the workflow again until the result is pretty damn good.
By this point they may have invested two frustrating hours. If meeting preparation used to take twenty minutes and now takes five, they recover those two hours after eight meetings, which could happen within a few days for a busy executive. That is illustrative math rather than a promised result, but it shows why an experience can feel inefficient in the moment and still become valuable quickly once the setup is doing useful work repeatedly.
It also changes what the executive believes is possible. They now know how to work through a broken connection, ask the AI to expose uncertainty instead of guessing, turn an outcome into a workflow, and improve that workflow through real examples rather than hoping the first prompt will be brilliant.
The next experiment might be proposals, followed by strategy research, email triage, or a review of the executive’s task list that considers impact instead of simply sorting everything by urgency. Each useful workflow creates better instructions, more organized information, more confidence, and a clearer idea of what deserves to be built next, so the gains start to compound in a way that is difficult to see when someone is still fighting with the first connector.
The work hiding behind “just ask AI”
From the outside, a request such as “generate a daily brief” sounds almost comically simple. You open a chat, describe what you want, and the AI generates it, which is close enough to the experience shown in product demonstrations that it is understandable when leaders assume their employees should be able to turn the tool on and start saving time immediately.
Then the actual questions begin: which calendar should the brief use, whether it can read email, whether it should include every message or only messages related to named people and projects, whether it can use CRM records, personal notes, meeting transcripts, and shared files, what counts as urgent, what happens when two sources disagree, and where corrections should be recorded so tomorrow’s brief does not repeat today’s mistake.
The same hidden work appears almost everywhere AI becomes genuinely useful:
- Connections and permissions: Which tools can the AI access, which accounts are correct, what will IT approve, and which information should remain outside the system?
- Instructions and examples: What does good work look like, which examples should the AI follow, and what should happen when information is missing?
- Design and quality: Which proposal format, brand rules, review steps, and quality checks turn a rough draft into something the organization can actually use?
- Operating knowledge: Where do the standard procedures, reusable skills, and current source files live?
- Records and improvement: What evidence is worth keeping so the workflow can improve without creating a logging bureaucracy?
- Cost and support: How much is the organization willing to spend, and where does someone go when the answer is not obvious?
The interface makes the final request look much simpler than the operating system required to answer it well, and that gap creates terrible expectations for people who are already busy and adopted AI precisely because they do not have spare time.
For AI nerds like me, a lot of this now feels easy, but I have spent a few thousand hours paying for that ease through broken workflows, badly organized files, sessions that ran too long, instructions that worked once and failed the next day, and outputs that were technically correct but still not good enough to use.
Even now, I can spend an hour fighting with AI over a proposal that I could have edited manually in fifteen minutes. Sometimes that hour produces a better instruction, a stronger quality check, or a reusable design decision that improves every proposal after it, and sometimes I eventually admit that I should have made the manual edit forty-five minutes ago.
If every failed experiment gets rewritten as a profound learning experience, we are just doing marketing to ourselves. Some experiments are dead ends, some tools are not ready, some workflows technically function but remain more annoying than the manual version, and sometimes the right decision is to stop.
A good operator or implementation partner can compress the learning curve by bringing tested patterns, recognizing familiar problems, and helping people avoid infrastructure they do not need, but nobody can eliminate the awkward middle entirely because the user still has to try the system on real work, notice where it is wrong, and care enough to improve it.
At some point these systems may be capable enough to handle much more of their own onboarding. You may tell an AI to inspect the available tools, propose the right connections, walk IT through the required permissions, configure its workspace, and test the setup inside safe boundaries. We are not there yet, and pretending we are sets everyone up for disappointment.
Success is not a personality test
The first executive did not fail a character test. They made a rational decision inside an organization that had given them a calendar full of visible responsibilities and an ambiguous technical problem with no protected time, no known support path, and no evidence yet that the effort would pay off.
The people I see getting the strongest results are eager enough about the potential that they will use the tools in their day-to-day work, tolerate failed experiments, and occasionally spend an hour giving feedback to an AI when they could have completed the immediate task faster by doing it themselves. That willingness is much easier to sustain when the organization treats learning as part of the work instead of something people should squeeze into evenings and weekends.
A good environment has an executive sponsor who believes the work matters, enough permission clarity that every connection does not become a political negotiation, a reasonable spending boundary, and a clear way for users to get help when they hit a problem that is completely new to them. It also needs people who will use the system, because no strategy, workshop, consultant, or expensive platform can generate learning from a workflow that nobody tries.
This is the uncomfortable position organizations are in right now: the tools are capable enough to create meaningful value, but not yet reliable or self-configuring enough to remove all of the human effort needed to set them up, teach them how the work should happen, and improve them when the first version is wrong.
In my experience, organizations underestimate that effort because it does not look like the outcome they were promised. Troubleshooting a browser session does not look like transformation, arguing with an AI about proposal spacing does not look like productivity, and talking to IT about permissions does not look like innovation, yet those moments often determine whether the useful workflow ever reaches daily use.
An organization cannot demand the long-term payoff while refusing to fund the short-term learning that makes it possible.
The other way to waste money
Once leaders understand the setup tax, there is a danger of overcorrecting and deciding that every problem needs infrastructure before anybody has used the basic workflow enough to know what should be built.
This rabbit hole is extremely easy to enter because the ideas all sound reasonable in isolation. A proposal would benefit from a design system. The AI would improve if every session created a log. The organization should probably have documented procedures, better records, a central knowledge system, a custom application, and perhaps several agents coordinating work across different tools.
Some of those investments may become essential, but building all of them before real use has exposed the actual bottleneck is how an AI initiative turns into an expensive construction project designed around assumptions.
I see this tension in my own work with clients. A better proposal system may save a great deal of time later, but how much should we invest in the design system before we know whether design is the real constraint? A session protocol and better records may improve consistency, but do they help someone produce the proposal they need today, or are we paying now for a future benefit that has not earned the investment?
The same problem applies to measurement because, if an outside operator costs hundreds of dollars an hour, spending many hours building a perfect before-and-after study for a task performed once a month is another way to lose the economics of the project while producing a very confident spreadsheet.
For the meeting-preparation example, a light baseline may be enough. Measure a handful of meetings before and after, note whether the briefing missed anything important, record how much editing it needed, and see whether the executive keeps using it when nobody reminds them. That will not prove organization-wide return on investment, but it may tell you whether this workflow deserves another round of improvement.
Usage-based pricing also needs boundaries rather than false precision. You cannot know exactly what a new agentic workflow will cost before seeing how often it runs, how much information it processes, how many revisions it requires, and which tools or models it uses, so set an initial cap, watch the real consumption, and update the budget from evidence.
In practice, I would start with a piece of work that matters enough to justify some friction, give the people involved enough time and support to get through the first ugly version, and build the next layer only when real use shows that the value or recurring pain is large enough to earn it.
That is a much less exciting message than “buy this tool and transform your business,” but it is closer to what AI adoption looks like today. There will be days when someone spends an hour getting AI to do something they could have done manually in fifteen minutes, and leaders will not know in advance whether that hour will become a reusable capability or simply disappear into a failed experiment.
When someone hits the broken connector at 10:20 on a Tuesday morning, the fate of the AI strategy may depend less on what the tool can theoretically do than on whether that person has thirty minutes, a clear place to get help, and a reason to believe the work is worth finishing.
