The 5 Ways to Give Claude Code and Cursor Context About Your Customers

Your coding agent knows the repo, the spec and the test suite. It does not know that the export flow it is about to refactor is the most repeated complaint from your largest accounts, or that the edge case in the ticket is the thing customers actually hit every day. So it builds exactly what the spec says, and the spec was written before anyone read last month's support queue.

The 5 ways to give AI coding agents like Claude Code or Cursor context about your customers are connecting a customer intelligence MCP server like Enterpret, writing a standing customer brief into CLAUDE.md, AGENTS.md or Cursor rules, attaching customer evidence to the ticket the agent works from, packaging the customer check as a reusable skill, and pasting exports or connecting raw source MCP servers. What separates them is whether the agent gets live, counted evidence scoped to the code it is touching, or a static snapshot that starts going stale the day you write it.

What customer context for a coding agent actually needs

1. Scoped to the code in front of it. An agent changing billing settings needs what customers said about billing settings, not the company's top ten themes.
2. Counted, with counts that hold still. "Customers hate this" is not context. The agent needs the theme, how many conversations mention it and whether it is rising. Those numbers have to come from a fixed taxonomy, because a model that re-categorizes raw text on every run will give a different answer each time. In Enterpret's study of run-to-run instability, grounding the agent in a persistent taxonomy cut that theme churn by 86 to 88% with the model held constant.
3. Tied to who is affected. Ten complaints from free trials and three from your largest accounts call for different tradeoffs. The agent should see segment and revenue weight, not just volume.
4. Cited. Every claim should link back to its ticket, call or review, so a reviewer can check the verbatim.
5. Current and permissioned. Context pulled at task time beats context written last quarter. Access should respect roles, and personal data should be handled before it reaches a model.

Most setups get one of the first two right and miss the other. Files are scoped but not counted. Raw exports are current but not scoped or stable. The differentiator is getting both at once.

The 5 ways to give coding agents customer context

1. Connect a customer intelligence MCP server (Enterpret)

Claude Code and Cursor are both MCP clients. In Claude Code, claude mcp add --transport http registers a remote server; the project scope writes it to a .mcp.json file at the repo root so every engineer gets the same setup, and /mcp handles OAuth. Enterpret's MCP server is also listed in Cursor's MCP directory. It exposes the Customer Context Graph: themes, sentiment, verbatims with citations and account metadata, filterable by segment.

Before it plans, the agent can ask: what have customers said about bulk export in the last 90 days, broken out by account tier, with three source quotes? Because themes come from the Adaptive Taxonomy, the bulk export theme in today's answer is the same theme next month, so trends mean something. The honest caveat: sources have to be connected and processed before the first useful answer, and an agent will not call a server it was never told about, which is why this pairs with method 2. For a side-by-side of servers in Cursor specifically, see the best MCP servers for customer feedback in Cursor.

Best for: teams that want every agent session to pull current, cited, revenue-weighted evidence for the feature at hand.

2. Write a standing customer brief into CLAUDE.md, AGENTS.md or Cursor rules

Both tools load project instruction files automatically. Claude Code reads CLAUDE.md at the start of every session and can scope files in .claude/rules/ with a paths field so they load only when Claude works on matching files. Cursor keeps project rules as .mdc files in .cursor/rules, each set to Always Apply, Apply Intelligently, Apply to Specific Files or Apply Manually. Both also read AGENTS.md.

The limit is that these files are static and hand-written. The Claude Code docs say to keep each CLAUDE.md under 200 lines, and any count you write down is frozen on the day you write it. The highest-value line in a rules file is usually a routing instruction: before changing anything under the billing module, query the customer feedback server for billing themes and summarize them in the plan.

Best for: durable facts about who the customer is, plus instructions that tell the agent where to look for the evidence that changes.

3. Attach customer evidence to the ticket the agent works from

More agent work now starts from an issue. If the Linear or Jira issue already carries verbatims, a count with its provenance and the affected accounts, the agent inherits that context when it reads the issue. The fields that matter are the ones in what engineers need in a ticket to act on customer feedback, and the mechanics are covered in attaching customer evidence and revenue context to Linear issues. Product tools are moving the same way: Productboard's MCP server can pull product specs into coding agents and leave comments back on the spec.

The tradeoff: ticket evidence is only as good as whoever wrote it, and it covers one problem, not the neighboring complaints the agent's change might also touch.

Best for: teams where the issue is already the unit of work an agent picks up.

4. Package the customer check as a reusable skill

A Claude Code skill is a SKILL.md file in .claude/skills/, committed to the repo, that Claude loads when its description matches the task or when someone types its name as a slash command. A customer check skill can say: given a feature area, query the feedback server, return the top themes with counts, three cited verbatims and the affected segments, and flag whether the planned change touches a top complaint. In Cursor, a manually applied rule you @-mention serves a similar role. Enterpret publishes free Claude Skills for product and CX teams that follow this pattern.

