The most common way an AI rollout dies inside a small business is quiet. The tool doesn't crash, doesn't throw errors, doesn't make anyone angry enough to complain. It just sits there while people drift back to doing things the way they did before. Six weeks after the launch email, you're paying for seats nobody opens.
The reflex fix is more training: another walkthrough, another memo, another "let me know if you need help." That targets the wrong problem. When people don't use a capable tool, it's almost never because they don't know how. It's because the tool was set up — where it lives, how it reports, what it shows, whether it has a name — in a way that makes ignoring it the path of least resistance.
There's useful evidence sitting in consumer AI right now. Meta's Muse is an agent people apologized to — including, famously, the design director's own mother, who had never really used anything he'd built before. The design reasoning behind it is public record: Alex Cornell, Muse's design director at Meta, has walked through the decisions on the record. Strip out the Meta-scale specifics and four of those decisions translate directly to the ten-person version of the problem. None of them require design skills. All of them are things an owner decides in an afternoon.
Fix 1: Put the agent where conversation already happens
Muse's foundational decision is that it feels like messaging, not an app. The same interface works for Cornell's mother and for an engineer because it runs on the pattern everyone already knows: you talk to it, it talks back.
Most internal rollouts do the opposite. The agent arrives as a destination — a new portal, a fresh login, a blank text field, a tour modal. Every new place to work is a tax, and busy people don't pay taxes voluntarily.
The advice version: don't launch the agent as a place people have to go. Put it in the Slack channel, the Teams thread, or the shared inbox your team already lives in, reachable as an address they can message. If your team runs on a group text, that's where the agent should answer. Adoption is mostly a location decision.
Fix 2: Show status in three layers, not one
Muse ships with a three-layer status display — a simple layer for what's happening, a detailed layer for those who want more, and a technical layer for people who need the internals. One interface serves your mom and an engineer. There is no separate "easy mode."
Internal rollouts almost always pick one layer and get it wrong for everyone. The ops manager gets pasted with a wall of agent logs she never asked for; the owner gets "done!" with no evidence trail at all. Both are status design failures.
The advice version: standardize a three-line status habit on every delegated job. Line one, what it's doing, in plain words ("chasing the unpaid Acme invoice"). Line two, what it's done so far, for whoever wants to drill in. Line three, the raw detail — prompts, sources, steps — available on request, never pushed. The rule: detail is opt-in, never ambient. People ignore things that shout at them in the wrong register.
Fix 3: Hide the implementation
Consumer agents practice progressive disclosure: they show the outcome and let you dig toward the machinery only if you want to. Cornell's design also accepts something internal rollouts rarely do — the output is never pixel-perfect, and users shouldn't be asked to evaluate the plumbing.
The internal version of this mistake looks like a manager forwarding a 40-step agent trace with "can someone check this?" Nobody should be asked to review prompts. That's asking a non-technical person to grade an implementation — the one task they were promised they'd never have to do.
The advice version: review results, not process. Show the finished work, the sources it used, and what to spot-check — that's the dig path. If the only way to trust a job is to read how the agent did it, the job is delegated wrong: give it a cleaner spec with a verify step instead. Trust attaches to outcomes; forcing people to read internals produces the opposite.
Fix 4: Let people relate to it
The most-discussed Muse detail is the apology. People say "sorry" to it — because it's a presence with a name and a face that they address directly, not a utility they operate. That's not sentimentality; it's engagement mechanics. People maintain relationships with things they address. They ghost tools.
Most internal agents launch as infrastructure: an anonymous "AI tool" in a portal, with no name, no owner, and no entry point anyone remembers. Two weeks later it's furniture.
The advice version: give the agent a name, let people address it directly — even "just" in a chat thread — and assign one human owner everyone knows. The name matters more than it sounds. "Ask Marlowe to do X" is a sentence a team member will actually say out loud; "submit a request through the automation tool" is a sentence nobody will. This isn't pretending the AI is a colleague or an employee; it's giving the thing an address people can form a habit around. Habits need handles.
The boundary design can't cross
None of this rescues a tool that doesn't work. If the output is slow and a little wrong, people stop asking it for things — and they're right to. Design fixes adoption, not correctness. So order matters: first confirm the agent reliably finishes one boring job your team actually wants done. Then design the rollout around it — right location, layered status, hidden plumbing, a name. The reverse order fails both ways: a beautiful rollout of an unreliable tool burns trust you'll need later, and a reliable tool nobody opens is a subscription, not a capability.
The afternoon retrofit
If you already have an AI tool nobody uses, run the retrofit this week:
- Relocate it. Pick the chat thread your team uses daily. Give the agent an address there. Stop mentioning the portal in your messaging entirely.
- Standardize the three-line status. Write the format down once and make it the default for every delegated job.
- Strip the internals from every report. Outcomes plus sources, dig on demand.
- Name it and assign it. A name, an owner, one sentence in the weekly meeting: "This is how you ask it for things."
- Retire or renew in 60 days. If usage is still zero after the retrofit, the tool is the problem, not the team. Cancel it and spend the money where the boring work actually happens.
The teams that get real value from AI aren't the ones that bought the best model. They're the ones that made using it the easiest behavior in the building. That's a design outcome, and it's within a small business's reach on any budget.
If you want the full framework for making an agent earn its seat — the permission ladder, the boring first assignment, the first-month inspection habit, and the one-page process format that keeps your context portable — it's all written down in The AI Agent Owner's Playbook. $49 CAD, instant download.
Top comments (1)
The location point matches what kills most internal tools: the new place to check is the first thing a busy week deletes. An agent that answers inside the thread people already read gets judged on its work; an agent behind a login gets judged on the login. The status layers are the second half of the same decision. What it is doing belongs in the channel, what it did belongs one click away, and the raw trace belongs with whoever maintains it. When those three land in the wrong place, each audience decides the tool is broken for a different reason, and the owner reads the resulting silence as an adoption problem instead of a placement problem.