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:
[Product analytics: NPS drops below threshold]
→ Orchestrator triggers: create_assistant(study_type="churn_reason", ...)
→ bulk_create_invites_from_segment(segment_filters={nps_detractor: true}, ...)
→ [AI moderator runs interviews]
→ analyze_transcripts(call_ids=[...])
→ query_intelligence("What patterns appear in low-NPS customer explanations?")
→ [Findings land in Slack channel / Intelligence Hub / report]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:
[Agent monitoring competitive intelligence signals]
→ Agent: "A competitor just announced a new pricing tier — I need to know how our positioning lands with current prospects."
→ Agent calls: create_assistant(discussion_guide=[positioning_questions], ...)
→ Agent calls: bulk_create_invites_from_segment(segment_filters={prospect_stage: "evaluation"}, ...)
→ [AI moderator runs interviews]
→ Agent calls: analyze_transcripts(...)
→ Agent synthesizes findings into a positioning recommendation
→ Agent surfaces recommendation with evidenceThe 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
The most common production pattern combines scheduled programmatic studies with on-demand agent queries against the accumulated Intelligence Hub.
Scheduled studies run automatically (post-launch, periodic churn interviews, monthly segment checks) and populate the Intelligence Hub. AI agents and researchers query the Hub for synthesized answers drawn from accumulated research. New studies are commissioned on demand when the Hub does not have a current answer.
[Scheduled pipeline]
→ Post-launch study every sprint cycle → Intelligence Hub
→ Monthly churn cohort interviews → Intelligence Hub
→ Quarterly competitive positioning studies → Intelligence Hub
[On-demand agent query]
→ query_intelligence("What objections appear most in enterprise pricing conversations?")
→ Returns: synthesized findings from 12 completed studies, 340 interviews
[On-demand new study when Hub has no current answer]
→ Agent determines Hub lacks signal on a new question
→ Commissions study → analyze_transcripts → Hub updatedThe Hub compounds: each study added increases the quality of answers to every subsequent cross-study query. A workspace with 50 completed studies answers broad synthesis questions with far higher confidence than one with 5.
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?
User Intuition is built API-first. The MCP server is the primary integration surface, not a secondary developer feature — the 72 tools cover the entire research workflow as first-class API operations, with nothing reserved for dashboard-only access.
All four required capabilities are available programmatically. Recruitment runs through bulk_create_invites_from_segment, which draws on a 4M+ panel across B2B and B2C segments in 50+ languages with structured targeting filters. AI-moderated interviews run in audio, chat, or video mode — list_available_modes surfaces the options; create_assistant configures the discussion guide and modality. Transcript analysis runs through analyze_transcripts, which returns structured themes and representative quotes across all interviews in a study. Cross-study intelligence retrieval runs through query_intelligence in the Intelligence Hub — 18 tools total for knowledge retrieval, session management, and output generation.
The API is available via two transports. The stdio transport runs locally via npx -y @userintuition-ai/mcp for development and IDE integrations. The Streamable HTTP transport connects to https://mcp.userintuition.ai/mcp via OAuth for production agent deployments and cloud pipelines. A REST API is also available for teams that prefer direct HTTP integration outside the MCP protocol.
Authentication is a single ui_sk_ key — no scopes, no per-resource tokens, no webhook registration. The key covers all 72 tools. Three free interviews are included on signup with no card required; the full API surface is available from day one. Full documentation at /platform/agentic-research/.
Migration path: from dashboard-only to API-driven
Moving from dashboard-only to API-driven research does not require replacing the dashboard on day one. The migration naturally follows the research use cases where programmatic control delivers the most value.
Step 1: Intelligence Hub queries first. If the workspace has completed studies, the lowest-friction entry is query_intelligence. Researchers start asking cross-study synthesis questions via an MCP-connected AI client rather than manually reviewing past reports. No new studies are required; the value is immediate on existing data.
Step 2: Automate one recurring study type. The first programmatic study is typically one that already runs on a predictable cadence — post-launch studies, monthly churn cohort interviews, quarterly NPS follow-ups. Encoding that as an orchestrator-led pipeline removes the recurring manual setup. The study still runs; the researcher no longer needs to initiate it.
Step 3: Connect to the pipelines that should trigger research. Once the basic pattern is established, the research API connects to the systems that capture trigger conditions — analytics platforms, CRM events, product experiment frameworks. Research becomes reactive to software signals rather than dependent on a researcher noticing the signal and remembering to commission a study.
Step 4: Agent-led research for exploratory questions. The final phase is giving AI agents the authority to decide when to commission research. This requires confidence in the end-to-end workflow and in the agent’s judgment about when human evidence is necessary. Start with well-scoped agent mandates (competitive monitoring, user feedback analysis) before expanding to broader decision-support research.
The migration is incremental; each step delivers independent value and prepares the infrastructure for the next.
Start with the Intelligence Hub or the Human Signal pattern — both are accessible via npx -y @userintuition-ai/mcp and a ui_sk_ key. Full documentation and API reference at docs.userintuition.ai/mcp-server/overview.