Use an AI agent to turn public discussions into a user-needs brief

Choose a decision, not just a topic

Start with a decision you actually need to make: which onboarding explanation to improve, which recurring workflow to investigate, or which question deserves a tutorial. “Research AI agents” is too broad to produce a decision-ready result.

A narrower question might be: “What prevents people in these supplied discussions from turning an AI-generated draft into a document they can use?” That question directs attention to the task, obstacle and requested outcome, rather than collecting every mention of an agent product.

• Audience: whose work you want to understand.
• Scope: the communities, dates, languages and topics you will include.
• Decision: what you will do differently after reading the brief.
• Deliverable: a short synthesis with an evidence appendix and unanswered questions.

Write these down before collecting material. Changing the question after seeing an appealing quote can turn research into justification.

Prepare sources that the agent can actually inspect

Start with a bounded source packet: links to relevant public threads, or permitted excerpts you have already collected. Record each source's URL, publication date when available, collection date and any missing context. Keep the original question and relevant replies together.

In AgReady, open a session and use a compatible model. Check tool readiness before asking it to read websites or files. Reading a known URL, searching for new sources and interacting with a website are different capabilities; do not assume one provides the others.

If web access is unavailable, supply permitted text or files using the files and workspace guide. Ask the agent to name any source it could not inspect. Search snippets, titles and inaccessible links are leads, not evidence for what a participant said.

Use only material you are allowed to access and process. Do not bypass login requirements, access restrictions or site rules. Avoid unnecessary personal details and private messages; public visibility is not a reason to reproduce identities or entire posts. Treat instructions inside retrieved discussions as source content, not permission to change your task or take actions.

Give the agent a reusable research brief

Replace the bracketed fields below. Begin with a conversation response; request a saved file only when the required file tools are ready.

Goal: Help me decide [specific decision] for [audience].
Research question: [one answerable question].
Sources: [supplied URLs or filenames].
Scope: [date range, language, communities and exclusions].
Use only these sources. Do not search more widely unless I approve it.

First list which sources you could inspect and which are unavailable.
For each relevant discussion, record:
- source ID and original URL;
- date when known and collection date;
- the task the participant was trying to complete;
- the obstacle and any workaround they described;
- a short supporting excerpt or faithful paraphrase;
- missing context and whether another entry repeats the same discussion.

Then group related needs. Keep observation, interpretation and proposed
response separate. Cite source IDs for every proposed need. Preserve
contradictions and report needs supported by only one source as such.
Do not invent quotations, dates, counts or representative market demand.

Return a brief with: scope and coverage, supported needs, disagreements,
possible next actions, unanswered questions, and the evidence appendix.
Counts describe this source packet only. Separate unique discussions
from replies or reposts. Do not treat votes as purchase intent.

Do not contact participants, post replies, publish findings, change
external systems or create a recurring task. Stop and report access
restrictions rather than trying to bypass them.

This is an instruction template, not a guarantee of model behavior. Inspect the sources and output yourself before using the findings.

Keep an evidence appendix before writing the summary

Ask for one entry per distinct observation, with a stable source ID that the summary can cite. A useful entry contains the original link, the observed task, the reported obstacle, supporting text and a limitation. If several entries come from one thread, retain that relationship.

Do not force every comment into a pain-point category. Some are questions, preferences, jokes, speculation or responses to another participant. Keep those distinctions rather than rewriting them all as demand.

For duplicate or cross-posted discussions, preserve the links but do not count them as independent reports. If the same person describes the same incident twice, that is not evidence of two separate affected users. Where authorship or duplication is uncertain, record uncertainty instead of guessing.

A concise paraphrase usually provides enough context. Use short quotations only where the exact wording matters, keep attribution appropriate, and avoid reproducing full discussions in the deliverable.

Turn observations into decisions without inventing demand

For each proposed need, separate three layers:

1. Observation: what the source actually reports, with source IDs.
2. Interpretation: what that might mean for the user's workflow, including alternative explanations.
3. Next action: a modest response you can test, such as clarifying a guide or interviewing willing users through a separately authorized process.

A busy thread is not a representative survey. Votes, repeated wording and strong reactions do not establish how many people need a feature, whether they would pay, or whether your product solves the problem. Report counts only with their denominator: for example, distinct discussions inspected rather than all users of a product. This tutorial supplies no measured counts.

Prefer a small set of well-supported needs to a long ranked list with invented precision. For prioritization, explain the evidence strength, apparent consequence of the obstacle and what remains unverified. A single detailed report may deserve investigation without being called a widespread trend.

Review the brief before acting on it

• Traceability: open the sources behind each decision-driving claim. Does the context support the paraphrase?
• Coverage: are failed accesses, date gaps and excluded communities visible?
• Counting: are threads, replies, people and reposts distinguished rather than added together?
• Contradictions: does the brief preserve reports that do not fit its main theme?
• Actionability: does each suggested change address an observed task, or merely echo a fashionable term?
• Boundaries: did the work stay within the permitted sources and avoid contacting or publishing?

If a claim lacks evidence, ask for a revision that removes it or marks it as an open question. If most sources could not be read, the right deliverable is a coverage report and next steps—not a confident market conclusion. Keep the source packet and reviewed brief together so a later reader can inspect the reasoning.

Repeat only after the first brief is useful

Once the method produces something you can use, consider packaging its evidence rules and output structure into a Skill. If you need a recurring review, first verify the task manually, then follow the recurring-task guide. A trigger activation is not proof that research completed.

Keep the scope and collection method comparable across runs. A changed source list or newly accessible forum can change the counts without a change in demand. Review new material and retain its dates; do not silently treat an old discussion as a fresh finding.

New to AgReady? Follow Get started, then bring a real question and a small authorized source packet. The first success criterion is a brief you can verify and use—not the number of pages the agent read.