How a small, underfunded coding-tools team inside Tencent Cloud built China's most-used efficiency agent — and what their operating model tells us about the future of work design.
When Tencent launched WorkBuddy on 9 March 2026, the story the market told was a product story. Servers buckled within hours of going live; the team had to expand capacity roughly tenfold inside the first 24 hours. Six weeks later, Pony Ma told investors on Tencent's Q1 earnings call that WorkBuddy was "the most widely used efficiency AI Agent service in China" — and mentioned it three separate times. By July, reporting put it above 20 million monthly users and first in daily actives among Chinese productivity agents.
The commentary that followed focused on timing: Tencent caught the desktop-agent wave. That's true, and it's also the least interesting thing about this case.
Here is the detail that should stop any organizational leader mid-scroll: the team that did this was about ten people. In 2023 they were a small AI code-completion squad inside Tencent Cloud with no commercial traction, unremarkable models, and a real question mark over whether they'd survive the next planning cycle. Their product lead, Wang Shengjie (汪晟杰), later described that period in startup terms — "we basically survived; roughly a pre-A round."
Three years later, that same group is running one of Tencent's fastest-scaling products in company history.
They did not get there by running better Scrum. They got there by rebuilding how work itself is organized. What follows is the case — first what actually happened, then the operating model I read out of it, and finally what does not transfer.
Part 1: What Actually Happened
2023 — the survival years. A roughly ten-person team inside Tencent Cloud builds an AI code-completion assistant. No breakout, no budget halo. To win their first serious customer, the product lead moves into China Merchants Bank's data centre for nearly three weeks — running meetings, deploying, collecting feedback, shipping new versions on site. The contract closes at the end of 2024. Xiaomi and Honor follow through the same on-site playbook.
That deployment matters more than it looks. Three weeks inside a bank's data centre is where you learn what enterprise permission boundaries, security sandboxes and context limits actually mean — knowledge that later became the substrate WorkBuddy was built on.
2025 — building the floor. The team ships CodeBuddy, then upgrades it to CodeBuddy IDE, where a user can move from a spoken requirement to a PRD, to generated UI, to deployed code inside one tool. In the second half of the year they build out the underlying agent architecture and open platform — execution infrastructure first, ecosystem second.
January 2026 — the weekend. After Anthropic's Claude Cowork lands, Wang Shengjie and one operations colleague build WorkBuddy 0.01 over a single weekend (17–18 January), on top of the existing CodeBuddy agent SDK — and largely using CodeBuddy to write it. There is no formal project approval process. He sends a video demo to his manager and gets the go-ahead the same night.
February–March 2026. Internal beta opens on 6 February. Before public launch, more than 2,000 non-technical Tencent employees are using it daily — HR, ops, admin, marketing. Public launch on 9 March overwhelms capacity within hours. Eight updates ship in the first month. First-month traffic hits 8.85 million visits, up 831% month-on-month, roughly 2.6× the second-place product.
April 2026 — the org catches up. WorkBuddy is spun out into an independent product department, grouped with ima and Tencent Docs. The team grows past 100 people. In its first three months it ships 43 versions and sees token consumption rise tenfold.
Note the sequence: the operating model came first, the org chart came second. Tencent restructured around a way of working that had already proven itself, rather than designing a structure and hoping performance followed. That inversion is the whole lesson.
Part 2: The Operating Model
Below is the model I read out of this case. Some of it is directly reported behaviour; some is my abstraction of what that behaviour implies. I've flagged which is which, because the difference matters if you're going to bet a reorganization on it.
For two decades, Agile frameworks organized software work around sprints, backlogs, functional handoffs and human-to-human coordination. Every one of those mechanisms exists to solve a single problem: humans are expensive to synchronize. When a large share of execution moves to agents that don't need standups, the mechanisms designed around that constraint stop earning their keep.
| Traditional Agile | AI-Native Operating Model | |
|---|---|---|
| Primary work unit | Sprints, user stories, backlog items | Problem domains with defined acceptance criteria |
| Team shape | Cross-functional teams inside functional silos | Very small human cores + agent fleets |
| Roles | Fixed (PM writes the PRD, dev writes the code) | Fluid (PMs ship prototypes, engineers shape product) |
| Coordination | Standups, grooming, handoff meetings | Machine-readable specs, tests, agent dispatch |
| Work rhythm | Business hours, sprint cadence | Humans and agents by day, agents alone overnight |
| Institutional memory | Tribal knowledge, wiki pages nobody reads | Committed context, reusable agent skills |
| Human attention goes to | Producing the work | Defining the work and adjudicating exceptions |
| Measured by | Velocity, story points, throughput | Completed end-to-end outcomes |
1. Fluid roles — the PM/engineer boundary dissolves
Reported. WorkBuddy's first working version was built by a product lead and an operations colleague, not an engineering pod. The team's own product tooling — CodeBuddy IDE — was explicitly designed to put "product manager, designer and programmer into the same tool."
The principle. AI lowers the execution barrier on both sides of the old handoff. Engineers stop spending their scarcest hours on syntax and start spending them on user journeys and product boundaries. Product managers stop shipping static wireframes and start shipping working prototypes. Each functional interface you remove removes a meeting, a translation loss and a queue.
The organizational consequence is bigger than the productivity gain: when one person can carry an idea from insight to running prototype, the unit of ownership becomes the problem, not the process step.
2. The day/night rhythm — a genuinely new work pattern
Reported. This is the most under-discussed detail in the entire case. Tencent Cloud agent PM Huang Guangmin (黄广民) describes the team's rhythm plainly: during the day, humans and AI work together; at night, AI works alone, with long-running tasks handed to agents to execute overnight. The team calls itself a 蜂群组织 — a "swarm organization": flat, self-directed, organized around the work rather than the hierarchy.
The principle. Traditional capacity planning assumes throughput is a function of headcount × hours. Once agents run unattended, throughput decouples from both. The scarce resource stops being execution capacity and becomes specification quality — how precisely you can define what "done and correct" means before you go home.
This is where most enterprise AI programmes quietly fail. They deploy copilots into an 8-hour human workday and measure a 20% speedup, when the actual prize is a work cycle that no longer stops.
3. Specification as the coordination mechanism
Reported. The team's development loop is unusually literal: code is essentially all written by CodeBuddy, every new requirement is run through the AI first, what passes gets merged and released, and humans investigate only what fails.
My abstraction — call it the task contract. That loop only functions if "passes" is machine-checkable. Which means the real work has moved upstream, into defining inputs, outputs, tool permissions and acceptance tests precisely enough that a machine can adjudicate them. Do that, and you can delete most status meetings, because a passing test is a more reliable status update than a person saying "on track."
Their own framing for what makes agents work is worth stealing: Huang Guangmin's formula is Agent = Model × Context × Loop — "most people never hit the model's ceiling; most people stumble on context and loop." Read organizationally, that is a diagnosis of nearly every stalled corporate AI pilot. Companies keep shopping for a better model when their actual deficits are context (the machine doesn't know how this company works) and loop (nothing closes, verifies and re-runs without a human).
4. Knowledge becomes an executable asset, not a document
Reported. Reusable agent "experts" in the product encapsulate role definition, workflow, delivery templates and capabilities; debugged workflows and knowledge are shared across the team. Skills are packaged, published and reused — the public skill marketplace saw roughly 30 million downloads in two months.
The principle. In a conventional organization, expertise is ephemeral: when your best operator leaves, their judgment leaves with them and the wiki page they wrote goes stale within a quarter. When a hard-won edge case is instead committed as an agent skill, a context file or an automated acceptance rule, it becomes infrastructure — versioned, executable, and available to everyone at once.
This is the compounding mechanism in the whole model. Three weeks inside a bank's data centre in 2023 is not a memory; it is encoded in how the product handles enterprise permissions in 2026.
5. Dogfooding closes the loop to zero
Reported. The prototype was built with their own agent SDK. The product is developed, documented and designed using their own agents. The internal claim is that the team can fully bootstrap agent development using its own tool.
The principle. When a team uses its own product to build its own product, the distance between noticing a problem and fixing it collapses. Efficiency gains don't just accrue — they compound into the next release. Forty-three versions in three months is not heroic effort; it's a structurally shorter loop.
6. Small human core, thick shared platform
My abstraction. The frontline stayed tiny because it never had to rebuild the floor: model orchestration, security sandboxes, enterprise compliance, connectors and agent SDKs were all inherited from years of CodeBuddy work. Small teams move fast only when someone else has already solved infrastructure. Without a thick platform, small teams drown in plumbing; without small teams, the platform group becomes the bottleneck it was built to remove.
The strategic read: a "thick platform" is the precondition for autonomy, not a reward for it. Most enterprises invert this — they push business units to become AI pioneers on their own, then wonder why every unit has built a different, unsafe, unmaintainable version of the same thing.
Part 3: What This Case Does Not Prove
A case study that only flatters its subject is marketing. Four honest caveats, because they determine whether any of this transfers to your organization.
It was expensive. Tencent's own Q1 2026 results show its new AI products — Hunyuan, Yuanbao, CodeBuddy, WorkBuddy and QClaw as a group — dragged operating profit by roughly RMB 8.8 billion; adjusted operating profit grew 9% including them versus 17% excluding them. Small teams, yes. Cheap, no. This model buys speed with compute, and someone is paying that bill.
Selection bias is real. This was a team of tool-builders building tools for themselves, in a domain where acceptance criteria are unusually machine-checkable. Code either compiles and passes tests, or it doesn't. If your work is regulated advice, clinical judgment, negotiation or care, "run it through the AI and investigate the failures" is not a loop you can safely close — and the specification burden rises sharply.
"Swarm organization" has a human cost. A rhythm where humans and agents work by day and agents run overnight is described admiringly in Chinese coverage — and the team is described, in their own words, as working "007." Speed of this kind is not free, and a leader importing the structure without examining the sustainability is importing burnout with a better vocabulary.
Survivorship. We're reading the operating model of the team that won. Plenty of small, flat, dogfooding, AI-first teams shipped fast and shipped nothing anyone wanted. Structure enabled this outcome; it did not cause it. Wang Shengjie's read on the desktop-agent shift — "we believed this was inevitable" — was a correct strategic bet, and no operating model substitutes for that.
The Blueprint for Leaders
If you're responsible for how your organization works — not just what it builds — four moves follow from this case:
- Move the value unit from tasks to outcomes. Stop measuring volume — tickets closed, documents produced, story points burned — and start measuring completed end-to-end deliverables owned by a small, named group. In an environment where output volume is nearly free, measuring volume actively misleads you.
- Build the platform before you demand the autonomy. Centralize model orchestration, security sandboxes, permission frameworks, connectors and shared context. Then let small teams move without asking permission. Autonomy without a platform is just distributed risk.
- Invest your best people upstream, in specification. The bottleneck is no longer execution; it's defining "done and correct" precisely enough for a machine to check. That is a genuine skill, it is scarce, and almost no organization currently trains, hires or promotes for it. This is the single highest-leverage capability gap I see in enterprises right now.
- Make knowledge capture mandatory and executable. Every post-mortem, client deployment and hard-won fix should end as a committed context file, an agent skill or an automated acceptance rule — not a slide deck. Individual experience that doesn't become organizational infrastructure is a liability disguised as expertise.
The competitive advantage of the AI era was never going to be access to a smarter chatbot. Everyone has that. The advantage belongs to organizations that redesign how human judgment, shared platform and autonomous execution fit together — and, critically, that redesign it before the org chart forces them to.
Ten people did this inside one of the largest technology companies on earth. The constraint was never headcount.
Over to you
So the question for your organization is simple: are you running the same operating model you ran in 2023, with AI bolted onto the side of it? Or have you started redesigning the model itself?
I'd genuinely like to hear where you're seeing this work — and where it's breaking. Tell me in the comments.
Sources: Tencent Cloud Developer Community; TMTPost; Wallstreetcn; Sina Finance; Tencent Q1 2026 earnings disclosures; TechNode; Tencent Cloud official product documentation.
