A sales employee builds a useful internal chatbot. It works on their machine. A colleague asks to use it, and can't.
That was the problem Garrett Galow described in an October 2026 WorkOS presentation. The employee had figured out how to build the thing. Making it available to other people still required engineering help.
I keep coming back to that second part. Not because the prototype was a failure, but because the prototype had done its job. It proved that one person could make something useful in one setting. It hadn't established what would happen when the tool needed to become somebody else's ordinary Tuesday.
An AI workshop can produce an energetic room, a working demonstration and a genuine change in what participants feel able to try. I wouldn't dismiss any of that. Protected time to learn can be the reason somebody gets to try a tool at all.
But a workshop ends. The work it introduces is supposed to continue. That's a different design problem.
A cohort designed around actual work
At the same October 2026 conference, Automattic's Em Shreve described a program of two-week, in-person AI immersion cohorts for employees of a distributed company. Roughly half the cohort time went to guided learning and half to projects from participants' real jobs.
That split is more consequential than it sounds. A classroom exercise can show that a model follows instructions. A real task immediately adds inconvenient questions:
- Does the information exist in a usable form?
- Is the output worth checking?
- Will anyone need the result again?
- Can the method fit into an already crowded day?
Shreve described work including a WooCommerce analytics tool, a Zendesk integration that could contribute to shared internal capabilities, and a support specialist's screen-guidance tool. They were different kinds of projects, not comparable units of productivity saved. The common feature was that employees weren't being asked to build imaginary examples merely to demonstrate that they understood a lesson.
The cohort also had a social structure. Participants demonstrated their work to one another, exchanged ways of working across roles and learned about reusable internal skills and Model Context Protocol integrations. Shreve described follow-up coaching, peer support, local gatherings, a help channel and maintenance of the learning material as tools changed.
This is the part I find interesting. The workshop wasn't presented as a self-contained magic trick. Automattic had designed things that might help the learning survive outside the room.
Designed is the important word. Shreve reported seven cohorts of around 45 people at the time of the talk, along with follow-up surveys at 72 hours, 30 days and 90 days. Those details establish the program's described scale and its attempt to observe what follows. They don't establish that the cohorts caused a particular increase in productivity or sustained adoption. The underlying comparison, survey methods and independent outcome verification weren't available in the material examined for this article.
There's enough evidence to understand the proposed handoff. Not enough to pronounce it a proven success.
Three things that are easy to call adoption
The word adoption is doing too much work when the same report uses it for workshop attendance, a promising prototype and a tool that colleagues rely on every week.
I find it more useful to keep three questions separate.
Did someone encounter and practise the capability? Attendance, course completion and immediate confidence can tell us something about exposure. Even a good session evaluation doesn't answer what happens after the event.
Did someone use the capability on meaningful work? A completed work project is stronger evidence than a classroom demonstration. It still tells us about a particular task and setting. It doesn't establish that the result is discoverable, reliable or transferable.
Can the work continue without recreating the workshop? Now the questions involve access, ownership, support, review and maintenance. Could another person use what was made? What happens when the original builder is unavailable? What changes when the tool or underlying model changes?
These aren't three ranks that everyone must climb. A finance colleague may need a dependable shared tool, not the ability to maintain its integration. An engineer may need to build that integration and make it usable by someone else. What matters is the handoff between the people and conditions involved.
If someone leaves a workshop knowing how to create an AI-assisted process, but the process exists only in their private workspace, the organization has gained one person's capability. It hasn't necessarily gained a repeatable way of working.
The support nobody photographs
A shared help channel isn't as photogenic as a demo. Neither are office hours, a maintained connector or a colleague showing someone else how to adjust a workflow. They are, however, plausible answers to the problem of what happens after a promising first attempt.
A September 2026 Zapier customer account of Jobber describes Ethan Schwandt's work around leadership sessions, practical workshops, office hours, governance help and onboarding. Different formats serve different moments. A session may make experimentation visible and legitimate. Office hours give someone a place to bring the task that didn't fit the lesson.
In another Zapier customer account, Klaviyo's Doug Hamilton describes an AI Tech Stack Tracker that helps translate changes across tools into information relevant to his team's roles. The account also describes coaching, workshops, shared discovery and a registry of colleague-built work. A tool update becomes more useful when someone can see why it matters to their job; a useful experiment becomes easier to reuse when someone else can find it.
And a 2025 Klue customer story describes teams repeatedly building similar automations because their work wasn't easy to discover or reuse. Its response was a modular framework with shared connections and building blocks.
Klue's situation is not principally a workshop story. That's why it's a useful contrast. People may know how to build things and still leave an organization with a pile of one-offs. Individual capability and shared capability are not the same asset.
These are vendor-published customer accounts. Their descriptions of programs and workflows can illustrate the mechanisms organizations say they've put in place. Reported builder counts and time-saving estimates are not independent measurements of what those mechanisms caused. I wouldn't use them to calculate a general adoption success rate, or to declare that these companies have solved the problem.
I would use them to ask a more specific question:
Where does a useful method go when its original maker is no longer the person standing beside it?
A prototype can be finished while the handoff isn't
The WorkOS account makes that question more concrete. In Galow's talk, the sales employee's chatbot wasn't useless. It was inaccessible to a colleague because of an account dependency. The organization's next task involved a way to host and distribute employee-built applications without sending every request through an engineer.
Galow described coaching sessions, a shared command-line starter toolkit and an internal platform called Atlas. A separate WorkOS company account similarly describes shifting the central AI group's effort from handling individual requests toward making capabilities available for others to use.
That is a response to an operational bottleneck, as reported by WorkOS. It isn't evidence that every internal app became safe, maintainable or correctly authorized. Galow described company single sign-on, logging and managed secrets, but finer-grained group and role permissions were described as future work in the October presentation. His adoption and contribution figures were company-reported, not independently audited.
The boundary matters because somebody can build it and other people can depend on it are very different claims. Moving from the first to the second can require boring, indispensable work: access rights, secrets, discoverability, maintenance, escalation and a person who will answer when something breaks.
An enablement program can't solve all of those with a better slide deck.
This is also where the argument could easily sprawl into a separate article about deployment platforms. That's not the point I'm making here. The point is that training may remove the obstacle of not knowing how to start while leaving the next obstacle untouched.
What would I actually count?
It would be convenient if all of this collapsed into one adoption percentage. The trouble is that the measures don't all describe the same thing.
A workshop can report seats filled, people trained and demos completed. Useful figures, if we're asking about the workshop. A follow-up survey can ask about confidence, intended use or self-reported practice. Useful for finding out what participants say changed. Neither automatically proves improved work outcomes.
A better account would keep its questions separate:
- Work performed: Was the new capability applied to an actual task with an inspectable result?
- Continued use: Did the practice recur outside the learning environment, and over what period?
- Transfer: Could someone other than the first builder find, use or extend the result?
- Operation: Was there an appropriate route for access, review, maintenance and failure recovery?
- Outcome: Was there credible evidence of better quality, less effort or a newly possible result, with a sensible basis for comparison?
Those questions don't demand a clinical trial for every internal workflow. They do demand that a confidence survey not be relabeled as productivity, that usage not be equated with quality, and that a reported time-saving estimate remain an estimate unless its method supports more.
An organization might learn something valuable from a 30-day survey even if it cannot isolate the effect of training. It might discover, from repeated use, that a tool is worth maintaining. It might also learn that a workflow creates more review and cleanup work than the first demo suggested.
I'd rather have that untidy picture than a confident metric that combines unlike things.
The work after the event
Workshops can still be the right place to begin. A protected two-week cohort is one possible design. A modest working session followed by a named support contact may be enough somewhere else. The required level of shared infrastructure and oversight depends on the work and its risks. There isn't one adoption architecture every organization ought to copy.
What the accounts have in common is a problem worth keeping visible:
Somebody learned or built something, and the organization still had to decide how that capability would travel, survive and be looked after.
Automattic describes a deliberately supported learning-to-work transition. Jobber and Klaviyo describe ongoing help and discoverability. Klue describes making individual automation work reusable. WorkOS describes the access and distribution problem waiting after an app has already been built.
None of those accounts proves a general causal improvement in enterprise productivity. Taken together, they do give us something more useful than another declaration that everyone needs AI training.
They show the different jobs hiding behind the phrase drive adoption.
// End of transmission. Keep the work alive. — ZYANE