Gradual Community
Ask

What AI Can't Replace in Community: A Recap With Richard Millington

What AI Can't Replace in Community: A Recap With Richard Millington
# AI
# Community
# Format: Event Recaps

A recap of our Context First conversation with Richard Millington on what's actually left for community once AI answers most support questions.

August 11, 2026
Joshua Zerkel
Joshua Zerkel
Richard Millington
Richard Millington
What AI Can't Replace in Community: A Recap With Richard Millington
We host Context First to get one perspective in the room at a time, and for this session I wanted someone who has spent fifteen years inside other people's communities, not just his own.  Richard Millington  is the founder of  FeverBee , a community consultancy that's worked with over 320 organizations including Apple, Meta, Microsoft, Google, the World Bank, and SAP. He's the author of Build Your Community, and through his Community Management Academy he's trained more than 1,200 community professionals. When Richard talks about what's changing, he's talking about it across hundreds of communities, not one.
What he brought to our conversation was a working framework for what community is actually for, now that AI has taken over the part of the job most of us thought was the job.

Community stopped being the front door to the answer

Richard's starting point was a shift most of us have felt before we had language for it. For years, community absorbed the questions that were too complex for a help center and too personal or too low-stakes to justify a support ticket. Documentation and FAQs handled the easy stuff. Support handled the hard, individual stuff. Community filled the space in between: the questions that were common enough to matter but nuanced enough that no single official answer covered them.
AI has interrupted that middle. Retrieval-augmented generation doesn't send someone to your community to find an answer anymore. It assembles one from your documentation and fragments of community content and hands it over directly, often inside a Google search someone never expected to leave. Richard ran a live poll during the session asking people whether their community engagement had gone up, down, or stayed flat over the past year. The results were what you'd expect if you've been watching your own numbers: engagement is down for most of the room, in some cases by as much as 90 percent.
The line that stuck with me was this one: "Members are still getting answers from the community. The value of the community remains pretty much the same. Only now they don't need to visit the community to get the answer." That's a very different problem than the one most of us have been managing for. It's not that community stopped mattering. It's that the traffic stopped needing to show up to prove it.

The value didn't disappear, it moved to a different kind of knowledge

Richard's response to that shift was the most useful part of the hour: a simple way of classifying what a community actually knows, and being honest about which parts of that AI can already do as well or better.
  • Canonical knowledge. The official facts, specs, and policies. One true source, and AI or your documentation will retrieve it faster and more reliably than a community thread ever will.
  • Procedural knowledge. The steps to do something, written once and followed by thousands. Also a place where AI and search already do a solid job.
  • Experiential knowledge. What actually works in practice, usually surfaced by someone who tried something and found an edge case nobody documented.
  • Contextual knowledge. The answer that depends on someone's specific version, configuration, or situation, where the official answer is right for most people and wrong for this one.
  • Ephemeral knowledge. What's true right now, before anyone's had time to write it down. What's breaking, what just changed, what the team hasn't caught yet.
Richard was direct about the first two: don't try to compete with AI on canonical or procedural knowledge. You'll lose, and you shouldn't want the fight. What community actually has going for it is the last three, the kind of knowledge that doesn't exist anywhere until someone lives it and shares it.

Knowledge has a lifecycle, and community sits in the middle of it

