# How Memory Hub Team Management and Asset Binding Works: A Technical Deep Dive

> Discover how Memory Hub team management and asset binding work. Explore hierarchical roles and fixed asset binding for efficient resource allocation in TencentDB Agent Memory.

- Repository: [Tencent Cloud/TencentDB-Agent-Memory](https://github.com/TencentCloud/TencentDB-Agent-Memory)
- Tags: deep-dive
- Published: 2026-08-26

---

**Memory Hub implements a hierarchical team management system with System Admin and Team-level roles (Admin/Member) that control asset visibility, paired with a fixed-asset binding mechanism through `setAgentFixedAssets` to equip agents with specific Chat Memory, Skills, Wiki, and CodeGraph resources.**

The TencentDB-Agent-Memory repository provides a production-ready implementation of Memory Hub that separates organizational access control from runtime asset allocation. Understanding how Memory Hub team management and asset binding work requires examining both the permission layer that governs who can create and modify resources, and the binding layer that determines which specific assets an agent can access during execution.

## Team Management Architecture

The Memory Hub enforces a two-tier role system that separates global platform administration from team-specific resource governance.

### Role Hierarchy and Permissions

According to the source code in [[`README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/README.md)](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/feat/server_team/README.md), the platform defines distinct authority levels:

- **System Admin**: Global role with capabilities to create teams, manage cross-team users, and oversee platform-wide settings
- **Team Admin**: Team-level manager who can add or remove members, modify team assets, and set access control lists (ACLs)
- **Member**: Regular team participant with read and limited write permissions based on asset ownership

These roles determine access to the team management APIs exposed in [`metadata-client.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/metadata-client.ts). The hierarchy is documented in the README section describing the "🛡️ A team memory panel controlled by humans" feature, specifically around lines 131-135.

### Team Lifecycle Operations

Teams are created, maintained, and destroyed through the **MetadataClient** class in [`/sdk/memory-core/typescript/src/v3/metadata-client.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main//sdk/memory-core/typescript/src/v3/metadata-client.ts). The lifecycle follows these specific method calls:

- `createTeam`: Initializes a new team with an owner and metadata
- `team/get`, `team/update`, `team/delete`: Manage existing team records
- `addTeamMember` / `removeTeamMember`: Control membership via `team-member/add` and `team-member/remove` endpoints

The TypeScript SDK implements these as asynchronous methods that communicate with the Memory Hub REST API, validating the caller's System Admin or Team Admin credentials before executing state changes.

## Asset Visibility and Ownership Controls

Every memory asset in the system carries metadata fields that govern access independent of the binding mechanism.

### Visibility Flags and Access Control

Assets created through `metadataClient.createAsset()` include two critical security fields:

- **`owner_user_id`**: Grants automatic full management rights to the creating user
- **`visibility`**: Enum value determining access scope—`private` (owner only), `team` (team members), `restricted` (ACL-based), or `agent` (specific agent only)

Team admins can manage assets where visibility is set to **team** or **restricted**, while the original owner retains override capabilities regardless of team membership changes. This model appears in the README documentation around lines 129-135 and is enforced server-side in [`MemoryCore/src/utils/manifest.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryCore/src/utils/manifest.ts).

## Fixed Asset Binding Mechanism

While team management controls who can see assets, the **Fixed-Asset Binding** system controls which assets agents actually load during execution.

### Binding Structure and API

Assets are equipped to agents through explicit bindings stored in the `agent-fixed-asset` service. The binding ties an `agent_id` to a prioritized list of asset references using the `setAgentFixedAssets` method:

```typescript
// Set fixed assets for an agent (team-level binding)
await metadataClient.setAgentFixedAssets(agentId, [
  { asset_id: "a1", asset_type: "skill", priority: 1 },
  { asset_id: "a2", asset_type: "wiki", priority: 2 },
]);

```

This client call translates to a POST request against the `/v3/agent-fixed-asset/set` endpoint, as implemented in [`metadata-client.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/metadata-client.ts) at lines 256-259. Each binding includes:
- **`asset_id`**: Unique identifier of the memory asset
- **`asset_type`**: Category classification (skill, wiki, codegraph, chat_memory)
- **`priority`**: Integer determining precedence when multiple assets match a query

### Runtime Resolution Logic

When an agent issues a request to the hub, the system executes a two-step filtering process described in the README's "Technical Implementation" section (lines 58-63):

1. **Permission Scope Narrowing**: Filters assets by **Team → User → Agent → Visibility** hierarchies
2. **Fixed Binding Selection**: Retrieves the agent's fixed asset list via `listAgentFixedAssets` or `listAgentFixedAssetsWithDetail` (lines 260-262 in [`metadata-client.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/metadata-client.ts)) and intersects it with the permission-scoped assets

The server-side logic in [`MemoryCore/src/utils/manifest.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryCore/src/utils/manifest.ts) validates asset ownership during this resolution phase, ensuring that even if an asset is in an agent's fixed binding list, it only returns if the requesting context satisfies the visibility rules.

## Implementation Walkthrough

The following TypeScript examples demonstrate the complete lifecycle from team creation to asset binding using the Memory Hub SDK:

```typescript
// 1️⃣ Create a new team (requires System Admin role)
await metadataClient.createTeam({
  team_name: "Tiny but Serious Inc.",
  owner_user_id: "u123",
  description: "A one-person startup team",
});

// 2️⃣ Add a member to the team (requires Team Admin role)
await metadataClient.addTeamMember({
  team_id: "t1",
  user_id: "u456",
  role: "member",
});

// 3️⃣ Create a skill asset with team visibility
await metadataClient.createAsset({
  asset_type: "skill",
  name: "Release Checklist",
  content: "...",
  visibility: "team",
  team_id: "t1",
});

// 4️⃣ Bind the skill to a specific agent
await metadataClient.setAgentFixedAssets("agent_release", [
  { asset_id: "skill-xyz", asset_type: "skill", priority: 1 },
]);

```

These operations require the requesting user to hold appropriate roles at each stage: System Admin for team creation, Team Admin for member management and asset binding, and either ownership or team admin rights for asset creation.

## Summary

- **Memory Hub team management** operates on a dual-layer role system: global System Admins create teams, while Team Admins manage members and resources within their organizational units.
- **Asset visibility** is controlled through four levels (`private`, `team`, `restricted`, `agent`) combined with mandatory `owner_user_id` fields that persist regardless of team membership changes.
- **Fixed asset bindings** explicitly link agents to specific resources via `setAgentFixedAssets`, with priority values determining precedence during runtime resolution.
- **Runtime security** follows a two-phase validation: first narrowing by team/user permissions, then filtering by the agent's fixed binding list, as enforced in [`MemoryCore/src/utils/manifest.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryCore/src/utils/manifest.ts).
- The **TypeScript SDK** in [`metadata-client.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/metadata-client.ts) provides the primary interface for these operations, mapping to REST endpoints like `/v3/agent-fixed-asset/set`.

## Frequently Asked Questions

### What roles exist in Memory Hub team management?

Memory Hub defines three distinct roles across two administrative tiers. **System Admins** possess global platform authority to create teams and manage users across organizational boundaries. Within each team, **Team Admins** can add or remove members, modify assets, and configure ACLs, while **Members** have limited access based on asset visibility settings and ownership. These roles are documented in the README around lines 131-135 and enforced through the MetadataClient API.

### How does asset visibility work in Memory Hub?

Asset visibility operates through a four-state enumeration: `private` restricts access to the owner only, `team` allows any team member to view and use the asset, `restricted` applies custom ACL rules, and `agent` limits access to a specific agent regardless of team membership. Every asset stores an `owner_user_id` field that grants immutable administrative rights to the creator, superseding team-based permissions when ownership is asserted.

### What is the difference between asset ownership and team visibility?

**Ownership** is a persistent attribute tied to the `owner_user_id` field that grants full CRUD rights to the asset creator regardless of team changes or visibility settings. **Team visibility** is a dynamic access control flag that determines which users within a team can view or reference the asset. An owner can delete an asset even if its visibility is set to `team`, whereas a Team Admin can modify an asset only if visibility is `team` or `restricted`, but cannot override ownership-based deletion rights.

### How are assets resolved at runtime for agents?

Runtime resolution follows a strict two-step process implemented in [`MemoryCore/src/utils/manifest.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryCore/src/utils/manifest.ts). First, the hub filters the complete asset universe by **Team → User → Agent → Visibility** constraints to generate a permission-scoped subset. Second, it retrieves the agent's fixed bindings via `listAgentFixedAssets` and returns only the intersection of permission-scoped assets and explicitly bound assets, sorted by the `priority` values defined in the binding configuration.