A lot of workplace AI adoption still amounts to this: here is a blank box. Type something clever.
The employee has to decide what to ask, gather the right background information, figure out what they’re allowed to share, judge whether the answer is correct, and move the useful parts back into the system where the work actually happens.
That’s a substantial amount of new coordination for a tool that is supposed to reduce coordination.
I think useful workplace AI should require less of the employee. The context, permissions, and controls should be designed into the process. People still need to understand what the system is doing and use their judgment, but they shouldn’t have to become good at AI before AI can make them better at their jobs.
The blank box only looks simple
Imagine an account manager preparing for a customer meeting.
A general AI tool might be able to create a useful briefing, but only after the account manager tells it which customer they mean and supplies the relevant context. That could include recent conversations, account history, open support issues, product activity, previous commitments, and the purpose of the upcoming meeting.
Before sharing any of that, the employee also has to know what information is safe to enter. They need some way to tell whether the sources are current and whether the summary is accurate. Once they have a useful answer, they still have to copy it into their notes, customer record, or whatever system they use next.
The employee is searching, assembling, explaining, checking, and transferring information. Now they’re also writing instructions for an AI system.
I understand why companies start this way. A general tool is easy to make available, and it gives people room to experiment. But experimentation and production work are different things. A process that depends on every employee assembling the right prompt every time is carrying more manual work than it appears to be.
Start with the work, not the tool
The better question is not, “How do we get employees to use AI?”
It’s, “Where does the work become unnecessarily hard?”
For the account manager, the problem might be that information about one customer is scattered across email, meeting notes, product data, support records, and the customer relationship system. Preparing for a meeting means reconstructing the story by hand.
That’s the operating problem. AI may help with part of it, but the employee shouldn’t have to rebuild the whole story in a chat window first.
If the meeting is already on the calendar, that is a natural trigger. The system could gather the information the account manager is allowed to see, identify recent changes or unresolved issues, and prepare a briefing inside the workflow where the meeting is being planned.
The employee still decides what matters. They still notice when something feels wrong or when a customer needs more care than the data suggests. What changes is the amount of searching and assembly required before that judgment can begin.
The same principle applies elsewhere. An escalating support case, a contract discrepancy, or a sudden change in customer activity already creates a signal inside the business. Employees shouldn’t have to notice the signal, leave the system, explain the situation to another tool, and then carry the answer back.
Put the assistance where the decision is already happening.
Context is part of the design
Bringing AI into a workflow does not mean showing employees everything the system can find.
Most companies already have too much information. The useful design question is what this person needs, at this moment, to make this decision.
For an account manager, that might include recent conversations, open issues, upcoming milestones, previous commitments, and a meaningful change in product activity. It probably does not mean every document, message, and activity record connected to the customer.
Too little context makes it hard to evaluate the system’s recommendation. Too much context sends the employee back into the same pile of information they were trying to escape.
I’d aim for the minimum context required for informed judgment. Enough that the employee can understand why the system reached its conclusion, challenge it when necessary, and decide what to do next.
That choice should be made as part of the workflow design. It shouldn’t be rediscovered by every employee through trial and error.
Governance shouldn’t depend on memory
The same is true for permissions and review.
Employees shouldn’t have to memorize which information they can share with an AI tool or which actions the system is allowed to take. Those boundaries should be built into the process.
A support assistant might be allowed to retrieve account history and draft a response without being able to send it. An account management tool might flag possible customer risk while leaving the final classification to the employee. A finance process might resolve clean matches automatically and route uncertain ones to a person.
The right boundaries will depend on the work, the quality of the information, and what happens if the system is wrong.
That’s why a blank chat window is such a weak place to carry governance. It turns company policy into a personal memory test. The employee has to remember what is allowed, apply the rule correctly, and recognize when the situation requires additional review.
A well-designed process carries more of that burden itself.
Teach people through the work
Employees still need AI literacy, but I don’t think generic prompt training is the best foundation for it.
People need to understand what a system can see, what it can’t see, where it is likely to struggle, which decisions they still own, and what to do when something looks wrong. Those lessons become much more concrete inside a real workflow.
Give a support agent an AI-assisted process and practical questions surface quickly. Why did the system recommend this response? Why did it miss the earlier conversation? What happens when I reject the draft? Can I mark this customer as an exception? Does anyone review recurring mistakes?
Those questions teach people about context, data quality, confidence, human review, and automation boundaries through work they already understand.
That is more useful than teaching everyone to write increasingly elaborate prompts. The goal is to make employees competent participants in an AI-assisted process, not turn the whole company into amateur prompt engineers.
Prompt skill is design feedback
If one employee consistently gets better results because they know the right instructions to give the system, I would study what that person is doing.
What information do they include? What sequence do they follow? What do they check before trusting the result? Which exceptions do they recognize?
Their skill may reveal something important about the work. But once the pattern is understood, the repeatable parts should be built into the process.
Prompts are useful during exploration. They help a team discover what the system can do and which context changes the answer. A production workflow should not depend on every employee remembering the same instructions and applying them perfectly.
The more important the work, the less it should rely on improvisation.
Make the complexity belong to the system
Good workplace technology eventually becomes an ordinary part of how the work happens.
Employees don’t need to understand database architecture before updating a customer record. They don’t need to know how email is transmitted before sending a message. The product carries much of that technical complexity for them.
AI should move in the same direction.
Employees need enough understanding to question the system, recognize its limits, and remain responsible for the judgment their work requires. They shouldn’t also have to act as data integrators, policy experts, and prompt engineers just to receive useful assistance.
Start with the work. Gather the right context. Build in the boundaries. Teach people through decisions they already know how to make.
If employees have to become good at AI before the system becomes useful, the design is asking too much of them.