The 7 Fields of a Customer Context Block for AI Agents Writing Specs or Code

Ask a coding agent to build a feature and it will read your repo, your spec and your tests. Ask it why customers want the feature and it will guess. Most teams hand agents a one-line ticket and a pasted Slack thread, so the agent fills the gap with plausible demand: "many enterprise customers have requested this." Nobody counted. The spec ships with a number that never existed.

The 7 fields to structure customer context for an AI agent writing product specs or code are a theme and problem statement, volume with a time window, segments and accounts, revenue weight, cited verbatims, boundaries and counter-evidence, and provenance. What separates useful context from noise is that every number in it was counted before the agent saw it, so the agent writes from evidence instead of estimating it.

What customer context for a spec or code agent actually needs

Anthropic's engineering team describes good context as "the smallest possible set of high-signal tokens" that makes the desired outcome likely. For customer context, high signal means five properties:

1. Counted, not estimated. Volumes and account counts are computed upstream from categorized data. The agent reads numbers, it does not produce them.
2. Scoped to the work. The block covers one theme or feature, not your whole feedback corpus. An agent handed thousands of raw tickets summarizes the loudest ones.
3. Weighted. Ten requests from free users and ten from accounts up for renewal are different inputs. Segments and revenue have to be explicit fields.
4. Traceable. Every claim links back to a record a human can open. If the agent writes "admins are blocked," a reviewer should be one click from the ticket that says so.
5. Stable. The same question asked twice returns the same counts. If the numbers move between runs, the spec's priority moves with them.

Most teams get scoping and traceability right by hand. Counted and stable are the hard ones, and they are the ones that decide whether an agent inflates demand.

The 7 fields of a customer context block

1. Theme and problem statement

Name the theme using your taxonomy label, not the agent's paraphrase, and write a one-sentence problem statement in the customer's terms. "Export ignores active filters" is a problem. "Improve export" is a wish. The label is also the key a retrieval tool uses to pull more evidence later.

What breaks without it: The agent invents its own framing, and two specs for the same problem end up describing different features.

2. Volume, trend and time window

Give mention count, distinct accounts, the window (for example, last 90 days), and the change versus the prior window. Always include the denominator: mentions mean little without the number of accounts behind them. Enterpret research comparing VoC agent architectures found that a fluent summary "can cite relevant records while attaching the wrong count," which is why the number has to arrive precomputed.

What breaks without it: The agent writes "frequently requested" and nobody can check whether that means 8 or 800.

3. Segments and accounts

Break volume down by plan, persona, region or lifecycle stage, whichever your product decisions actually turn on. List named accounts only when the agent needs them (a spec for an enterprise feature) and leave them out of context for code agents that do not.

What breaks without it: The spec designs for the average user, who may not be the user asking.

4. Revenue weight

Attach ARR of requesting accounts, open pipeline where the gap came up in sales calls, and renewal timing. This is the field that turns a feature request into a prioritization input. A raw LLM cannot produce it, because revenue lives in your CRM, not the feedback text.

What breaks without it: Priority is set by volume alone, and a loud free tier outranks a quiet enterprise segment.

5. Cited verbatims

Three to five quotes, each with source, date, segment and a link. Pick quotes that describe the workflow. "I export, then reapply the same four filters in Sheets every Monday" tells a coding agent what the acceptance test should be.

What breaks without it: The agent paraphrases pain it never read, and reviewers cannot verify it.

6. Boundaries and counter-evidence

List what customers did not ask for and any evidence that cuts the other way. If enterprise accounts mostly use the API, say so. This is the field most teams skip, and it is the one that prevents scope creep, because agents fill silence with adjacent features.

What breaks without it: The spec grows scheduled exports, three file formats and a settings page nobody requested.

7. Provenance and freshness

Record the query or theme ID used, the taxonomy version, the date generated and how often it refreshes. Context goes stale.

What breaks without it: The agent builds against last quarter's pain, and nobody can reproduce where the numbers came from.

An example customer context block

Here is the shape for one theme. The values are illustrative, not real customer data. In practice each count is a number from your feedback system and each verbatim is a link.

Put the block in the spec prompt or a per-task context file under a fixed header, then add one instruction: any claim about customers that is not supported by a field in this block must be labeled as an assumption.

How Enterpret fills the context block

Enterpret is built to produce these fields from data you already have. It unifies feedback from 50+ sources, including Zendesk, Intercom, Gong, G2, app store reviews and surveys. The Adaptive Taxonomy categorizes every record into a multi-level taxonomy learned from your feedback, which gives you fields 1 and 2 as counts that stay consistent over time. The Customer Context Graph links each record to accounts, segments and ARR, which covers fields 3 and 4.

