TencentDB Agent Memory Turns Chat Histories Into Governable Team Assets
Daily Open Source Project #60 TencentDB Agent Memory: A 14k-Star Team Memory Hub
GitHub Trending #1 | 2026-08-05 Snapshot | ⭐ 14,327 | Fork 1,315 | Primary Language TypeScript | License MIT (repository file)
Project URL: https://github.com/TencentCloud/TencentDB-Agent-Memory
📋 Project Overview
| Item | Information |
|---|---|
| Project Name | TencentDB Agent Memory |
| One-Liner | An Agent memory asset hub for individuals and teams, turning conversations, documents, and code into governable, shareable, and composable long-term assets |
| Trending Rank | 1 / 18 |
| Stars | 14,327 (Trending snapshot) |
| Forks | 1,315 |
| Open Issues | 513 (GitHub field includes Issues and PRs) |
| Primary Language | TypeScript; GitHub Linguist share 91.6% |
| License | Repository LICENSE explicitly states MIT; GitHub API temporarily misidentified it, returning NOASSERTION |
| Latest Release | v2.0.0, released 2026-08-03 |
| Default Branch | feat/server_team, not the usual main / master |
| Runtime Requirements | Full image stack uses Docker; source package requires Node.js ≥ 22.16 |
| Four Core Asset Types | Chat Memory, Skill, LLM-Wiki, CodeGraph |
Language Breakdown
| Language | GitHub Linguist Share | Primary Role |
|---|---|---|
| TypeScript | 91.6% | Memory Core, Proxy, Panel, Knowledge Service, and SDK body |
| Python | 3.5% | Python SDK, Hermes adapter, and auxiliary scripts |
| Shell | 2.2% | One-click deployment, verification, migration, and ops scripts |
| CSS | 1.8% | Memory Panel UI |
| JavaScript | 0.6% | Build and compatibility code |
| Dockerfile | 0.3% | Containerized deployment |
| HTML | <0.1% | Minimal static entry points |
Data scope: Stars, Forks, Issues, and language shares are from the 2026-08-05 Trending task snapshot; Release, Watchers, and source structure were verified on the same day. A supplementary API once showed 14,331 Stars, which only indicates a gain of 4 Stars between two observation points and should not be treated as "today's new additions."
🔥 Why It Matters
Many so-called "Agent Memory" solutions solve only one problem: chunking chat history, creating embeddings, and fetching Top-K from a vector store. TencentDB Agent Memory's ambition is clearly larger—it attempts to decompose an Agent's work experience into four distinct asset types: human preferences and decisions go into Chat Memory, successful workflows are distilled into Skills, documents become relational Wikis, and code becomes a queryable CodeGraph. The emphasis is not just on "being searchable," but on these assets also having an Owner, version, status, visibility, and Agent binding relationships.
This changes the working boundary for teams using Agents. Previously, new sessions, new members, or switching an Agent framework required re-explaining the project context; now, content that has already incurred a learning cost can be turned into a "team archive," and different assets can be assembled for roles like Scout, Builder, and Reviewer. It is not simply about expanding the context window, but about first structuring experience, then deciding who can see it, to whom it is assembled, and when it is injected.
Even more worthy of study is that the repository is not just a single product concept diagram. The source code reveals independent Memory Core, Memory Proxy, Memory Knowledge, and Memory Panel components, containing engineering mechanisms such as hybrid search, asynchronous refinement, distributed locks, dead-letter queues, protocol adaptation, session warm-up caches, Wiki two-stage ingestion, incremental code indexing, and ACLs. However, it is still in a phase of rapid evolution: the default branch name is unconventional, version surfaces are inconsistent, the public branch has no test files, and the README explicitly states that Team Memory Beta is iterating quickly. It resembles more of a technically deep early-stage platform than a mature product that can "mindlessly host all organizational knowledge out of the box."
🏗️ Core Features
1. Four Asset Types Are Not Four Entry Points, but Four Reuse Granularities
- Chat Memory: Preserves preferences, facts, constraints, and decisions, refined layer by layer from L0→L1→L2→L3.
- Skill: Extracts executable experience from successful tasks and tool calls, with versioning, resource files, trigger boundaries, steps, and validation rules.
- LLM-Wiki: Reorganizes product docs, design specs, and runbooks into structured Markdown pages and link relationships.
- CodeGraph: Indexes files, symbols, and call relationships, providing search, call chain, and impact scope queries for Agents.
These four asset types answer, respectively:
Chat Memory: What facts must not be forgotten about this person/team?
Skill: How was this type of task reliably completed last time?
Wiki: What are the entities, concepts, and relationships in the documentation?
CodeGraph: Where is the code, and which call paths might be affected by a change?
2. L0→L3: From Raw Dialogue to Injectable Persona
Source configuration shows that L1 is triggered by default every 5 conversation rounds; when warm-up is enabled, the threshold grows progressively from 1, 2, 4 up to the configured limit. L1 extracts atomic memories and performs deduplication, L2 aggregates scenarios, and L3 generates a more stable Persona. By default, Persona generation is triggered every 50 new memories, with a maximum of 20 scenario blocks retained.
L0 Raw Dialogue
└─ Captures messages, tool calls, sessions, and team/agent/task identity
↓ Background LLM extraction + deduplication
L1 Atomic Memory
└─ Facts / Preferences / Decisions / Constraints / Experience
↓ Scenario aggregation
L2 Scenario
└─ Stable patterns within a certain task type or context
↓ Persona summarization
L3 Persona
└─ Long-term profile and high-level context for subsequent Agents
The value here is not the tier names, but separating high-frequency raw data from low-frequency stable profiles: L0/L1 can have a TTL, while L2/L3 are responsible for long-term injection, avoiding stuffing entire chat histories back into the context.
3. Hybrid Search: FTS5 and Vector Search in Parallel, Merged via RRF
Memory Core's memory_search is not a simple vector Top-K. The SQLite path runs FTS5 keyword search and vector search in parallel, each over-fetching limit × 3 candidates, then merging using Reciprocal Rank Fusion:
RRF score(d) = Σ 1 / (60 + rank(d) + 1)
When the Embedding service is unavailable, it can degrade to FTS5; when FTS5 is unavailable, it can fall back to vector search. When using Tencent Cloud VectorDB, it can use the service's native dense + sparse hybrid search. The practical significance of this design: exact terms like code names and error codes are better suited for keyword search, while preferences and semantically similar experiences are better for vector search; RRF avoids directly comparing two sets of raw scores that are not on the same scale.
4. Skills Are Not Prompt Snippets, but Governed Team Assets
Skills support three visibility levels: private, team, and restricted. private belongs only to the Owner, team is visible to team members, and restricted can be finely authorized via User, Role, and Agent ACLs. Team members can review and share, then bind a Skill to a specific Agent, rather than having all Agents load all rules at once.
The retrieval layer supports bm25, embedding, and hybrid modes, with bounded Top-K queries; the asset layer tracks version, status, owner, and usage count. In other words, the system simultaneously handles both "how to find a skill" and "which version of a skill is allowed for whom."
5. Wiki: Analyze First, Then Generate, Then Deterministically Write to Disk
Wiki defaults to a two-stage LLM ingestion: Stage A first generates an extraction plan, Stage B then outputs FILE blocks. Sources exceeding approximately 28,000 characters are chunked; LLM output undergoes path whitelisting, structural file protection, path canonicalization, and deduplication merging before being written to disk. Structural files like schema.md, purpose.md, and index.md are prohibited from being directly overwritten by the model.
Raw Document
→ Chunking (~28K character budget)
→ Stage A: Analysis and extraction plan
→ Stage B: Generate FILE blocks
→ Path whitelist / canonicalize / locked checks
→ Create or merge Markdown pages
→ Rebuild index.md and SQLite index
This layer of deterministic post-processing is important: the model can decide the content, but cannot arbitrarily decide the final path, overwrite structural files, or bypass locked pages. It is closer to maintainable knowledge engineering than "letting the model write a bunch of Markdown randomly."
6. CodeGraph: Structural Query, Not Another Document RAG
CodeGraph performs a shallow clone of the repository, creates an index, and calls incremental sync() on subsequent synchronizations; upon failure, it falls back to a full re-clone. It exposes 8 query actions:
| Tool | Purpose |
|---|---|
search |
Search for symbols or related code nodes |
explore |
Continue exploring graph relationships from a node |
callers |
Find callers |
callees |
Find callees |
impact |
Analyze potential impact scope |
node |
Get node details |
status |
View index status |
files |
View file-level information |
An evidence boundary must be noted: this repository's Knowledge Service is primarily an orchestration and API wrapper around @colbymchenry/codegraph v1.2.0; the specific AST parsing and edge construction algorithms reside in the external platform package. One should not assert, based solely on this repository, that it uses a specific parser, nor equate structural graph queries with independently verified defect recall rates.
7. Proxy Supports Both Anthropic and OpenAI Protocols
The Proxy is responsible for identity verification, session initialization, context injection, and upstream model forwarding. Requests are first parsed by a protocol Adapter into a unified AgentContext, then Hooks are executed at fixed injection points, and finally serialized back to the original protocol. Agent Profile is preferentially identified via the URL path, avoiding scanning the system prompt each time; the session initialization phase can also pre-warm Hook caches.
Claude Code / CodeBuddy / OpenAI Client
→ Protocol Adapter
→ User authentication + team/agent/task session binding
→ Hook Cache / Memory / Skill / Knowledge queries
→ Injection at specified system / tools / user positions
→ Upstream LLM
→ Conversation write-back and background asset refinement
Hook failures are non-fatal by default: errors are logged and other injections continue, preventing a single knowledge source outage from causing the entire main model request to fail. This improves availability, but also means that operators must monitor injection logs and metrics; otherwise, "request successful" does not equal "memory successfully loaded."
🔬 Deep Technical Architecture Analysis
Overall Architecture: Separation of Data Plane, Knowledge Plane, Injection Plane, and Governance Plane
┌──────────────────── Agent / Client ─────────────────────┐
│ Claude Code │ CodeBuddy │ OpenClaw │ Hermes │ API Client │
└──────────────────────────┬───────────────────────────────┘
│ Anthropic / OpenAI protocol
┌──────────────────────────▼───────────────────────────────┐
│ Memory Proxy :8096 │
│ auth → session init → adapter → hooks/cache → injection │
└───────────────┬───────────────────────┬──────────────────┘
│ │
┌───────────────▼──────────────┐ ┌─────▼──────────────────┐
│ Memory Core :8420 │ │ Knowledge :8424 │
│ L0 capture │ │ Wiki ingest/index │
│ L1/L2/L3 pipeline │ │ CodeGraph clone/sync │
│ FTS5/vector/hybrid recall │ │ MCP/API query tools │
│ Skill + metadata + ACL │ └──────────┬─────────────┘
└───────────────┬──────────────┘ │
└──────────────┬──────────────┘
▼
SQLite / JSONL / COS / Redis / Tencent VDB
│
┌──────────────────────────────▼───────────────────────────┐
│ Memory Panel :8125 │
│ Team / Agent / Task / Owner / Version / ACL / Binding │
└──────────────────────────────────────────────────────────┘
Task Scheduling: Concurrency and Recovery Mechanisms for Slow LLM Tasks
The Memory Pipeline Worker uses a competing consumer model. The service pattern indicated by source comments is Redis Stream Consumer Groups; each session's L1/L2 uses a distributed lock, and L3 defaults to locking per instance. Locks are renewed every 30 seconds, with a default TTL of 240 seconds; if a lock is lost, an AbortSignal aborts any ongoing LLM call, and the ACK is skipped, allowing the task to be reclaimed by another Worker.
| Config Item | Source Default | Engineering Meaning |
|---|---|---|
| Worker concurrent consumption coroutines | 60 | Different sessions can run in parallel; not a measured performance throughput |
| Lock TTL | 240 seconds | Provides a 2x buffer for LLM requests up to ~120 seconds |
| Lock renewal interval | 30 seconds | Reduces the probability of lock expiry due to GC or event loop stalls |
| Max retries | 3 times | Exceeding limit enters dead-letter logic |
| Backoff | 5 / 15 / 45 seconds | Reduces retry storms during LLM/API failures |
| Pending reclamation cycle | 30 seconds | Reclaims tasks left by abnormally exited Workers |
| Pending determination timeout | 300 seconds | Must be greater than lock TTL |
| Recall total timeout | 5 seconds | Skips recall on timeout, not blocking the main request for too long |
This table is a default parameter audit, not an official performance benchmark. The repository README provides no reproducible latency, throughput, recall rate, or cost comparisons, so one cannot deduce "processes 60 tasks per second" from "concurrency of 60."
Data Consistency and Fault Boundaries
- Idempotent Writes: Memory Worker upserts via
record_id; COS uses overwrite writes. - Switchable Lock Granularity: Defaults to session granularity; if shared JSONL poses concurrent append risks, can temporarily switch to instance granularity, at the cost of serializing tasks on the same instance.
- CodeGraph Build State Machine:
pending → processing(cloning/indexing) → ready / failed; creation and sync return immediately, handled by a background queue. - Shared Knowledge Build Queue: Wiki and CodeGraph share a serial BuildQueue by default; the advantage is avoiding local build resource contention, the disadvantage is that a large repository index might block subsequent Wiki tasks.
- Auto Sync: CodeGraph can enable scheduled scanning with a fixed Worker Pool; the queue deduplicates via a Set; disabled by default, with a default scan interval of 10 minutes and a default max concurrency of 3.
- Restart Recovery: On startup, interrupted build tasks are marked as failed, and already synced graph instances and Wiki indexes are asynchronously recovered.
Security and Isolation Boundaries
The system's Team, Owner, and ACL are application-layer authorization, not OS sandboxes. The Knowledge Service's Git Source Fetcher only accepts HTTPS and includes internal/loopback address blocking to reduce SSRF risks; code index directories are isolated by service_id/team_id/code_graph_id. The Proxy Cache Key also includes dimensions like user, agent source, session, and space to prevent cross-user cache collisions.
However, deployers must still secure the four local ports, LLM API Keys, the admin user_key, persistent volumes, and the proxy upstream themselves. The README recommends using the admin account for operations and regular business accounts for daily Agent assets. This advice should be treated as a starting point for least privilege, not a complete zero-trust solution.
Source Code Scale and Maturity Audit
A shallow clone statistic on the v2.0.0 default branch commit 0aff21a:
| Metric | Result | Scope |
|---|---|---|
| Git tracked files | 837 | git ls-files |
| Estimated source lines | 176,154 | Counted TS/TSX/JS/Python/Shell/CSS/HTML/SQL, excluding build dirs and binaries |
| MemoryCore files | 324 | Top-level directory attribution |
| MemoryPanel files | 200 | Top-level directory attribution |
| MemoryProxy files | 151 | Top-level directory attribution |
| MemoryKnowledge files | 69 | Top-level directory attribution |
| Test-style files | 0 | No test/tests/__tests__ or .test/.spec files found on the current public default branch |
It is worth noting that multiple package.json files retain Vitest and E2E scripts, but the current public default branch has no corresponding test files; this means regression quality cannot be directly verified from the repository. On the other hand, the source code is not a thin shell: the implementation scale of Memory Core and Proxy is substantial, with concrete code for critical task scheduling, hybrid search, Wiki disk writing, and CodeGraph orchestration. A reasonable judgment is: product implementation depth is high, but public verifiability still lags behind the pace of feature expansion.
📖 README Core Content Summary
The README's core proposition can be condensed into one sentence: Don't make every Agent re-learn the same project; turn the context cost already paid into a team archive.
Three Closed Loops Emphasized by the README
- Automatic Refinement: Extract Chat Memory and Skills from conversations and tasks; generate Wiki and CodeGraph from documents and code.
- Cross-Agent Portability: Assets are decoupled from a single Agent framework and can be shared and maintained by different members and different Agents.
- Cold Start Import: Import existing codebases, documents, and historical Agent sessions, allowing new Agents to start from existing experience.
The "One-Person Company" Role Assembly Method
The README uses Scout, Builder, and Reviewer to demonstrate assembling assets by role: Scout loads user interview memories, market Wiki, and competitor Skills; Builder loads product Wiki, project CodeGraph, and delivery Skills; Reviewer loads historical incident memories, CodeGraph, and release check Skills. The key is not creating multiple chat windows, but giving roles different and controlled contexts, reducing irrelevant information.
Differences from Ordinary RAG
| Dimension | Ordinary RAG | TencentDB Agent Memory |
|---|---|---|
| Main Question | Which text chunks are similar to the query? | What type of experience should be persisted, who can use it, which version is valid, and to which Agent should it be assembled? |
| Asset Form | Chunk + Embedding | Chat Memory + Skill + Wiki + CodeGraph |
| Structural Relationships | Usually weak | Wiki Link Graph and CodeGraph |
| Governance | Often relies on external systems | Built-in Owner, Version, Status, Visibility, and ACL |
| Agent Injection | Application stitches it together itself | Proxy injects via Protocol Adapter and Hooks |
Boundaries Readers Need to Fill In Themselves
- v2.0.0 has been released, but
MemoryCore/package.jsonstill reads2.0.0-beta.1, while MemoryKnowledge and MemoryProxy each read0.1.0; version surfaces are not fully aligned. - The README badge says MIT, and the repository LICENSE is indeed MIT; GitHub API's
NOASSERTIONis a recognition failure, not an absence of a license. - CodeGraph can provide structural traversal, but cannot replace compilation, testing, static scanning, and manual review; dynamic language runtime behavior should also not be fully inferred from static graphs alone.
- Wiki and memory refinement depend on LLMs; output quality, cost, and privacy boundaries depend on the model and upstream services configured by the deployer.
🚀 Quick Start
Prerequisites
- Install Docker and ensure ports 8420, 8125, 8424, 8096 are not occupied.
- Prepare two sets of LLM parameters: one for Memory/Knowledge refinement, one for Proxy forwarding of main Agent requests.
- If developing directly from source, Node.js ≥ 22.16 is required; full image deployment does not require local TypeScript compilation.
1. Pull and Prepare Configuration
git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env
At minimum, fill in:
MEMORY_LLM_BASE_URL / MEMORY_LLM_API_KEY / MEMORY_LLM_MODEL
PROXY_UPSTREAM_URL / PROXY_UPSTREAM_API_KEY / PROXY_UPSTREAM_MODEL
2. Run Deterministic Pre-checks, Then Start
./verify.sh
./start-all.sh
In offline environments, use the repository's explicitly supported flag to skip LLM external probing:
./verify.sh --skip-llm
start-all.sh starts services in the order Memory Core → Memory Hub → Proxy, waiting for the previous service to be healthy before proceeding. This article has performed bash -n syntax checks on this set of Shell scripts in v2.0.0, and they pass; however, it does not substitute for the reader completing an end-to-end deployment using real Docker, model keys, and persistent volumes.
3. Open Console and Connect Claude Code
Console address: http://localhost:8125. The admin Key generated on first startup is saved in the deployment directory's .admin-key. The README recommends first creating a regular business user, then using the business user's user_key to connect the Agent:
export ANTHROPIC_BASE_URL=http://127.0.0.1:8096/claude-code/default
export ANTHROPIC_AUTH_TOKEN='<business-user-key>'
claude --model '<PROXY_UPSTREAM_MODEL>'
The first session will sequentially select Team, Agent, and optional Task. Once bound, subsequent turns will have the Proxy automatically inject that Agent's L2/L3, Skills, and Knowledge; L0 dialogue continues to be written back, and background Workers refine new assets.
4. Verify the Pipeline Is Actually Working
curl -s http://localhost:8420/health | jq .services.pipelineWorker
Focus on whether tasksConsumed and tasksCompleted are increasing. Seeing the model reply is not enough; also confirm: session binding succeeded, injection logs appeared, background tasks were consumed, and assets were generated in the Panel.
📊 Growth Rate and Community Heat
Growth Rate Assessment
The repository was created on 2026-04-07, 120 days before the 2026-08-05 snapshot. Based on 14,327 Stars, the historical lifetime average is approximately 119.4 Stars/day. This number only reflects the overall attractiveness since creation and does not represent the last 24 hours' velocity; the task snapshot did not retain "today's new Stars," and the Trending #1 rank cannot be reverse-engineered into a daily increment.
| Metric | Value | Interpretation |
|---|---|---|
| Trending Rank | 1 / 18 | Highest exposure and attention that day |
| Stars | 14,327 | Very high for a repository created only ~4 months ago |
| Forks | 1,315 | Fork/Star ratio ~9.2%, indicating strong trial and secondary research intent |
| Open Issues + PRs | 513 | GitHub aggregated field; high count reflects both activity and maintenance pressure |
| Watchers | 53 | Supplementary API value from the same day |
| Releases | At least 10 | From v0.2.2 to v2.0.0, version advancement is very fast |
| Latest Stable Version | v2.0.0 | Released 2026-08-03, just 2 days before the trending snapshot |
| Default Branch Public Commits | Only 6 visible in shallow clone | Release-style large commits/history squashing distorts traditional contribution metrics |
The GitHub Contributors API returned only 4 accounts on the default branch, with a maximum contribution count of 2; this clearly does not match the ~170k-line source scale, indicating the public history has likely undergone migration, squashing, or release-style imports. Therefore, one cannot use "4 contributors" to directly judge the actual dev team size, nor use 6 commits on the default branch to evaluate R&D activity.
Positive community signals are Stars, Forks, frequent Releases, and the 500+ Issue/PR aggregate; risk signals are Team Memory still labeled Beta, an unconventional default branch, missing public tests, cross-component version drift, and a large Issues/PR queue. A more accurate conclusion is: extremely fast growth, intensive discussion, significant engineering investment, but the maintenance and stabilization phase is not yet complete.
Today's Full Trending List
| Rank | Repository | Rank | Repository |
|---|---|---|---|
| 1 | TencentCloud/TencentDB-Agent-Memory | 10 | gabime/spdlog |
| 2 | zhaoxuya520/reverse-skill | 11 | denoland/deno |
| 3 | firecrawl/pdf-inspector | 12 | usekaneo/kaneo |
| 4 | uber/ADR | 13 | livekit/agents |
| 5 | obra/superpowers | 14 | angular/angular |
| 6 | microsoft/generative-ai-for-beginners | 15 | tailwindlabs/tailwindcss |
| 7 | cypress-io/cypress | 16 | browser-use/video-use |
| 8 | lyogavin/airllm | 17 | esengine/DeepSeek-Reasonix |
| 9 | webpack/webpack | 18 | EveryInc/compound-engineering-plugin |
Among these 18 projects, TencentDB Agent Memory deserves priority analysis, not only because it ranks first, but also because it simultaneously covers memory refinement, retrieval, knowledge graphs, code graphs, protocol proxying, and team governance—a technical breadth significantly deeper than tutorial repos, rule collections, or single-purpose tools.
🎯 Applicable Scenarios
| Scenario | Suitability | Reason and Suggestion |
|---|---|---|
| Long-cycle software projects | High | Can persist architecture decisions, incident experience, code relationships, and release Skills |
| Multi-Agent collaboration | High | Different roles can assemble different assets, reducing context noise |
| Individual "one-person company" | High | Scout/Builder/Reviewer can share the same team archive |
| Internal enterprise knowledge hub pilot | Medium-High | Has ACL, Owner, and team model, but needs supplementary SSO, audit, backup, and network isolation assessment |
| Claude Code / CodeBuddy enhancement | High | Proxy already provides session selection, protocol adaptation, and automatic injection |
| OpenClaw / Hermes integration | Medium-High | Repository provides corresponding adapters, but version compatibility should be verified in a non-critical environment first |
| Strictly offline environments | Medium | Core can be deployed locally, but whether refinement, Embedding, and main model are offline depends on model configuration |
| Strongly compliant production systems | Cautious | Requires additional verification of data retention, deletion, permission auditing, key management, and third-party model egress |
| Just want to add simple memory to chat | Low | Four services and governance model may be overkill; SQLite + FTS/vector plugins are simpler |
💡 Summary
The most valuable aspect of TencentDB Agent Memory is not that it built yet another vector memory store, but that it proposes a complete "Agent experience assetization" framework: conversations become memories, successful workflows become Skills, documents become Wikis, code becomes a CodeGraph, all governed through Teams, Owners, versions, ACLs, and Agent bindings. The Proxy feeds these assets back to clients like Claude Code and CodeBuddy, forming a closed loop of capture—refinement—governance—injection—reproduction.
Judging from the source code, it already possesses engineering depth beyond a proof-of-concept: FTS5 and vector RRF hybrid search, an asynchronous pipeline with distributed locks and dead letters, a protocol Adapter, injection Hooks, deterministic Wiki disk writing, and incremental CodeGraph sync are all real implementations. At the same time, the lack of public tests, inconsistent component versions, a shallow default branch history, and Beta status also remind us: it is suitable for technical validation and team piloting now, but before entering critical production pipelines, stress testing, regression, backup/recovery, security auditing, and model cost assessment should still be completed.