The most valuable AI idea I had today didn't come from AI

I recently came out of a meeting with a promising idea for an AI experiment. The interesting part is where it came from. It wasn’t an AI brainstorm, an agent demonstration or a particularly clever prompt. It came from sitting in an ordinary cross-functional meeting, listening to how people actually worked and asking some questions.

The meeting was about video discoverability. We were discussing the familiar problems: where videos live, who maintains the channel, how to make useful sections findable, and how existing interviews might support search and generative engine optimisation (GEO), the work of making material visible to AI answer engines as well as to conventional search.

It would have been easy to leave with a list of channel improvements: better titles and descriptions, more chapters, more clips. Those things may well be useful. But a different question started to seem more important. If an organisation has years of expert interviews, customer conversations and webinars, how does anybody find the exact answer they need inside them?

The problem behind the problem

I already had a working method for finding useful material in video. I take a transcript, put it into an AI tool, ask which sections answer particular audience questions, and check the suggested passages against the recording. It works for one interview, and I’ve used it to identify potential clips and turn spoken material into more useful editorial evidence.

But it has an obvious limit. What happens when the answer might be in one of fifty recordings, or several hundred? What if the videos sit in different folders, with inconsistent filenames, permissions and transcripts? At that point the problem isn’t primarily writing, video editing or even YouTube optimisation. It’s retrieval.

Someone in the meeting raised the possibility of keeping source files together in SharePoint, where transcripts may be available, and testing whether an AI search tool could retrieve relevant passages across the collection. That opened a practical line of enquiry: what could we find, how reliably, and with what source information attached? It was a much more interesting experiment than asking AI for another summary of another video.

The part that wasn’t automated

I don’t want to romanticise this. I didn’t invent the idea of searchable transcripts, and the meeting was a collaborative discussion. Colleagues knew the channel, the files, the operational restrictions and what might be technically feasible. My contribution was connecting their account of the operation with an editorial problem I already knew firsthand.

That took a few kinds of judgement. The first was knowing the work well enough to recognise that the current manual approach wouldn’t scale, because I had been doing it by hand. The second was asking about systems and ownership rather than assuming a new tool would fix everything. The third was recognising that this wasn’t only a video problem. If you can search recordings for verified answers to questions, why stop at recordings?

Customer case studies, interviews and other approved sources present a similar challenge. There may be good evidence that a customer’s reporting became faster, more accurate or better at supporting decisions. But if somebody needs that evidence for a new campaign, can they find the actual passage, or do they rely on a vague recollection or a polished summary?

The same underlying capability might help: find the evidence, identify its source, preserve its context, check its status and decide whether it can be reused. That doesn’t make a customer-evidence system the automatic next project. It makes it a sensible hypothesis to test once the smaller video experiment has shown whether retrieval works at all.

AI could accelerate the answer. It didn’t choose the question.

A lot of AI discussion centres on the quality of outputs: how fast a model writes, how well an agent follows a workflow, or how much production time it saves. Those are legitimate questions, and I use AI myself to examine ideas, document decisions and develop potential experiments. But there is an earlier stage of work that gets less attention, which is deciding what problem is worth solving.

That question is usually discovered in meetings, interviews, handovers, complaints, awkward workarounds and the small explanations people give for why something takes longer than it should. A model can help analyse a transcript of those conversations. It can compare options, turn a rough idea into a test plan or find patterns across recorded evidence. What it doesn’t automatically have is the lived organisational context, the relationships, or the responsibility for deciding that this problem matters more than the dozen others competing for attention.

The strongest objection is that the meeting could have been recorded, and a capable model given the transcript might well have flagged retrieval as the real issue. That’s plausible, and it will become more plausible as meeting tools improve. But the transcript would only have contained what people said. The pressure point came from knowing what my one-interview method felt like to run by hand, and from being in a position to ask the follow-up questions that turned a passing remark about SharePoint into a testable proposal. A model reading the record afterwards could have spotted the pattern; it could not have changed the conversation while it was happening.

A useful idea is not yet a successful innovation

There is a danger of getting carried away at exactly this point. A central searchable library sounds impressive, and an AI agent searching across every interview sounds more impressive still. Neither description tells us whether the results would be accurate, whether the system can respect access controls, or whether editors would trust it enough to use it.

So the test should be small. Give an approved tool a limited set of source videos and transcripts and ask it real editorial questions. Check whether it can identify the right recording, the right words and a usable reference or timestamp. Measure how much manual checking remains, and record the false matches as carefully as the successes.

If that doesn’t work reliably, the idea isn’t ready to scale. If it does, there’s a reason to try the same method on other evidence sources. The point is not to build the largest possible agent but to learn whether a painful piece of work can be made dependable and easier.

What this means for experienced content professionals

I’ve spent years thinking about writing and editing, and more recently about what AI changes in both. I still care about a good sentence and an argument that stands up. But that conversation was a reminder that editorial expertise also operates well before the draft.

It shows up when someone recognises a useful question, notices an unsupported claim, or understands the difference between a file existing and evidence being usable. It shows up when they see a connection between two teams that don’t describe their problems in quite the same way. That work is easy to overlook because it rarely leaves behind a visible deliverable. Sometimes all it leaves behind is a better question.

I don’t think the lesson is that humans have ideas and AI merely executes them. AI can suggest questions and reveal patterns people miss, and people can propose terrible solutions with complete confidence. The more practical lesson is that human judgement and AI capability do different jobs, and we should be precise about which did what.

This possible innovation came from listening, experience, collaboration and asking questions. AI may help us test it, and if the test succeeds, AI may help make it useful at scale. But noticing that an organisation had a knowledge-retrieval problem hidden inside a video-distribution conversation was editorial intelligence before it was artificial intelligence.