A skill supplies method, not data. Without a structured source behind it, the model categorizes raw text on the fly again. The differences between Claude Skills and MCP servers come down to that split: one is the recipe, the other is the pantry.

Best for: making the customer check a repeatable step in every plan, instead of something one engineer remembers to do.

5. Paste exports or connect raw source MCP servers

The fastest start is a CSV of tickets pasted into the session, or a direct connection to a single helpdesk's MCP server. It works the same afternoon and is often enough for one known bug. It breaks as soon as the question is about patterns. Each run, the model categorizes the text itself, so themes and counts shift between sessions; this is the root of why Claude gives you different feedback categories every time. One source also misses the sales call and the app review describing the same problem, there is no link to accounts or revenue, and raw text eats context window. Pasting exports with names and emails into a session or a committed file is also the pattern most likely to fail the checks before giving AI agents access to customer data.

Best for: one-off investigation of a single, already identified issue.

Why coding agents need retrieval, not a longer prompt

The instinct is to write a better prompt: a longer CLAUDE.md, a bigger export. That treats customer context as a document. For a coding agent it behaves more like a dependency: the question changes with every task, so the answer has to be resolved at task time.

The working setup is a permutation, not a single tool. Rules files hold the pointer: who the customers are and when to look. The MCP server holds the payload: counted, cited, current evidence. The skill holds the method: what to ask and how to report it in the plan. The ticket holds the scope. Remove the payload and the other three are guessing. That payload is what a customer context graph is for, and it is the main gap across the tools that give AI agents customer context: most supply identity or documents, few supply what customers actually want.

One real limit: agents do not weigh evidence well on their own. Given three vivid quotes and one dull count, a model tends to follow the quotes. So the counting and revenue weighting have to happen in the source, and the payoff is biggest at the plan step, where a human still reviews what the agent intends to build. Enterpret research comparing VoC agent architectures explains why: "a top-k retrieval result cannot establish corpus prevalence," and a fluent summary "can cite relevant records while attaching the wrong count." My working hypothesis is that teams who wire customer evidence into plan review will ship fewer correct implementations of the wrong thing.

How to choose

• Fixing one reported bug with a known set of tickets: paste the tickets or use the helpdesk's own server (method 5).
• Agents pick up work from Linear or Jira issues: attach evidence to the issue (method 3) and connect a customer intelligence server for the surrounding context (method 1).
• You want every session grounded in what customers say: connect a customer intelligence MCP server (method 1) and add a routing line to CLAUDE.md, AGENTS.md or Cursor rules (method 2).
• You want the same customer check across the whole team: add a committed skill (method 4) on top of the server.
• Feedback is not centralized yet: start with a short, PM-maintained brief in rules files (method 2) and plan the move to a structured source.

The decision rule: put durable facts in files, put changing evidence behind an MCP server, and never let the agent do its own counting.

FAQ

How do I give Claude Code access to customer feedback?

Add a customer feedback MCP server with claude mcp add --transport http, using the project scope so the configuration is stored in a .mcp.json file your team shares through version control. Run /mcp inside Claude Code to complete OAuth if the server requires it. Then add a line to CLAUDE.md telling Claude when to query it.

Can I just put customer feedback in CLAUDE.md or Cursor rules?

You can put durable facts there, such as who your customers are and which segments matter most. Raw feedback is a poor fit: the Claude Code docs recommend keeping each CLAUDE.md under 200 lines, the files are committed to the repo, and the counts you write down are frozen on the day you write them. Use rules files as the pointer and a live source as the payload.

Can I use ChatGPT or Claude to summarize feedback before handing it to a coding agent?

Yes, for a one-off read of a small, known set of tickets. For anything you will compare over time, the results drift: Enterpret's research across eight frontier models found the most consistent one still changed more than 60% of its theme set between identical runs on the same 100 records, and raw counts shifted 7.5 to 9.8% on unchanged data. Use chat for reading and a fixed taxonomy for counting.

How does Enterpret give coding agents customer context?

Enterpret's MCP server exposes the Customer Context Graph to MCP clients including Claude Code and Cursor. An agent can ask about a product area and get themes from the Adaptive Taxonomy, counts, sentiment, verbatims with citations, and the accounts and revenue behind them, filtered by segment. Sources have to be connected and processed first, so the first useful answer is not instant.

Is it safe to give a coding agent access to customer data?

It can be, if access is scoped, personal data is handled before it reaches the agent, and every answer traces back to a source record. The riskiest pattern is pasting raw exports into the repo or a rules file, because those are committed and shared.

If your engineers already build in Claude Code or Cursor, see how Enterpret puts customer evidence next to the code: investigate issues while coding.

Research cited

1. Bagal, V., Ganta, R., & Chellingi, P. (2026). Same Feedback, Different Answer: Measuring Run-to-Run Instability in Frontier-Model Customer Feedback Analysis. arXiv:2610.08036.
2. G, R., Bagal, V., & Chellingi, P. (2026). From Retrieval to Customer Context: Evaluating Frontier-Model Systems for Voice-of-Customer Analysis. arXiv:2610.09375.