Nine Voices from Tencent: How Can Agents Keep Evolving?

“Getting an agent into production is easy. Building a mechanism that automatically keeps improving it is difficult.” —A searching question from a Tencent employee

A few days ago, I read an article collecting nine Tencent employees’ views on how agents can continually improve themselves. After finishing it, I sat still for a while. Several observations precisely captured things I had sensed while using AI tools but had not yet articulated.

Our industry faces an awkward reality: everybody is building agents, but almost nobody can clearly explain how to make them improve with use. The first version works, the demo impresses, and the boss approves. Then what? Three months after launch, the agent repeats the same mistakes, users repeat the same corrections, and every conversation feels like a trainee’s first day. The same traps, over and over.

This article is more than a retelling. I want to expand, connect, and supplement those nine perspectives with my own experience using tools such as Claude Code, to answer one question: what kind of system does agent evolution require?

1. Measure Before You Optimize

The first contributor says something that sounds obvious but underpins the entire discussion:

The essential step is to establish an evaluation system for your business. For the tasks your agent repeatedly performs, how should you judge each result? Only after defining quantitative metrics can you discuss optimization.

Why does this matter? I have seen too many teams begin “agent optimization” by changing a prompt. One version feels better, the next feels worse, and after three days nobody can tell whether anything improved.

It is similar to programming. You would not refactor a core module without tests. TDD starts with tests before implementation. Agent optimization should likewise begin with evaluation, then move to optimization strategies.

What should we measure? At least these four dimensions:

Metric	Meaning	Why it matters
Task completion rate	Proportion of tasks completed successfully without human intervention	The most basic measure of capability
Token efficiency	Tokens consumed to complete the same task	Lower consumption can indicate better context management
Human intervention frequency	How often users must correct, supplement, or retry	A direct reflection of reliability
Error recovery rate	Proportion of mistakes the agent fixes independently	A key measure of improvement through use

Without these numbers, “optimization” is like feeling an elephant in the dark. You do not even know what you are improving.

2. Temporary Workers and Permanent Employees: Two Memory Strategies

The same contributor offers an even more interesting distinction:

If AI is a temporary worker doing one-off jobs, such as a coding assistant, skills and rules are suitable. If it is a long-term worker expected to grow, it also needs a memory module.

The analogy is excellent.

In temporary-worker mode, the worker finishes a job and leaves, then starts from scratch next time. You supply a detailed operating manual—skills and rules—and ask it to follow it. Claude Code’s CLAUDE.md is a typical manual; we discussed it in detail in the previous article. Each time Claude makes a mistake, you add a rule. Over time, the manual improves, and so does the agent’s performance. Fundamentally, though, the agent has not grown more intelligent on its own; its instructions have improved.

Permanent-employee mode is different. You need the agent to remember last week’s mistakes, last month’s lessons, and this project’s preferences. That requires memory: short-term memory for the current task’s context, and long-term memory for knowledge across sessions.

The choice depends on your use case:

Frequent repetitive tasks, such as code review or test generation: skills and rules may suffice. Write a good manual.
Long-term companion scenarios, such as personal assistance or project management: memory is necessary for growth.
Mixed scenarios, which describe most real situations: combine a reliable manual with memory.

My impression is that most people remain at the temporary-worker stage. However good CLAUDE.md becomes, it is still a better manual. The real opportunity is letting the agent accumulate experience like a long-term colleague.

3. Failure Can Be More Valuable than Success

Contributors two, three, and five approach the same point from different angles. Together, they offer a deep insight:

Good data is not necessarily entirely correct data. Often, the most valuable data contains a problem and its correction.

That sounds counterintuitive. Surely AI should learn from high-quality, correct examples? But consider how people learn.

Remember preparing for university entrance exams? After a test, teachers asked you to keep a notebook of mistakes. The goal was not to repeat everything you had answered correctly, but to revisit and practice your errors. Mistakes reveal gaps in knowledge, precisely where there is most room to improve.

Agents are similar. A hundred successfully completed tasks have value, but limited value: they show the agent is already good at that class of task. The especially valuable records are failure plus correction: what went wrong, how the user corrected it, and what the correct approach ultimately was. This is fuel for improvement.

