An agent that knows everything is usually not useful.
Useful agents know the right material for the job, and they know what material is out of scope.
That is the job of Collections.
Collections let a builder or team give an agent bounded knowledge:
- product docs
- policy material
- support records
- research notes
- implementation guidance
- customer-specific context
The boundary matters as much as the content. When the agent answers, the team needs to know what sources it used, whether the answer is reviewable, and how the knowledge can change over time.
Selecting documents is one part of that work. During SME gathering or import, agree terminology and an initial ontology: the concepts, relationships, and distinctions the application must understand. Retain the sources, owners, and applicable versions behind that meaning so intents and later answers can be reviewed against it.
Keep reusable application knowledge distinct from an organization’s policies and a project’s current evidence or decisions. Each may have its own vocabulary, integration mappings, and access rules. Collection assignment does not replace those access checks, and current business records still belong to their source systems.
When use produces a new finding, retain its context and review it before promoting it into shared knowledge. A case-specific conclusion should not silently become a rule for every customer.
For builders, this keeps the same knowledge boundary available across Direct Agents, Smart Agents, and Agent Applications.
The knowledge application build method connects this preparation to intents, integrations, and a useful experience.
Build a knowledge agent
