Why agents need product context
AI coding agents have made building software much cheaper. They have not made it easier to know what is worth building. An agent asked to “improve onboarding” will write good code for whatever it guesses the problem is. Without the evidence a product manager uses, it can ship the wrong thing faster.
Product context is that evidence: which customers raised a problem, which accounts and how much revenue sit behind it, what usage shows, and what the team already decided about it and why.
What product context includes
| Context | The question it answers | Where it usually lives |
|---|---|---|
| Customer signals | Who asked for this, in their own words? | Support, calls, Slack, surveys |
| Business context | Which accounts, and what are they worth? | The CRM |
| Product evidence | How many users touch this, and is it breaking? | Analytics, error tracking |
| Decision history | Did we already decide this, and why? | Meetings, docs, people’s memory |
| Delivery | What shipped, and did the problem go away? | The issue tracker, then feedback again |
The hard part is not any single row. It is the links between them: this complaint, from this person, at this account, worth this much, about a problem the team deferred in March for a stated reason.
Why pasting documents into a prompt is not enough
- It is a snapshot. The feedback keeps coming after you paste it.
- It is unlinked. A list of quotes does not say which accounts they came from or what they are worth.
- It has no decisions in it, so the agent cannot tell a new idea from one you rejected last quarter.
- It cannot be checked. The agent’s claims should point back to sources a person can open.
How to give agents product context
- Keep it in one connected store, fed continuously from the tools where feedback, revenue and usage already live.
- Link it by identity: feedback to people, people to accounts, accounts to revenue. See how to prioritize feature requests by revenue.
- Record decisions with their reasons, so the agent sees what was already settled. See how to keep a product decision log.
- Expose it read-only over MCP. The Model Context Protocol is an open standard that lets AI applications call tools and read data from other systems (modelcontextprotocol.io). Read-only access lets an agent query evidence without being able to change it.
- Require citations. Ask the agent to cite the feedback and decisions behind each claim, and to say when something is an assumption.
What to ask an agent once it has context
- “What are the top problems for accounts over $50k, and what did we decide about each?”
- “Before drafting this spec, show me the customer evidence and any past decision on it.”
- “Which deferred items have new requests since we deferred them?”
How purpal does it
purpal is the product context layer for better decisions. It connects customer feedback (Intercom, Slack, Zoom, Google Meet, uploaded files) to the people and accounts behind it, deal value from HubSpot, usage from PostHog, Mixpanel or Google Analytics, and errors from Sentry. It records what your team decided and why. Its read-only MCP server lets MCP-compatible tools such as Claude query themes, evidence, decisions and specs, with access set per token. Inside purpal, every answer in chat is cited to its source.
Questions
Can the agent change anything?
Not through purpal’s MCP server. It is read-only.
Is this the same as giving an agent our codebase?
No. Code context tells an agent how the product is built. Product context tells it who needs what, and why the team decided what it did. Agents need both.
Do we need a PM for this?
Someone has to make and record the decisions. The context makes that faster and makes the reasoning available to everyone, people and agents alike.