Overview

TencentDB Agent Memory treats access as part of memory quality: a Team, Agent, User, and optional Task establish scope before relevance ranking. The control plane separates permission to read or use an asset from permission to bind it into an Agent’s loadout, applying ownership, visibility, roles, ACLs, status, and Team relationships. The Hub manages these relationships while Core and asset stores remain authoritative. Explicit scope limits leakage and wrong-role context, though compatibility defaults and control-plane failures can weaken shared recall.

Learning outcomes

Relevance is not authorization: an asset must be in the caller’s permitted scope before it can reach the session.
Permission and binding are separate; someone may read a shared asset without being able to equip it as another Agent’s default context.
Visibility, ACLs, ownership, and human correction help prevent private or role-inappropriate material from becoming inherited instruction, but explicit identity fields remain essential.

Keywords

GovernanceLoadoutIdentityVisibilityACLBindings

Memory as a Governed Agent Loadout

TencentDB Agent Memory treats access as part of the memory problem. This chapter focuses on how a user, Team, Agent, and Task determine the scope of an asset, and how ownership, visibility, ACLs, and bindings decide what can actually reach a session. The result is a practical distinction: a memory can be relevant to a question without being permissible or appropriate for the Agent that is asking it.

A global memory namespace is attractive because it is simple. Every Agent searches the same pool, and the most similar records win. That model fails as soon as a team has different roles, private working notes, or multiple projects with different constraints. “Relevant” is not a complete authorization decision. The system needs to know whose experience produced the asset, which Team and Agent it belongs to, whether the caller is a member, and whether the asset was intentionally assigned to this working context.

The identity graph behind a session

The control plane starts with a human identity and a Team. A Team is not only a label for grouping users; it is a scope for Agents, Tasks, and assets. Membership gives a caller a relationship to that Team, while a role such as admin, member, or reviewer can affect default actions. An Agent belongs to a Team and has an owner, description, and prompt that define the role it is meant to perform. A Task identifies a concrete piece of work and can be linked to one or more Agents.

When the Proxy initializes a session, the Team–Agent–Task selection becomes the identity context for the turn. The memory data plane also carries team, user, and Agent dimensions, with Task available as a narrower business filter. The v3 API documentation describes the Team + Agent + User combination as the core isolation triple. The repository’s compatibility code still supplies default values when an older caller omits fields, so the effective strictness depends on the route and deployment configuration. The design intention is clear even where migration compatibility remains: new integrations should not treat a shared default bucket as an adequate substitute for explicit identity.

The difference is easiest to see with two Agents in one Team. A release reviewer may need the Team’s incident history and the codebase’s impact information. A customer-support Agent may need product decisions and customer-facing guidance but not internal debugging notes. Both can ask about “the login issue,” and semantic retrieval may find the same words. Their loadouts should still differ because the Agent role and its fixed bindings express an intentional selection before ranking begins.

A Task adds another useful boundary without replacing the Agent identity. It can narrow recall to a project or work item, associate participating Agents, and give the Proxy a concrete description to include in the session context. But the repository also documents paths where Task is optional, especially for integrations that want broad recall across an Agent’s memories. That is a business choice, not permission to omit the user or Agent dimensions indiscriminately.

Published by DeepMox

FAQ

What is the difference between asset permission and Agent binding?

Permission determines whether a caller may perform an action on an asset; binding determines whether that asset can be equipped in an Agent’s loadout. Permission to inspect an asset does not automatically authorize making it default context.

Can a Team administrator access a private asset?

No. In the documented private mode, only the owner can access the asset, including when the caller is a Team administrator.

What happens when an asset’s visibility changes after binding?

A previous binding can become unusable when visibility changes or the asset is archived. The loadout is a governed relationship, not a permanent copy of whatever was once searchable.

Previous10 minTencentDB Agent Memory: Diagnose Missing Context

Next8 minTencentDB Agent Memory: From Turns to Skills

TencentDB Agent Memory: Governed Agent Loadouts

Memory as a Governed Agent Loadout

The identity graph behind a session

FAQ