Where AI should stop in product discovery

At ThriveAI, we built an AI agent to help product teams investigate feature requests. It could search customer feedback, query product analytics, and inspect the available event data before a product manager decided what to build.

One client ran a consumer health membership app. An annual membership included two blood tests, which members could schedule through the product. After completing the first test, they needed to understand when the second became available, whether it was still covered by their plan, and whether the app would remind them to book it.

The product team wanted to know whether they should add that reminder.

The agent's first investigation made the feature look well supported. Then I traced its recommendation through the underlying feedback and telemetry. The evidence was real, but the connection between the sources was weaker than the answer made it sound.

The lesson for me was simple: an AI agent can gather evidence for a product decision without owning the decision itself.

The feature request was hiding several problems

The request initially sounded straightforward: notify members when their second blood test was due.

The feedback revealed a messier experience. Some members did not know when they became eligible for the second test. Some were unclear about whether the benefit reset on a calendar date or their membership anniversary. There were also cases where the booking flow appeared to ask for payment even though a retest was included in the plan.

A reminder might help someone who had simply forgotten. It would do less for someone who did not understand the eligibility rule or encountered the wrong price at checkout.

That distinction matters for a product team. One feature request was bundling together communication, entitlement, checkout, and notification problems. Treating all of them as reminder demand could produce a clean feature and leave much of the underlying experience untouched.

Two sources appeared to agree

The agent found customer conversations asking for reminders and clearer timing. It also found that members returned to the blood-test booking flow after completing an earlier booking.

Some returned within days. Others came back months later. That pattern made the reminder case look stronger: perhaps members were returning when their second test became due.

I inspected what the product events could actually establish. They showed that someone completed a booking flow and later opened it again. They did not record whether the person was arranging their first or second test, whether another test was included in their plan, or when they became eligible.

Someone returning within days could have been rescheduling the first test or recovering from an incomplete booking. Someone returning months later could have been booking the second. The data could not separate those journeys.

The support evidence had the opposite limitation. It showed that some members were confused, but it could not establish the size of the eligible population or whether a reminder would change behaviour.

The agent had found two useful signals. It had connected them with an assumption: repeat booking represented unmet demand for a second-test reminder.

I changed the agent's responsibility

The problem began in the objective I had given it. I had asked the agent to decide whether and how the reminder should be built.

That wording rewarded a recommendation. Faced with incomplete evidence, the agent assembled the most coherent case it could.

I rewrote the objective. The agent would gather evidence to help the product manager assess the feature. Its output had to keep three categories visible:

1. Direct evidence: members had questions about the second test, and repeat booking occurred.
2. Plausible interpretation: some later bookings might represent members using the second test in their plan.
3. Unresolved questions: the data could not identify test number, entitlement, eligibility, reminder delivery, or reminder-driven action.

This produced a more useful decision brief. The app could make the second-test benefit, eligibility rule, and checkout treatment clearer. The team could also add the missing product events and then evaluate whether reminders improved completion among eligible members.

The agent still did substantial work. It searched feedback, queried behaviour, inspected the event schema, and exposed the gaps in what the product could measure. The product manager could then weigh the evidence against cost, urgency, and other roadmap priorities.

Where I now draw the boundary

I want AI agents to make recommendations when the decision criteria are explicit, the outcome is observable, and the downside is bounded. Many product decisions do not begin that way.

A feature request can combine several user problems. Feedback can make a problem vivid without showing how common it is. Telemetry can show what happened without explaining why. A model can turn those fragments into a persuasive narrative long before the product team has earned the conclusion.

For product discovery, I now give the agent responsibility for finding the evidence, showing its work, and naming what remains unknown. The product manager remains responsible for deciding whether that evidence justifies a change to the product.

That boundary does not make the agent less useful. It makes the output easier to trust and gives the product leader a much better place to exercise judgment.