Quick answerSet context depth by the specific task the agent is performing in that conversation, not by giving it standing access to the full customer record by default. A billing question needs billing history; it does not need medical notes from a healthcare-adjacent purchase, prior support complaints about an unrelated product line, or a full year of browsing behavior. This is a design tradeoff about how much a single compromised session, prompt injection, or misrouted response can expose, separate from the compliance question of what you are legally allowed to store or process at all. Compliance sets the outer boundary; this decision sets how much of that legally-available data any one conversation can actually touch.
Blast radius is a property of the conversation, not just the database
A privacy incident caused by an overly broad database is bad, but a privacy incident caused by an agent that had the full record loaded into one conversation and then leaked or misused part of it, through a prompt injection, a misrouted screenshare, or simply an answer that surfaces information the customer did not ask about, is a different and often worse failure. The database being compliant does not make any single conversation's exposure safe. Design the agent's per-conversation context as its own attack surface, scoped down to what that conversation's task actually requires, the same way you would scope an API key rather than handing every integration full account access.
Quality gains from more context follow a curve, not a straight line
Teams often assume that more history always means better answers, but the marginal quality gain from adding, say, eighteen months of history instead of six is usually small once the agent already has enough to understand the customer's current situation. Map out, task by task, where that curve flattens, and set the default context window at the point past which more data stops meaningfully improving the answer. This is worth doing explicitly rather than defaulting to whatever the platform makes easiest to wire up, since the easiest technical default is almost always the full record, not the scoped one. The privacy compliance obligations that apply to whatever you do keep in scope are a separate layer on top of this; see data privacy and PII when an AI agent has customer records for that side.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Make context depth an explicit, reviewable setting, not an emergent one
Whatever scope you land on should be a documented, per-use-case setting that shows up in a review, not something that emerged from whichever engineer wired up the integration first. Revisit it whenever a new use case is added to the agent, since a scope that was appropriate for billing support can quietly become too broad once the same agent is repurposed for a higher-stakes use case like account changes or dispute handling. This is closely related to, but distinct from, the readiness question covered in what data you need ready before onboarding an AI agent, which is about data quality and structure; this decision is specifically about how much of that prepared data should be visible in any single conversation.
FAQ
Does giving the agent less context reduce its accuracy on complex issues? It can, for genuinely cross-cutting issues, which is exactly why this should be a deliberate, task-based setting rather than a blanket minimum. The goal is not to starve the agent of context; it is to stop handing over more than the task in front of it needs.
Should a human agent have the same context restrictions as the AI agent? Not necessarily the same restrictions, but the same principle. Humans have judgment and accountability an AI agent's session does not, which is part of why a broader default has historically been more tolerable for human reps than it is for an automated system with a much larger effective attack surface.
How does this interact with multi-tenant data isolation? They solve different layers of the same risk. Multi-tenant isolation stops one customer's agent session from ever touching another customer's data; context-depth scoping limits how much of one customer's own data is exposed within their own session. See multi-tenant AI agent data isolation for the cross-tenant side.