That is the data flywheel:

Agent performs a task → makes a mistake → user corrects it
    → record the “mistake + correction” pair
    → feed it back to the agent/model
    → avoid the same trap next time
    → encounter new mistakes → repeat

The second contributor puts it plainly: otherwise, every task feels like the first day on the job, with the same mistakes repeated forever. Every agent builder should pin that sentence above their desk.

There is a harsh reality, however, noted by the third contributor: many agents are abandoned before their data flywheel starts turning. Usage is infrequent and user patience is limited. The agent is rejected before it collects enough corrective examples. It is a chicken-and-egg problem: agents need mistakes to improve, but users may not give them room to make mistakes.

4. Human in the Loop: The Wisdom of a Safety Driver

Contributors three and six both mention human-in-the-loop systems. The third provides an especially good analogy: the safety driver in an autonomous vehicle.

When using Claude Code, selecting an option, cancelling with Escape, or adding corrective instructions is a human contribution to correcting the agent’s data, similar to an autonomous-driving safety operator.

A safety driver usually lets the vehicle drive but continuously watches the road. When the system is about to make a dangerous decision, the driver intervenes, takes the wheel, brakes, or corrects the route. Every intervention can become valuable training data.

We play a similar role with Claude Code. Consider ordinary interactions:

Explicit feedback: confirming or cancelling an action—equivalent to “this step is fine” or “stop, that is wrong.”
Implicit feedback: reading the agent’s suggestion and then editing it manually—quietly taking the wheel.
Corrective data: cancelling and supplying revised instructions—taking over and driving to the right position.

These signals increase in value. Explicit feedback indicates right or wrong. Implicit feedback suggests what was inadequate. A correction directly demonstrates the better approach.

There is a lovely paradox: more intervention now can mean less intervention later. Each correction can make the agent more reliable, provided the intervention is recorded and fed back into the system. Without that mechanism, you are a safety driver whose experience nobody ever listens to.

5. A Frozen Brain and a Changing Context

The fifth contributor uses a precise mathematical analogy to explain where LLM knowledge comes from:

Roughly speaking, the model matrix and context vector ultimately interact through multiplication. The model is the frozen part; the context is the changing part.

In plain language, a large model has two “brains”: fixed parameters and temporary context. Everything you put into a ChatGPT conversation is part of that temporary brain. The billions of parameters are the fixed brain, frozen once training ends.

This suggests two paths for continued agent improvement.

Path one: make the fixed brain adaptable—model plasticity.

Let the model itself continue learning. This is the domain of online and continual learning, with a very high technical barrier. In this discussion, it is territory primarily explored by major companies and leading laboratories, rather than ordinary application developers.

Path two: use the temporary brain well—context engineering.

If you cannot change model parameters, improve the context. Better prompts, smarter memory management, and more precise retrieval can make the temporary knowledge supplied for each conversation more useful.

The contributor suggests leaving the first route to model-training specialists and exploring the enormous room for innovation in the second.

I agree. For most of us, context engineering is the practical route. We do not need to train a new model. We need to place the most valuable information inside a limited context window:

Relevant task history: mistakes made on similar tasks before.
User preferences and habits: preferred code style and level of explanation.
Precise fragments of domain knowledge: the few paragraphs needed now, rather than an entire manual.

A context window is a workbench with limited space. You cannot move the entire warehouse onto it. Put only the tools and materials needed right now on the bench.

6. Teach the Agent to Reflect

The fourth contributor’s suggestion is brief: “Look into reinforcement learning!” The sixth takes the idea in a direction that excites me: metacognition.

Design agents using metacognition and ontology: an ontological knowledge base helps the agent understand the world, while metacognition helps it think about and improve its own thinking.

The term sounds academic, but the idea is simple: thinking about how you think.

People improve not merely because they act, but because they reflect. After writing code, you look back: Was that good? Is there a better approach? Did I repeat the previous mistake? That self-examination is metacognition.

Reinforcement learning provides a mechanism for adjusting behavior through rewards and penalties. On its own, it teaches which actions earn rewards, rather than explaining why an action is good. Add reflection, and the agent can also analyze why it went wrong.

