# MemoryCore, MemoryPanel, and MemoryKnowledge Service Responsibilities Explained

> Understand MemoryCore, MemoryPanel, and MemoryKnowledge service responsibilities. Learn how MemoryCore handles data, MemoryPanel manages UI, and MemoryKnowledge processes knowledge assets for TencentDB Agent Memory.

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

---

**MemoryCore manages the data-plane storage and skill execution APIs, MemoryPanel provides the control-plane UI and request forwarding layer, and MemoryKnowledge operates the knowledge-plane ingestion pipelines for wiki and code-graph assets.**

The TencentDB-Agent-Memory repository implements a three-tier team-memory architecture that separates concerns across distinct service boundaries. Understanding how MemoryCore, MemoryPanel, and MemoryKnowledge divide responsibilities ensures correct deployment and API integration. Each service exposes specific endpoints and follows strict interaction contracts documented in the project's README files and source code.

## MemoryCore: Data-Plane Storage and Processing

**MemoryCore** serves as the data-plane engine, providing low-level read/write APIs, authentication, and skill/RAG execution. According to [`MemoryCore/README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryCore/README.md), this component handles all persistent storage operations and LLM-driven processing.

Key responsibilities include:

- **Gateway API Exposure** – Serves the `/v3/*` endpoint hierarchy (e.g., `POST /v3/conversation/add`, `GET /v3/conversation/query`) that accepts raw memory operations.
- **Request Authentication** – Validates API-key and user-key headers at the request level before executing operations.
- **Skill and RAG Execution** – Manages skill extraction pipelines, LLM inference calls, and vector-store interactions for retrieval-augmented generation.
- **Health and Metrics** – Exposes operational endpoints for monitoring service status and performance counters.

The Core operates on port `8420` by default and expects `Authorization` and `x-tdai-service-id` headers for every request.

## MemoryPanel: Control-Plane UI and Public API

**MemoryPanel** functions as the control-plane interface, offering a stateless web console and public REST API for operators to manage teams, users, agents, and memory assets. As documented in [`MemoryPanel/README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryPanel/README.md), this service does not persist user sessions or credentials, delegating all storage to external services configured at startup.

Key responsibilities include:

- **React-Based Management UI** – Serves the frontend application at `http://localhost:8125` for interactive team and asset management.
- **Request Forwarding** – Validates incoming credentials, then forwards authorized calls to MemoryCore for actual data manipulation.
- **Metadata Aggregation** – Provides REST endpoints under `/api/v1/` (e.g., `/api/v1/meta/*`, `/api/v1/skill/*`, `/api/v1/knowledge/*`) that aggregate metadata from the Core for presentation purposes.
- **Stateless Operation** – Maintains no local persistence; all configuration and secrets are injected via environment variables at startup.

The Panel acts as a reverse proxy and validator, ensuring only authenticated traffic reaches the Core's data-plane endpoints.

## MemoryKnowledge: Knowledge-Plane Ingestion Service

**MemoryKnowledge** manages the knowledge-plane, handling the ingestion, processing, and storage of wiki pages and code-graph structures. As outlined in [`MemoryKnowledge/README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryKnowledge/README.md), this service operates independently but is commonly co-deployed with the Panel in the **Memory Hub** container image.

Key responsibilities include:

- **Knowledge Asset CRUD** – Exposes `/v3/knowledge/*` endpoints for creating, updating, and querying wiki entries and code-graph nodes.
- **Ingestion Pipelines** – Executes LLM-driven "wiki ingest" and "code-graph build" workflows that chunk, embed, and store content.
- **Callback Notifications** – Posts status updates to the Panel's `TMC_CALLBACK_URL` after successful ingestion, enabling UI refreshes and metadata synchronization.
- **LLM Binding Exposure** – Returns `llm_binding` configuration data that the Panel pushes to MemoryCore for runtime model associations.

This service typically binds to port `8424` and writes processed vectors and metadata into MemoryCore's storage layer through the Core's internal APIs.

## Service Interaction Architecture

The three services form a tiered stack with specific communication patterns:

**Panel → Core** – After validating a request using bearer tokens, the Panel forwards the payload to MemoryCore. For example, when creating a skill, the Panel handles the UI interaction and API validation, but MemoryCore performs the actual database write via `POST /v3/skill/add`.

**Panel ↔ Knowledge** – The Panel triggers long-running ingestion jobs by calling MemoryKnowledge endpoints (e.g., `POST /v3/knowledge/wiki/ingest`). Upon completion, MemoryKnowledge sends a callback to the Panel's configured `TMC_CALLBACK_URL` with status updates and asset identifiers, allowing the Panel to refresh its cached metadata views.

**Knowledge → Core** – Following successful ingestion, MemoryKnowledge writes the resulting vector embeddings and graph metadata directly into MemoryCore using the Core's `/v3/meta/*` and `/v3/knowledge/*` storage APIs.

This architecture allows independent scaling: you can run MemoryCore as a standalone data service while co-locating Panel and Knowledge in the combined **memory-hub** image, as described in [`deploy/panel-knowledge-combined/README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/deploy/panel-knowledge-combined/README.md).

## Implementation Examples

### Creating a Team via MemoryPanel

```bash
curl -X POST http://localhost:8125/api/v1/meta/team \
  -H "Authorization: Bearer <API_KEY>" \
  -H "x-tdai-service-id: <SERVICE_ID>" \
  -d '{"name":"demo-team","description":"Demo team for testing"}'

```

### Storing Conversation Data in MemoryCore

```bash
curl -X POST http://localhost:8420/v3/conversation/add \
  -H "Authorization: Bearer <CORE_API_KEY>" \
  -H "x-tdai-service-id: <SERVICE_ID>" \
  -d '{
        "session_id":"sess-123",
        "messages":[
          {"role":"user","content":"What is the status?"},
          {"role":"assistant","content":"All systems operational."}
        ]
      }'

```

### Ingesting Wiki Content via MemoryKnowledge

```bash
curl -X POST http://localhost:8424/v3/knowledge/wiki/ingest \
  -H "Authorization: Bearer <KNOWLEDGE_API_KEY>" \
  -H "x-tdai-service-id: <SERVICE_ID>" \
  -d '{
        "title":"Architecture Overview",
        "content":"The system uses a three-tier memory architecture..."
      }'

```

### Knowledge-to-Panel Callback

After ingestion completes, MemoryKnowledge automatically invokes the Panel callback:

```bash
POST http://localhost:8125/api/v1/knowledge/callback \
  -H "Content-Type: application/json" \
  -d '{"status":"ok","wiki_id":"wiki-123"}'

```

## Summary

- **MemoryCore** operates the data-plane, handling all persistent storage, vector operations, and LLM skill execution through `/v3/*` endpoints.
- **MemoryPanel** provides the control-plane, serving a React management UI and forwarding validated requests to the Core without maintaining local state.
- **MemoryKnowledge** runs the knowledge-plane, managing wiki and code-graph ingestion pipelines and notifying the Panel via `TMC_CALLBACK_URL` upon completion.
- **Service flow** follows a strict hierarchy: Panel validates and forwards to Core for storage; Panel triggers Knowledge for ingestion; Knowledge writes results to Core and callbacks to Panel.
- **Deployment flexibility** allows running services independently or combined in the official **memory-hub** container image.

## Frequently Asked Questions

### What is the primary difference between MemoryCore and MemoryPanel?

MemoryCore manages the data-plane including all storage, authentication, and LLM execution, exposing low-level `/v3/*` APIs. MemoryPanel provides the control-plane UI and public `/api/v1/*` REST endpoints, acting as a stateless gateway that validates requests before forwarding them to the Core. The Panel never performs data persistence itself.

### How does MemoryKnowledge communicate ingestion status back to the Panel?

After completing a wiki or code-graph ingestion job, MemoryKnowledge sends an HTTP POST to the Panel's `TMC_CALLBACK_URL` environment variable. This callback includes the operation status and asset identifiers (e.g., `wiki_id`), allowing the Panel to refresh its metadata cache and update the UI without polling.

### Can I deploy these three services independently?

Yes. Each service is designed to operate independently with separate ports (Core on `8420`, Panel on `8125`, Knowledge on `8424`). You can deploy MemoryCore as a standalone data service while running Panel and Knowledge together using the **memory-hub** combined image documented in [`deploy/panel-knowledge-combined/README.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/deploy/panel-knowledge-combined/README.md), or deploy all three separately for high-availability configurations.

### Which component handles API authentication and security?

MemoryCore performs the actual request-level authentication using `Authorization` and `x-tdai-service-id` headers. MemoryPanel validates these credentials on incoming requests before forwarding traffic to the Core, but the Core serves as the ultimate authority for access control and data isolation.