Multiple people on our team interview students every week. Documenting each conversation — downloading the recording, anonymizing the transcript, structuring the findings, publishing to Confluence — used to take longer than the interview itself. So we walked an AI agent through the process, packaged the result as a plugin, and shared it. Now anyone on the team can run the entire pipeline with one command. But the interesting part isn’t the interview plugin — it’s the pattern: automate once, share as a plugin, and suddenly the whole team benefits.
What Friction Actually Looked Like
After each conversation comes the documentation: move the recording to OneDrive, download and anonymize the transcript, open the right project, find the correct Confluence space, then switch to TheyDo to mine insights. All of it was documented in a detailed guide.
For those who interview regularly, the process was manageable — if slightly tedious. But the real cost showed up with colleagues who ran interviews less frequently. When you only do something every few weeks, documented doesn’t mean familiar. Every time was essentially the first time again. The guide existed precisely because the process couldn’t be held in memory. That’s not a people problem — that’s a workflow too fragile to scale across a team.
The risk wasn’t that insights got permanently lost. It was that they got delayed, deprioritized, or handled inconsistently depending on who ran the interview and when they found the time.
That’s what we set out to fix. Now the entire pipeline runs with one command. An AI agent handles every step, from the recording in Teams to a structured insight page in Confluence, following the team’s existing templates and taxonomy.
But the more interesting part is the pattern behind it.
The Pattern
We walked our local AI agent through the process step by step — and it learned from it. No scripting, no workflow engine. Just guiding the same agent we already use every day, and being precise about what good research documentation looks like: which fields matter, what counts as evidence, how to separate observation from interpretation.
Then we packaged the result as a plugin and put it on our team’s internal plugin marketplace — a shared repository where anyone can browse and install automations. A colleague who interviews students tomorrow can use it directly. And when we improve the plugin, everyone who uses it benefits immediately.
The interview plugin isn’t our only one. We’ve built automations for other recurring workflows the same way: an AI agent that explores our mobile app and files UX issues, automated weekly team updates that pull from Jira, Confluence, and Git. Each one built by the person who knows the process best — a PM, a designer.
Automate a process once. Package it as a plugin. Share it. Suddenly the whole team benefits — and nobody had to write code.
The Interview Is Human. The Pipeline Isn’t.
The interview itself is irreplaceable. A researcher reads the student’s face, follows up on hesitation, notices what they don’t say. That’s not something you automate.
Everything that happens after the conversation ends — downloading, transcribing, protecting data, structuring, classifying, documenting — is pipeline work. It requires consistency, not judgment. The agent chains together six steps, from finding the recording in Teams to publishing in the right Confluence space. The output follows the same template a researcher would produce manually: participant overview, behavioral insights grounded in direct evidence, opportunity areas, and an experience map.
People on the team were already using AI for parts of this process — summarizing transcripts, drafting notes. The change isn’t that AI is involved. It’s that the entire pipeline is now one uninterrupted flow, and anyone can run it.
From Plugins to Pipelines
One plugin is a convenience. Multiple plugins, built by different people for different parts of a workflow, start to connect.
Right now, the interview plugin produces a structured insight page. But a single snapshot in Confluence doesn’t drive decisions on its own. The real value comes when insights from dozens of interviews get bundled with feedback from other channels — in-app analytics, surveys, support tickets — and that combined view becomes accessible to everyone who has a voice in the roadmap.
That’s the direction we’re working toward. Not just faster documentation, but a layer that connects the plugins: interview insights, feedback data, usage patterns — flowing into a shared understanding of what students actually experience. We’re not there yet.
What We’ve Learned
The hard part isn’t technology. It’s noticing which processes are worth automating — and being precise enough about them that an AI agent can execute the steps reliably.
The person closest to the work is the best person to build the plugin. Not because it requires code, but because they know what good output looks like. A designer knows what a useful interview snapshot contains. A PM knows how to structure a team update. That domain knowledge is the real input.
There’s a secondary effect too: building a plugin forces you to set up a local AI agent, connect it to your tools, and think precisely about your own process. That initial investment pays off far beyond the plugin itself — it changes how you work day to day.
We’re ending up with an infrastructure for turning domain knowledge into reusable capability — no code required.
Leave a Reply