PMs who write specs inside an AI agent keep hitting the same ceiling: the chat connects to nothing, remembers nothing, and can't say who actually said what. The fix isn't better prompting - it's grounding the agent in a research corpus it can cite.
Some product managers now spend their whole workday inside tools that were never built for product managers. One of them told his story to a room full of other PMs on Reddit. It reads like a confession:
"More than half of my working day now happens in a terminal and VS Code. I'm a Product Manager. That's not supposed to be what my days look like."
- a PM in a Reddit thread, on using an AI coding agent for product work
If you write specs or PRDs with an AI assistant, you already know part of his story, because you've walked the first steps yourself. It starts with a normal chat tool. That tool is actually useful - for writing, for quick questions, for a first draft of almost anything. Then, at some point, the work stops being generic and becomes your work. That's when you hit the same wall he did:
"It was fine for writing and quick questions, but it had a ceiling. It couldn't connect to anything real, didn't know my context, and every conversation started fresh. I kept running into things I wanted to do that it just couldn't do."
Read that middle sentence again. It's really three problems in one. Couldn't connect to anything real: the model can't see your data, your documents, or your users. Didn't know my context: it can't tell your product apart from any other product. Every conversation started fresh: whatever you taught it yesterday is gone today. Three things are missing - connection, context, and memory - and none of them is about how smart the model is. AI companies will keep making smarter models, and none of that extra smarts will fix these three problems. They aren't brain problems. They're plumbing problems.
For most PM work, this wall is just annoying. For discovery work - figuring out which user problems are real and worth solving - it's a dealbreaker, for a reason this essay will explain slowly, because the reason matters more than the conclusion: an AI with no connection to your research can't hand you real evidence. It can only hand you words that sound like evidence. And that gap - real evidence versus words that sound real - is exactly what discovery exists to protect.
Let's stay with the Reddit PM a bit longer, because what he did next is the most useful part of his story. He didn't try harder prompts. He rebuilt his whole setup:
"What started as me trying to get some data analysis done turned into building an entire work setup: workflows connected to databases, Notion, Slack, Gmail... There's something called MCP servers that lets you plug all of this into one place, and once you set it up it starts to feel like the tools are actually built around how you work rather than the other way around."
Once he fixed the connection problem, he fixed memory too:
"I have a custom memory system now where each session saves what worked, what went wrong, what decisions were made. Each project has its own context and history so the next session picks up where the last one left off."
He summed up the lesson in one line, and this whole essay is built on it: "What I think actually makes it useful is what you build around the AI, not just the AI itself." The model was never the problem. What he built around it was.
He's not one of a kind. He's just early. A senior PM we talked to, at a business-intelligence company, described his team doing the exact same thing - and he brought it up without us even asking:
"We have a set of skills that pulls all the data from the insight database in Notion, and uses it to write PRDs and design docs."
- a senior PM at a business-intelligence company
A head of product at an edtech company told us how she won a big argument at her company. Her CEO had called a product direction "ảo" - fake, an illusion. She didn't argue back harder in the meeting. Instead, she asked an AI assistant to write a research brief on the idea. The brief pointed to real companies already proving the idea worked. Her CEO read it, checked the sources himself, and changed his mind. The AI did real work in a real decision - because she pointed it at something real.
Three different teams, three different setups, one same answer: the PMs getting the most out of AI are not the best prompt-writers. They're the ones who gave the AI real material to work with - the same material their own judgment already runs on. That raises the real question behind this essay. For discovery work specifically - specs, roadmaps, the sentence in a PRD that starts "users struggle to..." - what is that material? And what does your setup need to protect so the output can actually be trusted?
The answer is hiding in a story a PM at a logistics company told us. At first it sounds like it has nothing to do with AI at all. Her team learns things the way most teams do - in meetings, on field visits, or just walking up to someone's desk - and everything they learn gets written into one shared doc. Then comes the part she said is the only way they can trust that doc:
"Any information we put into the doc, my manager double-checks: whose idea is this? Who said it? Why did they say it? And how is it different from what he already knew from the meetings before?"
- a PM at a logistics company
Her manager isn't being difficult. He's running the only test that tells real knowledge apart from made-up stories in a shared doc: every claim has to survive being traced back to its source. And she was honest about how hard that test is to pass, even with notes written entirely by humans:
"It can happen in a meeting, on a field trip, or when I just walk up to someone's desk. So it's quite hard to verify without enough context, or some way to double-check."
Now add an AI agent to this picture. When an assistant writes the first draft of your spec, the sentences about your users have to come from somewhere. If the agent is connected to your real research, those sentences come from your real research. If it isn't - if it's the blank chat tool from the first section, smart but empty - those sentences come from the model's general idea of what users like yours usually say. They'll sound smooth and believable, but nobody can say where they came from. They're made-up stories, built on the spot by a machine, and they fail the manager's test the second anyone asks: who said this? Nobody said it. It just sounds like something somebody might say.
The edtech head of product - the one whose research brief changed her CEO's mind - put a name to the skill this moment demands. She was talking about how AI had changed her team's work:
"Now that there's AI, we have to use judgment more - not just execute."
But judgment isn't just a feeling - it needs something to work with. You can only judge an AI-written claim about your users if you can set it right next to what a user actually said. So a good discovery setup needs one more thing than the Reddit PM's setup had. Connection, context, and memory get the agent to relevant. Discovery needs a fourth thing: provenance - meaning every claim can be traced back, on demand, to a real conversation and the exact words inside it. An AI agent either picks up good evidence habits from what it reads, or it hides the missing evidence behind confident-sounding writing.
With that requirement in mind, the common setups sort themselves out fast.
Pasting transcripts into the chat - or into a project folder the assistant can see - is the first thing almost everyone tries, and it really does ground the conversation you're having right now. But then the first missing piece from the start of this essay shows up again: every conversation starts fresh. The pasted context disappears when the session ends, next week's spec starts from a blank agent again, and nothing builds up over time. You've grounded one chat. You haven't built a habit.
The insight-database-plus-skills setup - what the BI company built - is the more serious option, and it deserves real credit: it's connected, it lasts, and it's genuinely useful for writing PRDs. Its weak spot is quieter. A general-purpose doc tool stores whatever gets typed into it, and what usually gets typed into an insight database is conclusions - themes, summaries, the leftovers of work someone already finished. When an agent quotes that database, it inherits the conclusions but not the words behind them, and the manager's question just moves down one level: the spec points to the database, but what does the database point to? Unless someone kept the habit of attaching the exact quote to every row - and a doc tool never asks anyone to do that - the evidence trail broke the moment the conclusion got written down.
And the fully custom route - the Reddit PM's memory system, session logs, and skill library - solves everything except its own cost. By his own cheerful admission, he's basically running a second job as his own IT team. He also almost never started: "I kept convincing myself that it was too technical, that it was built for engineers." Most PMs who hit the same wall won't build what he built. People like him matter here as proof, not as a plan to copy: they show the need is real enough that people will build the fix by hand.
All three workarounds are really reaching for the same missing thing: a place to store research where the basic unit isn't the document and isn't the conclusion, but the evidenced claim - the user's exact words, tied to where they came from, tied to the problem they point to - kept somewhere lasting that an agent can read from and write to.
That's exactly what a CLRA workspace is, and the CLRA MCP server is how your agent reaches it. The structure comes first, because the MCP server is only as good as what it can show your agent.
In CLRA, research lives in three connected layers. Interviews hold the raw material - the exact notes from a call, a field visit, or a community thread. Highlights are the quotes that matter, each one tied to the exact spot it came from and tagged for what it is - pain, worldview, jargon, or observation. Problems are job stories - when I'm in this situation, I want this, so that I can get that - and each one stays linked to the highlights that back it up. This turns the logistics manager's question-and-answer test into something built right into the tool: claim, to quote, to conversation, one step at a time.
The MCP server opens up that whole chain to whatever AI agent you already use - Claude, Cursor, anything that speaks MCP. And it works in both directions.
Getting new research in is simple. Say notes from your last three calls are sitting in markdown files. Your agent can send them straight into the workspace as interviews - no copy-pasting, no upload screen. CLRA's AI then does the work of pulling out candidate highlights, each one tied to the exact words it came from, and you decide what's real and what isn't - the same judgment call the edtech lead described earlier, now with real material to use it on.
The daily change happens on the reading side. Mid-spec, your agent can search your problems and pull up what it finds - not made-up themes, but problems your team actually wrote, with the quotes and speakers attached. So the sentence about your users in the PRD comes with a real problem behind it, real words behind that problem, and a real conversation behind those words. When a stakeholder asks "who said this?", you don't have to shrug or guess. You get a name, a sentence, and a source, one click away.
The research base your agent searches is the same problem map your team already keeps up - job stories, ranked by priority, each one showing how much evidence backs it up:
Unlike a general research folder, or an insight database sitting in a doc tool, CLRA is built around job stories with evidence attached to them, not free-form pages - so what your agent pulls up stays tied to what users actually need, not to what some old summary once said about them. And because the workspace saves and builds up over time, the third missing piece from the start of this essay gets fixed too. The agent you open tomorrow starts with everything your team has ever saved, not with an empty screen.
Let's go back one last time to the PM whose day moved into the terminal. It would be easy to read his story as a warning - a tool that outgrew its user. But the better reading is the opposite. He saw something true before most of his peers did: an AI assistant is only as good as the context it can reach. So he paid the price of building that context by hand, one connection at a time, one memory file at a time. He wasn't wrong. He was just early, and he was building something general-purpose.
Discovery work needs that same move, plus one thing his setup never had to guarantee: that every claim about a user can be traced back to the real person who said it. In product work, real conviction is earned one quote at a time. An AI agent grounded in a research base that keeps those quotes inherits your team's conviction. An agent grounded in nothing just makes up its own - and hands it to you in writing that sounds confident enough to ship.
The next spec you write with AI will contain sentences about your users. Decide where those sentences come from.
Give your agent something real to read: create a free workspace and connect it through the CLRA MCP server. And if your discovery starts in online communities, the CLRA extension captures the exact quotes that make your research base worth citing.
