Partition Memory by Domain, Session, and Agent Role

A single unrestricted knowledge graph is not automatically the best design. It can create excessive retrieval scope, expose information to agents that do not need it, and make it harder to determine which source should be used for a particular task. Memory should be partitioned according to domain and responsibility.

Memory layers can separate areas such as subscription state, billing and finance, support tickets, and contracts. These layers may be isolated softly or more strictly, depending on the deployment. A note set can group the documents that belong together and make that group available only within the appropriate session or agent context.

This design serves two purposes. The first is relevance. A billing agent does not need every support conversation, every product document, and every unrelated record in the organization. Giving it a smaller, domain-specific memory space reduces the chance that irrelevant information will distract retrieval.

The second purpose is access control. An agent deployed in production should not automatically receive read and write access to all organizational data. A billing agent can be limited to invoices, payments, account status, plans, and seats. A support agent can be limited to customer-reported issues and support history. A supervisor agent can receive broader access because its job is to combine findings from the specialized agents.

The same principle applies to session memory. Each agent can have an independent session where it stores working information. That session should not be confused with the permanent organizational memory. The agent can reason within its own session and promote only the necessary conclusions into persistent memory.

Partitioning also supports domain-specific semantics. The meaning of an entity or field depends on where it is used. Contract terms describe what should be true. Billing records describe what was charged or paid. Workspace entitlement data describes what access is currently active. These are related, but they are not interchangeable. Keeping them in identifiable domains makes it possible for a supervisor to compare the intended state, financial state, and operational state without collapsing them into one undifferentiated pool.

A practical role design can be expressed as follows:

• The billing agent investigates transaction status, invoices, reconciliation, plans, and seats.
• The support agent investigates what the customer reported, where the problem appears, and how urgent or visible it is.
• The workspace or entitlement agent investigates current access, flags, limits, and changes to the product state.
• The supervisor agent combines the findings, identifies the cross-system failure, and recommends the next action.

This is not merely an organizational pattern. It affects retrieval quality. Each agent searches a memory space aligned with its task, produces a focused finding, and passes that finding to a supervisor with broader context. The result is more controlled than giving every agent a massive graph and asking each one to search everything.

The design rule is simple: isolate by default, share deliberately, and grant broader memory access only to roles that need to reconcile multiple domains.