Imagine an ideal reflective process:

1. Perform the task and obtain a result.
2. Evaluate it: “Is this good? What could be better?”
3. Analyze causes: “Where did it fail? Wrong intent or wrong tool?”
4. Adjust strategy: “Next time, confirm intent before acting.”
5. Store the lesson in memory.

Does that not resemble a learner capable of examining itself? Whenever I think about this, I get a strange feeling: are we discussing software engineering or cognitive science?

7. Use AI to Improve AI: An Evolving System Prompt

The seventh contributor offers a practical approach: use an AI model to improve the system message incrementally.

We know how strongly a system prompt affects behavior. A carefully designed one and a casually written one may produce vastly different outcomes. But how do you determine whether yours is good, and how do you improve it systematically?

The proposed answer is direct: let AI help do that work.

Another detail matters: structured XML rules are preferable to an improvised string.

<!-- A structured system prompt -->
<rules>
  <rule name="error_handling" priority="high">
    If page loading times out, capture the current state first.
    Then wait three seconds and retry, at most twice.
  </rule>
  <rule name="form_filling" priority="medium">
    Before filling a form, check that all required fields have been located.
    Log any missing fields and skip them.
  </rule>
</rules>

<!-- An underspecified system prompt -->
“You are a browser automation assistant. Fill in forms and retry errors.”

Structure makes each rule’s boundaries, priority, and conditions clearer. With an improvised string, the model has more to infer.

An automated improvement loop could look like this:

Run the agent → collect execution data and error logs
    → measure completion rate, error rate, and other metrics
    → give another AI the data to diagnose and propose prompt changes
    → A/B test the old and new prompts
    → deploy the better version → repeat

This is AI improving AI. Humans need not rewrite every prompt themselves; they can review whether the proposed changes make sense.

8. Test-Driven Agent Evolution

The eighth contributor offers the most systematic proposal: a multi-agent testing pipeline.

Introduce another multi-agent system for evaluating the AI product. A Spec Agent judges result quality and correctness. If a test fails, it analyzes the cause and assigns work to a Coding SubAgent. The subagent reviews the failure, improves the system prompt, and submits a pull request for human review.

The pipeline becomes:

Spec Agent, the judge → evaluate whether output meets requirements
    ↓ failure
Root-cause agent → diagnose the problem and assess confidence
    ↓ high confidence
Coding SubAgent → modify the prompt, code, or configuration
    ↓
Pull request → human review
    ↓ approved
Merge and deploy → next evaluation cycle

Several aspects are especially smart:

Agents testing agents. LLM-as-judge is not new, but embedding it systematically into iteration is a crucial step.
Confidence thresholds. Not every error triggers an automatic repair. Only high-confidence diagnoses proceed, reducing the risk of incorrect changes making things worse.
Humans as gatekeepers. People no longer need to manually investigate every failure or edit every prompt. They review the PR and decide whether to merge it.

The contributor closes with a thought that resonates with me: in an AI-era test-driven workflow, people may shift almost entirely from executors to gatekeepers and judges.

This does not feel distant. In my own Claude Code use, I increasingly act as a reviewer. The agent writes code while I evaluate it; the agent debugs while I judge whether the diagnosis is right.

Final Thoughts

Taken together, the nine perspectives describe a complete system, rather than one clever trick. A diagram might summarize it like this:

Evaluation    ← Quantify before optimizing
    ↓
Feedback      ← Mistake + correction = fuel for improvement
    ↓
Memory        ← Temporary worker or long-term colleague?
    ↓
Reflection    ← Think about the thinking
    ↓
Iteration     ← Use AI to improve AI

Evaluation → feedback → memory → reflection → iteration. Each part matters, forming a loop that can reinforce itself over time.

My strongest impression is how similar this is to human learning. We grow through mistakes, improve through reflection, accumulate knowledge through memory, and measure progress through tests. The difference is that our learning systems emerged over millions of years, while agents’ systems must be deliberately designed.

We are both agent users and designers of the systems through which agents improve. It is a strange role: teaching something to teach itself.

Original discussion: How Tencent employees think about agents’ continuous self-improvement