An AI agent can help run customer research. It should not be allowed to decide that its own output is evidence, contact people without a deliberate review point, or turn a synthesis into a product decision on its own.
The useful division of labour is simpler:
| Role | What it should own |
|---|---|
| The agent | Carry the product context, propose a study, coordinate approved steps, check progress, and return findings to the conversation where the question began |
| The research system | Enforce identity, permissions, project state, research methods, participant access, quota, and the authoritative record |
| People | Set the purpose, review the study, choose and contact participants, establish consent, interpret the evidence, and make the decision |
That is the design principle behind Maren MCP: the agent orchestrates the customer-research workflow; Maren runs and records the research; the customer controls access, outreach, and judgment.
The dangerous version of AI agent customer research
There is an appealing version of agentic research that compresses the whole practice into one instruction:
Find out why trial users fail to activate and fix the roadmap.
An unconstrained agent could turn that into a chain of guesses. It might choose a method without checking the decision, recruit whoever is easiest to reach, send messages under unclear authority, treat a handful of responses as representative, summarise away contradictions, and convert the result into an action.
The workflow would be fast. It would also be difficult to inspect, interrupt, or challenge. The same system would frame the question, collect the material, interpret it, and judge whether its conclusion was good enough. At that point, “research” risks becoming an elaborate way for the model to confirm its first idea.
Customer research needs separation between purpose, collection, evidence, interpretation, and decision. An agent can reduce the administrative work between those stages. It should not erase the boundaries between them.
What MCP changes
The Model Context Protocol gives AI clients a standard way to discover and invoke tools exposed by another product. A tool can describe its purpose, required input, expected output, and behaviour. The protocol also supports structured results that clients can validate instead of forcing the model to infer state from prose.
That makes MCP a useful interface for research operations. Without a connection, an agent can draft a discussion guide, but someone still has to recreate the study in a research product, add participants, monitor fieldwork, run analysis, and carry the findings back into the original product discussion. Every handoff creates an opportunity to lose context or assume that an unfinished step succeeded.
With Maren connected, the agent can work from the context that created the research need. If a planning conversation reveals uncertainty about activation, it can inspect the available methods and workspace capacity, prepare a project for review, and later retrieve the completed synthesis. It does not need broad database access or a second copy of Maren’s business logic.
Ten narrow tools make the workflow legible
Maren MCP exposes ten focused tools rather than one broad “do research” operation. They cover five stages:
| Stage | What the agent can do | Boundary Maren enforces |
|---|---|---|
| Orient | Inspect the connected workspace, capacity, interview styles, and existing projects | The workspace comes from the approved connection, not a tool argument |
| Design | Create a draft with an objective, style, depth, language, tone, and discussion guide | Project input is validated and the result remains a draft |
| Prepare | Add participants, activate the approved project, and retrieve matching interview links | Adding participants sends no email; links are treated as credentials |
| Monitor | Read participant states, completions, synthesis readiness, and the next useful action | Maren returns current state instead of trusting the agent’s memory |
| Learn | Start synthesis after at least three interviews are eligible and retrieve the report | Quota, single-flight execution, refresh confirmation, and output boundaries still apply |
The sequence matters. A project is a draft before it is active. A participant can be prepared without being contacted. A participant link belongs to one person. Synthesis is unavailable before the minimum evidence threshold. Refreshing a completed synthesis is not treated as an invisible retry because it uses another synthesis allowance.
These are product rules, not suggestions hidden in a prompt. Maren applies them even when the agent loses context, repeats a request, or attempts a step too early.
The system of record should remain authoritative
Agents are probabilistic. Workspace membership, project state, quota, and participant credentials are not.
Maren does not ask the agent to remember those facts. It exposes tools that inspect them at the point of use:
- before proposing a study, the agent can check the current workspace and available capacity;
- before creating a project, it can retrieve the registered interview styles and supported depths;
- before returning participant links, it can see whether the project is active;
- before synthesis, it can check how many interviews are eligible; and
- after a write, it receives Maren’s result rather than declaring success itself.
The agent may carry a project identifier between calls, but the identifier is only a name. Maren still validates access every time. This follows the current MCP tools guidance for stateful services: a server should validate the caller’s authorization against a handle on each call, rather than treating possession of the identifier as permission.
Every write also uses Maren’s shared research-operation services. The dashboard and MCP route do not maintain competing versions of project creation, participant handling, or synthesis. The agent coordinates the workflow, but Maren remains the authority on whether an operation happened and what state exists now.
Identity should come from the approved connection
A poorly designed multi-tenant tool might accept workspaceId or userId as ordinary input. That makes identity look like data the agent can choose.
Maren MCP derives the user, OAuth client, workspace, role, and permissions from the approved connection. When a customer connects an agent, they select one workspace and review the requested access. Maren resolves that authorization again on each request. A resource from another workspace returns as not found instead of revealing that it exists.
This design is consistent with the current MCP authorization specification, which binds access tokens to their intended resource and recommends requesting only the scopes needed for an operation. The broader OAuth security best current practice likewise recommends restricting token privileges to the required resources and actions.
For the customer, the mental model stays concrete: this agent has these permissions in this workspace. It is not connected to every workspace, and tool input cannot expand the grant.
Separate preparation from contacting people
Research crosses an important line when another person is contacted.
An agent with permission can add participant email addresses to a Maren project. That action sends no invitation, reminder, or thank-you email. Projects created through MCP have those email controls disabled. Retrieving the unique interview URLs requires a separate permission, and each returned URL is labelled as a credential for its matching participant.
The separation creates a clear review point. A customer can inspect the objective, guide, participant list, and project settings before distributing anything.
It also avoids pretending that outreach is routine plumbing. A team still needs to decide:
- whether the person is appropriate for the study;
- who should contact them and from which channel;
- what the invitation should disclose;
- what consent, privacy, legal, or contractual requirements apply; and
- whether the participant has enough context to make an informed choice.
The agent can prepare the work. It does not quietly become the sender.
Make cost boundaries explicit
An agent should be able to prepare useful work without receiving an ambiguous spending mandate.
Creating a project, adding participants, and activating a project do not themselves consume an interview from the workspace allowance. Activation can still identify a risk: if the known participant list could move the workspace into paid overage, Maren returns the current capacity and price information and requires explicit overage permission before activation succeeds.
The same principle applies to synthesis. Starting the first eligible synthesis reserves synthesis capacity. If a completed synthesis already exists, a fresh run is not disguised as a harmless retry. Maren asks for explicit confirmation because refreshing the result uses another allowance.
This is a better boundary than asking the model to infer approval from conversational tone. The agent can explain the cost and ask for a decision. The server enforces the decision at the operation that matters.
Treat customer evidence as data, never instructions
Participant content comes from outside the product team. It can contain copied code, markup, links, accidental secrets, or text that looks exactly like an instruction to an AI model.
That content is research data. It should not be allowed to redefine the agent’s role, reveal unrelated information, or trigger another tool.
This is not a theoretical formatting concern. OWASP’s prompt-injection guidance describes the underlying problem: models often process natural-language instructions and data in the same context, and indirect injection can arrive through retrieved documents, tool output, web pages, or other external material.
The first Maren MCP surface does not return raw interview transcripts. It returns completed cross-interview synthesis. Maren wraps the synthesis in newly generated boundary markers, labels it as untrusted research data, and instructs the agent not to follow anything inside those markers as an instruction.
That control does not make a model infallible. No honest product should claim that a label eliminates prompt injection. The boundary does make the intended interpretation explicit and testable: participant-derived content may inform a decision, but it cannot grant itself authority.
The same discipline helps research quality. A participant’s sentence is evidence of what that person reported in context. It is not automatically a fact about the whole market, a validated causal explanation, or an instruction to build a feature. Keep findings linked to their support and contradictions; the guides to synthesising user interviews and building a small-team research repository show how.
Give every operation a recovery trail
Agent workflows fail differently from button clicks. A client can time out after a write succeeded. A model can repeat a call. Two requests can race. A long-running synthesis can still be processing when the next check arrives.
Maren handles mutating MCP calls with idempotency keys, applies tool-level rate limits, and returns structured error codes. Valid operations that reach execution receive an audit reference that support can use to trace the request. A repeated operation with the same idempotency key and input can resolve to the original result rather than creating another project or duplicate participants.
These controls are easy to omit from a demo because they do not make the happy path more exciting. They are what make the unhappy path recoverable.
The current MCP tools specification makes similar operational recommendations: validate inputs, implement access controls, rate-limit calls, prompt for confirmation on sensitive operations, and log tool usage for audit. A useful agent integration is a production interface, not a chat-shaped shortcut around production rules.
Human oversight needs a defined job
“A human is in the loop” is not enough if nobody knows which loop or what the person is expected to review.
For customer research, useful review points include:
- Before project creation: confirm the decision, research question, participant criteria, and method.
- Before activation: inspect the objective, participant-facing topic, discussion guide, depth, language, and tone.
- Before outreach: verify the participant list, invitation, sender, consent information, and distribution channel.
- Before paid overage or refreshed synthesis: approve the specific cost-bearing operation.
- Before acting on findings: review evidence, counterevidence, sample limits, product data, and unresolved uncertainty.
The MCP specification recommends that people be able to deny tool invocations, and the NIST AI Risk Management Framework calls for documented roles and responsibilities in human-AI configurations. In research, those principles become practical only when the product exposes real stopping points.
What the agent gains
For the agent, Maren MCP provides a legible route from uncertainty to evidence.
It can notice that a product discussion contains an unanswered customer question. It can compare registered interview styles, prepare a study, check current state rather than assuming a prior step completed, and return synthesis to the exact conversation where the decision is being made.
Most importantly, the agent has somewhere to go when evidence is obtainable. It does not need to fill every gap with a plausible answer.
What the customer keeps
For the customer, the benefit is continuity with control:
- the product question does not need to be reconstructed in another interface;
- repetitive setup and status checks can be delegated;
- the research method and workspace rules remain consistent;
- participant contact stays deliberate;
- sensitive links require explicit access;
- usage boundaries remain enforceable;
- findings return to the decision context; and
- people remain accountable for what the evidence means and what happens next.
That is a more useful promise than “full autonomy”. Clear edges make the agent more dependable because they tell it what it can know, what it can do, when it must stop, and which system is authoritative.
What Maren MCP does not do
Maren MCP does not turn an agent into an autonomous research department. It does not:
- choose the business decision the study should support;
- decide that a sample is representative;
- recruit an external panel;
- determine whether consent or outreach is lawful and appropriate;
- send participant invitations through the MCP workflow;
- expose raw interview transcripts through its first tool surface;
- convert qualitative findings into market prevalence; or
- make the product decision after synthesis.
It also does not replace Maren’s participant experience. The adaptive interview still happens in Maren using the selected method. Cross-interview analysis still happens in Maren. MCP makes those capabilities available within an approved agent workflow.
The responsible shape of a research agent
Agents are becoming a normal place for planning, analysis, writing, and coordination. Customer evidence needs a route into that work. Otherwise, the fastest available answer will keep beating the better answer that requires a conversation with a customer.
Bringing research into the agent does not require collapsing the whole practice into the model.
Let the agent carry context and coordinate approved steps. Let Maren enforce the research workflow and preserve the authoritative state. Keep access, outreach, consent, interpretation, and decisions with people who can be held accountable for them.
Explore Maren MCP to see the ten tools, permission model, customer safeguards, and connection flow. In Maren, you can connect a supported agent from Settings → AI agents.