API-driven customer research is the architectural pattern where the research workflow — configuring a study, recruiting participants, running moderated interviews, retrieving findings — executes as programmatic operations rather than dashboard clicks. For teams already running on software pipelines, it is the natural extension: research becomes one more callable step rather than a context switch to a separate tool.
This guide covers what API-driven research means architecturally, why dashboards became the default and why they are now a constraint, the three orchestration architectures that cover most production deployments, and how User Intuition’s agentic research platform implements this pattern. For teams evaluating the specific tool surface, the full API documentation lives at docs.userintuition.ai/mcp-server/overview.
What API-driven customer research means
The dashboard has been the default research interface for two decades because it matched how research was done: a human researcher opened a tool, configured a study, launched recruitment, reviewed transcripts, and assembled a report. Each step required human judgment, human navigation, and human time. The dashboard was optimized for that model.
The model has changed. Product decisions now run on software pipelines — analytics platforms, experiment frameworks, CI/CD systems, AI agents that monitor signals and act on them. A research step that requires opening a separate browser tab breaks the automation chain. Research that should inform a shipping decision lands two weeks after the decision was made.
API-driven customer research replaces the dashboard interaction with function calls. Study configuration, participant recruitment, AI-moderated interview execution, transcript retrieval, and cross-study synthesis all become typed operations that software programs and AI agents can invoke. The research workflow runs embedded in the pipelines it is meant to serve.
This is distinct from simply having a REST API as a developer feature bolted onto a dashboard product. API-first means the API is the primary integration surface, not a secondary export mechanism. The full research workflow must be available programmatically, or the pattern breaks down at the steps that are not.
Why dashboards became the default — and why they are now a constraint
Dashboards became the default because research was a specialist function. A dedicated researcher used a dedicated tool. The dashboard’s UI was the product; the research workflow happened inside it. That model held as long as research was a periodic, human-driven activity disconnected from the software pipelines that ran the rest of the business.
Three shifts have made the dashboard model a constraint.
Shift 1: AI agents need research. AI agents that monitor product metrics, competitive signals, or customer behavior now need evidence — not simulated evidence from the model’s training data, but fresh signal from real people. A dashboard requires a human to operate it; an agent cannot.
Shift 2: Decision velocity has outpaced research cycles. Product teams ship weekly. Competitive landscapes shift monthly. A research process that takes 3-6 weeks from brief to findings is too slow to inform most decisions. Programmatic research — triggered automatically, run by an AI moderator, analyzed without human transcription time — compresses that to hours.
Shift 3: Research is now a step in a pipeline, not a standalone project. When a feature ships to 10% rollout, a post-launch study should be automatic. When NPS drops, a churn-reason study should trigger. When a competitor announces a new capability, a positioning-reaction study should run. These triggers are already captured in software systems; a dashboard requires a human to notice them and initiate the research separately.
The API-driven pattern resolves all three: agents can call it, it runs fast enough for decision cycles, and it embeds in the pipelines that already capture the triggering signals.
Three architectures
Most production deployments fit one of three orchestration architectures.
Architecture 1: Orchestrator-led
A central workflow engine calls the research API as one step in a larger pipeline. The orchestrator is typically an existing system — a data pipeline, a CI/CD workflow, a scheduled job, a product analytics trigger — that already captures the conditions under which research is warranted.
Example workflow:
Ask the agent to list the available research tools.
Use list_studies to identify a study and get_study_report to retrieve its evidence.
For new research, create and customize a draft, then approve the saved plan
and recruitment before fielding.The research step runs automatically within an existing workflow. No human initiates it; the trigger condition and the research response are both encoded in the pipeline.
Best for: Recurring research cycles where the trigger condition is already captured in a software system. Post-launch studies. Threshold-triggered research. Scheduled competitive monitoring.
Architecture 2: Agent-led
An autonomous AI agent decides when to commission research, what to ask, and what to do with the findings. The agent has judgment over the research lifecycle, not just execution.
Example workflow:
Ask the agent to list the available research tools.
Use list_studies to identify a study and get_study_report to retrieve its evidence.
For new research, create and customize a draft, then approve the saved plan
and recruitment before fielding.The agent makes the decision to research, not just executes a research step in a fixed workflow. This requires a research API that supports full end-to-end automation with no mandatory human handoffs.
Best for: Exploratory research driven by signals that do not fit a fixed trigger. Competitive response research. Research-augmented AI assistants where the agent decides when it needs human evidence rather than reasoning from prior context.
Architecture 3: Hybrid
A hybrid workflow combines scheduled research operations with on-demand agent analysis. Your application stores study IDs, handles completion, and supplies relevant reports to the agent when a decision arises.
Agents can search findings and participant responses across authorized studies, then retrieve the underlying reports and interviews. Results preserve study context and source links; the calling agent interprets the evidence. Search coverage is explicit, and retrieving evidence does not launch research.
New research is commissioned when the retrieved evidence is insufficient. The schedule should not silently authorize changes to the audience, plan, or budget.
What you need from a research API
Not every research API supports the full programmatic pattern. Four capabilities are required; a gap at any one breaks the automation chain.
1. Recruitment
The API must source and invite qualified participants without manual work. This requires a panel with meaningful coverage (demographic, behavioral, industry, language) and a targeting API that accepts structured filters. Without programmatic recruitment, every automated study still requires a human to find and contact participants — the bottleneck moves upstream rather than being eliminated.
A production recruitment API accepts segment filters (role, company size, industry, seniority, language, behavioral attributes), creates invitations for all qualifying participants in a single call, and handles incentive distribution programmatically.
2. AI-moderated conversation
The API must conduct a research-grade interview autonomously — not deliver a survey. Survey APIs return what respondents choose; moderated interview APIs return why respondents choose it. The moderator must be capable of probing, following up on unexpected answers, and surfacing the reasoning behind behavior.
A discussion guide configured at study creation defines the research goals; the AI moderator executes the conversation adaptively across all participants, maintaining research rigor without scripted inflexibility.
3. Transcript analysis
The API must return structured findings from completed interviews, not raw transcripts that require a researcher to synthesize manually. Structured analysis — themes, representative quotes, cross-participant comparisons, sentiment — is what makes the output actionable for downstream systems and agents.
4. Cross-study intelligence retrieval
Individual study findings are useful once; cross-study synthesis is useful indefinitely. An API that returns findings per study but provides no way to query across accumulated research leaves each study as an isolated artifact. Cross-study retrieval — natural-language queries that synthesize answers from all completed research in the workspace — turns the research API into a compounding knowledge infrastructure rather than a transaction service.
How does User Intuition handle API-driven customer research?
MCP exposes study planning, recruitment, interviews, results, evidence search, and supporting configuration operations. The CLI provides shell access to research workflows. Use the current tool catalog and API reference for exact names and arguments; tool counts vary by release.
Create a metadata draft with create_study, then send the research brief through customize_study. Relay any planning questions to the user. Retrieve the persisted plan with get_study and obtain approval before recruitment. The user must choose panel or BYOP explicitly.
For a panel study, use launch_panel with dry_run: true to obtain the recruitment estimate. Show the country, language, cost, and timeline; launch with the same settings after approval. Each launch specifies one country. Audiences below 10% incidence require a feasibility request.
Study results expose findings, participant responses, sample profiles, recommendations, and source references in JSON. Use generate_report when analysis is needed, and get_interview to verify supporting messages and recording links. Preference shares, credibility scores, and ranked themes are not guaranteed typed fields in this response.
Agents can search findings and participant responses across authorized studies, then retrieve the underlying reports and interviews. Results preserve study context and source links; the calling agent interprets the evidence. Search coverage is explicit, and retrieving evidence does not launch research.
Use the hosted endpoint, https://mcp.userintuition.ai/mcp, with OAuth in compatible clients. For local stdio, run npx -y @userintuition-ai/mcp with USERINTUITION_API_KEY set to your ui_sk_ key. The CLI supports browser login and API-key management. Hosted OAuth does not require exchanging a user-supplied API key.
Migration path: from dashboard-only to API-driven
- Start with a read. Retrieve an existing study and its report. Confirm the response fields your application needs.
- Add planning. Create a draft and coordinate Customize Plan, retaining the saved plan and its approval.
- Add recruitment. Use a reviewed panel estimate or authorized BYOP list. Track which settings were approved.
- Handle completion. Save study IDs and paginate interview records. Use polling or webhooks with reconciliation.
- Keep evidence visible. Preserve references and distinguish participant statements from your application’s synthesis.
Agents can search findings and participant responses across authorized studies, then retrieve the underlying reports and interviews. Results preserve study context and source links; the calling agent interprets the evidence. Search coverage is explicit, and retrieving evidence does not launch research.