How to give AI agents customer context
Ask a coding agent "what do customers say about our export feature" and you get a confident essay assembled from your code comments and its training data. The agent isn't being lazy. It answers from what it can see, and what it can see is the repo. The customer half of the picture lives in Slack threads, Discord channels, support tickets, and sales calls it has no way to reach.
We build Modem, which exists to close exactly this gap, so weigh our take accordingly. The mechanics below apply whether or not you use us.
Why agents answer generically
An agent grounds its answers in retrievable context. Code is retrievable, so questions about code get sharp answers. Customer signal fails retrievability three ways. It's scattered across tools with separate auth. It's duplicated, so naive retrieval overweights whichever channel is noisiest. And it's unresolved, meaning nothing links the person complaining in Discord to the account they represent in your CRM. Feeding an agent raw access to all four channels doesn't fix this. It hands the agent the same re-reading job that burns a context window before the work starts.
The three sources that matter
Feedback channels. Slack, Discord, support tickets, sales-call transcripts, GitHub issues. This is what customers actually said, and it's the layer agents most need and least have. The raw material needs deduping and topic-merging before it's useful.
Account data. Plan, spend, renewal state, from your billing system or CRM. This is what turns "someone wants SSO" into "three enterprise accounts up for renewal want SSO." Modem pulls this through the Stripe and Salesforce integrations; the Salesforce sync is read-only by design.
Product state. What shipped, what's in flight, what broke. Issue trackers and error monitoring (Linear, Sentry) close the loop between what customers report and what the team is doing about it.
You don't need all three on day one. Feedback channels first. The other two multiply the value of what's already connected.
Push vs pull
Push means assembling context into the prompt ahead of time. A person pastes the thread, or a script injects a summary file. It works for one-off tasks, and it's the right shape when a human is curating a specific brief. It goes stale the moment it's written, and someone has to do the assembling every time.
Pull means the agent queries for what the task needs, when it needs it. This is what MCP is for. The agent holds a connection to a server, sees its tools, and calls them mid-task. Context arrives current, sized to the question asked, and nobody assembled anything by hand.
Pull is the durable answer, with one caveat. The agent has to know the server is worth querying. A line in your repo's agent instructions ("query Modem for customer feedback before answering questions about what users want") converts the capability into behavior.
A worked Claude Code example
Wiring Modem into Claude Code is one command:
claude mcp add --transport http modem https://mcp.modem.dev/mcpAuth is OAuth on first use. There's no API key to embed. Then, in a session:
You: Customers keep complaining about export timeouts. Find out who's affected and propose a fix.
Without the connection, the agent greps the codebase for export and timeout and reasons from there. With it, the agent queries the context graph first and gets back the merged topic. Twelve reports across Discord and Zendesk, the affected accounts and their plans, and the original quotes, including the one specifying the 25k-row threshold that turns out to be the repro. The fix it proposes starts from the actual failure mode instead of a plausible one.
For scripted pipelines the same access is available through the @modem-dev/cli npm package (the binary is modem).
What changes when they have it
Three shifts show up in practice. Answers to "what do customers want" become citable, with names and quotes, which changes how much the team trusts agent output. Task briefs improve, because a delegated fix arrives carrying the customer evidence instead of a bare ticket title. And prioritization arguments get shorter, since "who else hit this and what do they pay us" becomes a query rather than a research project.
The boundary worth stating plainly. An agent with customer context still can't decide what to build. It can tell you twelve people asked and which accounts they're at. Whether that outweighs the platform migration on the roadmap is a judgment call, and it stays one.