The example that made this concrete was a data import feature. A product ships an update, someone hosts a webinar walking through it, and the recording goes into a thread. A member tries it and finds that the import times out silently past 5,000 rows. Someone else posts a workaround. A staff member or a power user eventually consolidates that thread into one verified answer. That answer gets pulled into a course. Eventually it hardens into documentation.
Richard's read is that this is the actual production line of knowledge, moving from ephemeral (something just broke) to experiential (someone found a way around it) to procedural (there's now a verified fix) to canonical (it's in the docs). He shared a real example from that same morning: a release had broken imports with European date formats, and the community's discussion thread knew about it forty minutes before support did. That's not a nice anecdote about engaged members. That's an early warning system that most organizations aren't set up to use.

Most organizations aren't structured to let that knowledge move

The problem, in Richard's view, is decentralization of tools and decentralization of ownership. Marketing owns the webinar, records it, posts it, and almost nobody watches it again. Education owns the courses, and they quietly go stale as the product changes. Support owns the tickets, and the good stuff in a resolved thread usually just dies there once the ticket closes. Documentation owns the official answer, and it lags behind what community already knows.
Every one of those functions is doing solid work in isolation. None of it is talking to the others. Richard's argument was that the fix is designing the handoffs deliberately, whether or not that adds up to a single platform: knowledge should have a predictable route from event to thread to verified answer to course to documentation, with a person deciding what gets promoted and AI doing the work of assembling and surfacing it along the way.

A decline in engagement isn't automatically a crisis

I asked Richard directly, because it's the question I hear most from other community folks right now: is AI actually reducing how much people want to interact with each other, or just reducing how much they need to visit a specific community to do it? His answer was that yes, AI is leading to a real decline in engagement in the communities he works with, but he doesn't think it reflects less demand for people to interact with each other. He thinks it reflects a misalignment between what a lot of communities currently offer and what members actually want from them.
That leaves two honest paths. One is to lean further into belonging: build the kind of social, peer-driven space people go to Reddit for, because that demand hasn't gone anywhere. The other is to accept that if your community exists mainly to support and inform, some decline in raw engagement might not be the tragedy it looks like on a dashboard, as long as the people who genuinely need it are still getting more value, faster. What worried Richard was a third option, the one nobody should take: denying the shift, or continuing to run the community the same way it ran three years ago. He compared it to publishers and booksellers facing ebooks, or the music industry facing streaming. Adapting quickly beats fighting a trend that's already won.
We didn't have time to go deep on two things Richard raised near the end that I think deserve their own treatment: how to actually measure a community's value once traffic is no longer the proxy for it, and how to get the rest of the organization to agree to build this integrated system in the first place. Both came up in the AMA, and both are meaty enough that we turned them into their own playbooks below.

Key Takeaways

  • AI has taken over the questions that used to route people into community, especially the ones with a single official answer.
  • The value of community hasn't disappeared, but it's concentrated in experiential, contextual, and ephemeral knowledge, the kind that only exists once someone lives it.
  • Knowledge moves through a lifecycle, from ephemeral to experiential to procedural to canonical, and community is usually where that lifecycle starts.
  • Most organizations lose this knowledge because it's scattered across disconnected tools with no deliberate handoff between them.
  • A decline in engagement doesn't necessarily mean declining demand for connection. It can mean the community isn't currently built for what members actually want.

FAQ

Is AI actually reducing engagement in communities, or just changing what people use them for?

Both, according to Richard Millington. AI genuinely is reducing raw engagement and participation in most of the communities FeverBee works with, in some cases significantly. But he doesn't believe that reflects less demand for people to connect with each other. He thinks it reflects a mismatch between what a given community is currently designed to offer and what its members actually want, which points to redesigning the experience rather than assuming the drop means community no longer matters.

What should community stop trying to compete with AI on?

Canonical knowledge (official facts, policies, and specs) and procedural knowledge (step-by-step instructions that don't change often). AI and good documentation already retrieve both faster and more consistently than a community thread can. Richard's advice is to stop measuring community's value against that kind of question and focus on the knowledge only community produces.

What kind of knowledge does community still create better than anything else?

Experiential knowledge (what actually works when someone tries it in the real world), contextual knowledge (the answer that depends on someone's specific situation or configuration), and ephemeral knowledge (what's changing or breaking right now, before anyone's had time to document it). All three require lived experience, which is exactly what a community of real users generates continuously.

How does community-generated knowledge actually turn into official documentation?

Richard described a lifecycle: an event or release surfaces something new, a community thread captures the real-world experience of using it (including edge cases and workarounds), someone consolidates that thread into a verified answer, that answer gets built into a course, and eventually it hardens into documentation. The bottleneck in most organizations is that tools and ownership are decentralized enough that this handoff never happens deliberately, even when the underlying knowledge is already there.
Comments (0)
Popular
avatar
ďťż
Dive in

Related