ByteDance's TRAE Work competes with Tencent's WorkBuddy in the office agent space. Major tech companies have recently completed their deployment of desktop office agents: Alibaba has launched Qwen Office, Tencent is primarily promoting WorkBuddy, Baidu has launched DuMate, and ByteDance offers Doubao Office and TRAE Work. Product strategies fall into two categories: proprietary models and aggregated models—Qwen Office and Doubao Office rely on proprietary models, while TRAE Work and WorkBuddy adopt a multi-model aggregation approach. As agents take on more tasks, routing has become critical; balancing task performance against computational costs will determine product competitiveness. Office agents may emerge as a new distribution channel for models, shifting model competition from user-driven selection to routing system selection.Article author and source: Wall Street Journal
The business competition among office agents is unfolding in a rather straightforward manner.
Recently, Wall Street Morning · All-Weather Technology discovered that TRAE Work, a subsidiary of ByteDance, began placing advertisements in elevators within a residential complex in Chaoyang District, Beijing.
For complex tasks, use TRAE Work. A QR code is provided next to the ad; new users can scan it to receive 4,500 points.
Just recently, another ad screen in this elevator displayed Tencent WorkBuddy.
This is precisely a testament to the recent intensification of competition among office agents.
Over the past few months, major tech companies have largely completed their deployment of desktop office agents. Alibaba launched Qwen Office, Tencent primarily promoted WorkBuddy, and Baidu rolled out DuMate; ByteDance offers both DouBao Office, which is further integrating with Feishu, and TRAE Work, which is expanding into general office scenarios.
The targets of several products are becoming increasingly similar, but their paths still differ significantly at the model level.
Qwen Office is anchored by its own model system, while DouBao Office is similarly supported by ByteDance’s proprietary models and Feishu workflows; TRAE Work and WorkBuddy emphasize multi-model aggregation, aiming to consolidate the capabilities of different models into a single desktop workspace.
The self-developed model approach still requires continuous improvement through training—the stronger the model, the higher the task complexity the Agent can handle. The aggregation approach, on the other hand, faces a different challenge: when multiple models are available, which one should be used when?
These questions currently have no standard answers.
The Hidden Battle in the Elevator
Over the past few months, competition among major tech companies around office agents has primarily occurred at the level of product launches and organizational restructuring.
Among these, ByteDance's adjustments to Doubao, Feishu, and VolcEngine at the end of July attracted particular attention.
Previously, Feishu operated as an independent business unit under ByteDance, with its head, Xie Xin, reporting directly to ByteDance’s CEO, Liang Ruobo. Following this adjustment, the Feishu product team has been integrated with the Doubao product team, and Xie Xin now reports to Zhao Qi, head of Doubao; the Feishu GTM team has also been further integrated with relevant teams from Volcano Engine.
This adjustment has also drawn attention because Feishu's own business performance is not weak.
Under these circumstances, Feishu’s product and sales systems were once again restructured and recombined, making ByteDance’s intent to reallocate resources around AI-powered office solutions even clearer.
After the adjustments, DouBao Enterprise, developed with deep involvement from the Feishu team, has begun internal testing with select Feishu customers. Feishu’s existing office capabilities—including documents, spreadsheets, meetings, and group chats—have become the foundation for DouBao’s further integration into enterprise workflows.
For a time, DouBao Office became the focal point for outsiders observing ByteDance’s next steps in AI-powered office solutions. However, the first to directly compete with WorkBuddy was TRAE Work.
In an elevator of a residential complex in Chaoyang District, Beijing, advertisements for TRAE Work can already be seen.
Photo source: Taken in Chaoyang District, Beijing
Not long ago, the other advertising screen in the same elevator displayed Tencent WorkBuddy. Now, the WorkBuddy ad has been removed, and TRAE Work has appeared on another screen nearby.
Image source: Internet
This elevator encounter also brought another internal office agent initiative at ByteDance back into focus.
TRAE initially entered the market with an AI-powered programming tool. In June this year, TRAE SOLO was officially upgraded to TRAE Work, expanding its scope beyond code generation to include general office scenarios such as research, writing, data analysis, solution planning, and cross-team collaboration.
From SOLO to Work, TRAE aims to encompass more than just programming tasks—this product lineup is being expanded to serve a broader office workforce.
TRAE’s expansion into general office productivity is not starting from scratch. According to Analysys, in June this year, the desktop version of WorkBuddy reached 20.97 million monthly visits; during the same period, the domestic version of TRAE IDE reached 12.79 million monthly visits, ranking second. Since the June upgrade, TRAE Work has already achieved account integration and project resource sharing with TRAE IDE.
Doubao Office received the majority of attention from ByteDance’s recent organizational restructuring, but TRAE Work was actually the first to compete for users offline against WorkBuddy.
TRAE Work is facing increased competitive pressure.
Externally, TRAE Work competes with WorkBuddy for users; internally, it must also address how it coexists with DouBao Office.
Subtle boundaries within the model pool
Looking further into the model layer, another divergence in competition has emerged among office agents.
One approach is to bet on proprietary models.
Qwen Office currently positions the Qwen model as its core capability. Alibaba officially defines it as "based on the Qwen series of large models," and the model selector currently offers different tiers, including Basic, Advanced, Economy, and Qwen3.8-Max.
Doubao Office also relies on ByteDance's proprietary Seed model.
For this type of product, the continuous training and iteration of the model still directly determine the upper limit of the Agent's capabilities.
TRAE Work and WorkBuddy take a different path: the multi-model aggregation approach.
WorkBuddy supports switching between multiple models, including HunYuan, GLM, MiniMax, Kimi, and DeepSeek, and offers an Auto mode that automatically selects the appropriate model based on the task. TRAE Work also comes with a variety of built-in models and provides an Auto mode.
Even if both products choose the aggregation route, the cards they currently hold are not entirely the same.
From the current model options available in the product, WorkBuddy’s default model pool does not include Alibaba’s Qwen or ByteDance’s Seed; in TRAE Work’s visible model selections, Tencent’s HunYuan is not available, but Qwen version 3.7 is pre-installed.
This difference is not yet sufficient to indicate that fixed camps have formed among large model providers; models like Seed can also access third-party agents via API.
The boundary of the model pool reveals the competitive tension between Tencent and ByteDance: on one hand, WorkBuddy and TRAE Work aim to integrate more models to position themselves as universal work platforms; on the other hand, Tencent and ByteDance each possess HunYuan and Seed, and their own foundational models are also vying for usage volume and user adoption.
This also raises a new question: as office agents take on an increasing number of real-world tasks, could they become a new distribution channel for models? Could the battle over desktop entry points further evolve into a competition over model invocation volumes?
Is routing the next challenge?
When an agent holds multiple models simultaneously, scheduling becomes an unavoidable issue in aggregation pathways.
First and foremost, model capabilities are further diverging.
As models continue to iterate, each model's strengths in code generation, complex reasoning, long-text handling, search capability, response speed, and invocation cost are becoming increasingly pronounced.
This disparity is further amplified in Agent scenarios. A complex task often requires dozens of consecutive model calls, and the choice of model at each stage directly impacts task completion effectiveness, time consumption, and cost.
Although routing is hidden in the background, its impact on user experience is becoming increasingly direct.
Ideally, users only need to submit a task, and the backend automatically selects the appropriate model: simpler information extraction tasks are handled by faster, lower-cost models, while more complex reasoning and coding tasks trigger stronger models.
For individual users, this ultimately translates to waiting time and point consumption; in enterprise scenarios, it further becomes computing power costs.
Finding the balance between task performance and computational cost becomes the most direct user value of routing.
If aggregator agents like WorkBuddy and TRAE Work eventually accumulate a sufficient number of users, routing could generate another value: a data flywheel.
Each real task generates feedback on model performance: which tasks are more successfully handled by which models, how long they take, how many tokens they consume, and under what circumstances they are likely to fail.
Subject to privacy, authorization, and data governance requirements, this feedback can be used to optimize routing strategies.
At the same time, this may also alter the relationship between model providers and Agent platforms.
In the past, large model providers competed more for users and developers to actively invoke their models. As more tasks are handled by agents, users may gradually delegate model selection to the backend.
For model providers, entering the routing layer means accessing more real-world tasks. If a model develops a clear advantage in specific tasks such as coding, search, or reasoning, it may receive more requests.
Competition between models may also extend from competing for user choice to competing for selection by routing systems.
Users need to manage model selection and computational costs, while model providers seek to reach more real-world tasks through this layer—placing the routing layer at the intersection of model supply and user demand.
Capital markets have also begun to recognize the value of aggregation platforms. In May this year, OpenRouter, the world's largest model aggregation platform, completed a $113 million Series B round, reaching a post-money valuation of $1.3 billion.
However, whether this set of business value can truly be realized depends on whether the routing can be sufficiently accurate.
Currently, the industry has not reached a unified answer. Explorations by different research teams within Tencent have already demonstrated this divergence.
Tencent HunYuan and researchers from the University of Chinese Academy of Sciences proposed DecoR, which focuses on individual requests by breaking down the query into capability requirements such as skills, knowledge, and difficulty, then selecting a more suitable model based on historical performance.
Another study by the Tencent WeChat team and Shanghai Jiao Tong University extended the time horizon, suggesting that a model performing better at a single step may not yield the optimal outcome for the entire task, and switching models can impact cache reuse and cumulative costs.
One focuses on "Who should this request be assigned to?", while the other begins to consider "What final outcome will a sequence of model selections produce?"
There is still no standard answer to when exactly the model should be switched or how often it should be changed.
However, for aggregated agents, business problems are already quite specific. Whoever can more accurately assign real tasks to the appropriate models while reducing computational costs will have a greater chance of turning multi-model capabilities into a true product feature.
