Never Repeat a Mistake: TencentDB Agent Memory Raises Completion from 60% to 80%

Problem Definition: Execution Capacity Grows Faster Than Collaboration Bandwidth

When agents make a single developer much faster, the real bottleneck shifts from code generation to the ability to transfer information across people, sessions, branches, and permission domains. The authors define "collaboration bandwidth" as the effective context that can be understood and used by the right person or agent within the correct permission boundary.

OPC (One‑Person Company) as an Observation Sample

OPC is an AI‑native organization where a single decision‑maker works with multiple agents, splitting research, development, content, and operations among digital capabilities. METR’s measurement of model task‑completion time shows a doubling every seven months for software‑engineering‑focused tasks, and Anthropic’s analysis of Claude Code interactions confirms rapid growth of coding agents.

OPC’s efficiency comes not only from a person doing more work, but also from reduced hand‑offs, lower isolation, and focused goals. However, OPC does not eliminate collaboration; it rewrites many human interactions into a single person plus agents sharing context.

Collaboration Bandwidth Definition

The authors formalize collaboration cost as:

collaboration_cost ≈ handoff_count × handoff_cost + conflict_resolution_cost + permission_and_compliance_cost

This formula separates three intertwined aspects: whether information can be found, whether it can be understood, and whether it can be used under the correct permissions.

Three‑Layer AI Organization Architecture

Inspired by Sun Tianxiang’s talk, the architecture consists of:

Top layer : governance and resource allocation.

Middle layer : the joint workspace of humans and AI agents.

Bottom layer : shared assets (skill, trajectory, substrate) that are inheritable.

The bottom layer stores validated task states; the middle layer consumes them; the top layer enforces boundaries and versioning.

Spec‑Driven Development and Its Relation to Team Memory

Spec‑driven development emphasizes expressing intent, constraints, solutions, and acceptance criteria before implementation. As agents become faster at writing code, the cost shifts to accurately specifying these elements. Spec Kit treats specifications as continuously updated facts rather than static documents.

Spec solves the “express intent” problem, while team memory solves the “inherit verified state” problem. Together they enable tasks to move from a temporary conversation to a structured, checkable artifact.

TencentDB Agent Memory Core Structure

The system defines team memory as the transformation of background, knowledge, code relationships, and work methods generated during real tasks into searchable, composable, traceable, authorized, and continuously updatable agent assets.

Four asset types are defined:

Chat Memory : background, constraints, decisions, preferences, and historical interactions.

Wiki : product knowledge, architecture design, standards, runbooks, and historical conclusions.

CodeGraph : symbols, files, call graphs, dependencies, and impact paths.

Skill : repeatable methods, tool invocations, boundaries, and verification rules.

These assets are not parallel documents; a single task may draw from all four to answer “what happened, what the team knows, how code is related, and how we usually act.”

Asset Lifecycle: From Evidence to Strong Assets

Memory creation follows four steps:

Evidence slicing : split sessions, documents, and repository content into locatable tasks, turns, pages, symbols, and commits.

Candidate extraction : identify background, decisions, rules, code relations, execution steps, error paths, and verification results, forming candidate atoms or skills.

Scope binding : attach owner, team, repo, branch, path, version, time, ACL, and source evidence.

Post‑validation upgrade : unverified traces remain low‑weight background; verified items (tests, reviews, commits) are promoted to stable scenario memory or shared skills.

After a task ends, new background, judgments, code relations, and validation feedback become candidate assets that are reviewed and fed back into the Memory Hub, creating a “once‑only‑error” loop.

Cold‑Start Strategy

To avoid waiting years for assets to accumulate, the system ingests historical sessions into Chat Memory, existing documentation into Wiki, and repository data into CodeGraph, then continuously augments them with new task evidence.

Internal Data Exploration (2,600 Sessions → 5,081 Tasks)

Analysis shows that 32.36% of tasks contain at least one “bottleneck” (card‑point). The authors generate 48,114 candidate relations, filter to 22,361 canonical relations, and finally isolate 231 strong relations (same work item, same problem, reusable SOP) while the rest become background references.

Key insight: logical rework (1,350 instances) far exceeds missing context (269), indicating that memory must store decisions and failure paths, not just raw data.

Redis Real‑World Case Study

Seven engineers were interviewed; common pain points were design and review time, loss of context across sessions, and the need for transparent asset provenance. The authors built a retrieval environment using 5,081 historical tasks and 35 real Redis TAPD test tasks. From 12,574 candidate pairs, only 57 final pairs remained, classified as 32 strong, 10 weak, and 15 background references.

Findings emphasize fine‑grained scope (repo, branch, path, tenant), separation of strong vs. background relations, prevention of future‑information leakage, and the necessity of evidence‑backed conclusions.

Evaluation on SWE‑bench

Two experiments were conducted:

Standard SWE‑bench (2,294 tasks, 500 verified) showed task completion rise from 60% to 80% after adding team memory (a 20‑point, 33.3% relative gain).

Ultra‑long 50‑task session: success rate improved from 17% to 20% and total cost dropped from $887.64 to $717.78, a 19% reduction in tool‑call turns.

These results confirm that pre‑task experience assets can materially improve downstream task performance, aligning with recent research on Agent Workflow Memory.

Design Principles Derived from Data

Memory’s purpose is inheritance, not archival.

Asset value is measured by reduction of uncertainty in the next task.

Both abstraction and raw evidence must be retained.

Assets should be atomic, composable, and assembled per‑task.

Assets require a full lifecycle (create, review, merge, deprecate, delete).

Memory must be decoupled from any specific model or agent framework.

Engineering Challenges in Multi‑Person Environments

Conflict handling across branches and environments.

Freshness management as APIs and policies evolve.

Permission enforcement following zero‑trust principles.

Provenance tracking for auditability.

Negative‑feedback loops to downgrade or retire bad assets.

Cost‑aware retrieval balancing token budget, latency, and privacy.

Conclusion

By turning error‑centric context into inheritable assets, TencentDB Agent Memory expands effective collaboration bandwidth, enabling “once‑only‑error” outcomes. The system demonstrates measurable gains on benchmark suites and real‑world Redis tasks, while highlighting the need for rigorous governance, versioning, and lifecycle management to keep team memory trustworthy and useful.