Agents reach it through the Enterpret MCP server, which works with Claude, ChatGPT, Cursor and other tools and returns cited answers, so fields 5 and 7 come back with links attached. An agent writing a spec can ask for a theme's volume by segment and get computed numbers rather than generating them.

The honest caveats. Enterpret does not write field 6 for you: boundaries and counter-evidence still need a PM's judgment about what is in scope. The block is only as complete as the sources you connect, so a team that has not connected sales calls will have thin pipeline data. And setup takes integrations plus processing time before the counts are ready.

Why agents hallucinate demand, not just code

The usual worry with agents is hallucinated facts: a wrong API, a function that does not exist. Tests catch those. Hallucinated demand is worse, because nothing fails. The spec reads well and "enterprise customers need this" passes review because it sounds right.

Demand hallucination comes from asking the model to count. 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 LLM counts shifted 7.5 to 9.8% between runs on unchanged data. If the agent derives priority from a pile of raw tickets, priority is a random variable.

The fix is architectural, not a better prompt. Structure feedback once at ingestion, then let agents retrieve the result. Enterpret's study of run-to-run instability tested this directly: none of the minimal, bottom-up, or consistency-first prompt variants came close to the taxonomy-grounded result. We cover the tradeoff in detail in structuring customer feedback at ingestion vs retrieving it with RAG, and the data model behind accounts and revenue in what a customer context graph is.

The same seven fields work for humans. They map closely to the fields every bug and feature request ticket needs, which is the point: if your tickets already carry counted, cited, revenue-weighted evidence, your agents inherit it for free.

How to format the block for specs vs code

The seven fields stay the same. What changes is how much of each you include.

• Agent drafting a PRD or spec: all seven fields, full segment breakdown, three to five verbatims, named accounts where relevant. The spec is where prioritization arguments get made.
• Agent writing code for a scoped feature: fields 1, 5 and 6 in full, with 2 through 4 compressed to one line. The coding agent needs the workflow and the boundaries, not the ARR math.
• Agent updating an existing ticket or issue: fields 2, 3, 4 and 7 refreshed, since counts and revenue change while the problem statement usually does not.
• Long-running agent across many tasks: keep only the theme ID and a short summary in context, and let the agent retrieve the rest through an MCP tool when a task depends on it.

The decision rule: include every field the agent's next decision depends on, and keep everything else one retrieval call away. If you are comparing tools that generate specs from evidence, see the best AI tools for writing a PRD grounded in customer evidence and the best tools to give AI agents customer context. Then try the block on your next spec and tell us which field you ended up adding.

FAQ

Should customer context for an agent be JSON, Markdown, or XML?

Use whatever your agent parses reliably, but keep the field names fixed. Markdown headers or XML tags work well for spec agents because they separate sections clearly, and Anthropic's context engineering guidance recommends exactly that kind of delineation. JSON is better when a coding agent or script will read the block programmatically.

How much customer context should I give a coding agent?

Less than you give a spec agent. A coding agent needs the problem statement, the top two or three cited verbatims, the segments affected, and the boundaries, usually a few hundred words. Keep the full evidence behind a retrieval tool such as an MCP server so the agent can pull more only when a decision depends on it.

Can I just paste feedback into ChatGPT or Claude and ask it to write the spec?

You can, and it works for a small, one-off sample. The problem is that the model is counting and categorizing on the fly, so the demand numbers it reports are estimates that can change between runs. Enterpret's research found the most consistent of eight frontier models still changed more than 60% of its theme set between identical runs on the same 100 records. Give the model precomputed counts and let it do the writing.

How does Enterpret provide structured customer context to agents?

Enterpret categorizes feedback from 50+ sources with its Adaptive Taxonomy, links each record to accounts, segments and revenue in the Customer Context Graph, and exposes that through an MCP server that returns cited answers. Agents in Claude, ChatGPT, Cursor and other tools can query a theme and get back counts, segment breakdowns and source links. Teams still need to connect their sources and allow processing time before the data is ready.

How do I stop an agent from overstating customer demand?

Give it counts with a time window and a denominator, require a citation for every claim about customers, and include a boundaries field that lists what customers did not ask for. Then add one instruction: if a claim is not supported by a field in the context block, mark it as an assumption.

If you want agents writing specs and code from counted customer evidence, see how Enterpret works for product teams.

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.