The AI products of Tencent, Alibaba and ByteDance are integrated, and the rearrangement of the three-plane architecture is launched.

On October 29, in Shenzhen, at the Tencent Global Digital Ecosystem Summit, Senior Executive Vice President Dowson Tong launched a new office suite named Buddy One. Built on WorkBuddy as the workbench, it integrates Tencent Docs, Tencent Meeting and the IMA knowledge base, enabling AI to access the user's authorized materials.

This means that documents, meetings and knowledge bases are no longer three separate products that compete to attract users on their own, but three tools in the same AI-driven workflow. Long before the unification of these products, the organization had already laid the groundwork for this transformation.

In June this year, Dowson Tong mentioned in a public dialogue that an internal WorkBuddy organization document he reviewed wrote the following: teams of 3 to 5 people are formed to conduct experiments around specific fields. Earlier, on March 31, Tencent Cloud sent an internal letter announcing the establishment of the 6th Cloud Product Department, which is responsible for building AI-native code (CodeBuddy) and general productivity agents (WorkBuddy).

Many large tech companies have taken similar moves. In June, Alibaba merged the Wukong and MuleRun teams; at the end of July, ByteDance combined the Feishu product team and the Doubao product team. Kuaishou went even further — it set up a cross-business unit virtual organization called "Enterprise AI Productivity". Note that it is a virtual organization, not a new department.

Everyone is discussing which products have been merged. What I care about is another thing: the three-tier architecture has been rearranged.

01   Front End — From "Departments" to "Small Teams"

Let's start with the "teams of 3 to 5 people". In a pyramid-style organization, the adoption of AI by one department involves extremely complex decision-making processes, which requires budget approval, multiple reviews, and alignment with numerous other departments. But an individual employee can start using AI as early as this afternoon.

This asymmetry determines that AI always penetrates individuals first rather than the entire organization. The only way to break this situation is to split the organization into smaller units, as small as a single cell or a special operations team. This is the front-end form I described in *The Agent Organization*: infinitely splitting entrepreneurial special operations teams. Its extreme form is an independent accounting business unit composed of "1 natural person + n dedicated agents", similar to a micro-company that directly faces the external market and assumes full responsibility for its own profits and losses.

Please note what this means. A single person can configure multiple agents such as sales assistant, data analyst, customer service, and contract reviewer to help them handle multiple clients and multiple projects at the same time. Individual productivity will be upgraded from "8 hours a day" to "7×24 hours parallel processing". This is not a 20% improvement in efficiency, but a leap in productivity by orders of magnitude.

02   Middle Platform — From "Bureaucracy" to "Factory"

Now let's talk about the virtual organization at Kuaishou. Why does it span different business units? Why is it "virtual"? Because this is exactly the deadlock of the traditional middle platform. The original intention of the middle platform is to share resources, but in reality it often gets stuck: it is neither a front-end unit that can directly deliver services to customers, nor a back-end unit that can set underlying rules. Caught in the middle, it only provides semi-finished products that the front end cannot assess, and undertakes KPI set by the back end, so it is inevitable to move towards bureaucratization. The result is that the larger the middle platform is built, the more constrained the front end will feel in use.

After AI is introduced, the logic of the middle platform changes: it no longer outputs "personnel", but "capabilities". All assets, data, algorithms and compliance capabilities are encapsulated into standardized APIs; the middle platform does not command the front end, but only exists as a "public service market". The front end calls services on demand and pays per use.

In *The Agent Organization*, I cited an example of a retail company. The sales forecasting algorithm is encapsulated into an API that every category unit on the front end can call. By entering the category ID, date range and promotion plan, the system will return the forecasted sales volume. The number of calls and consumed Tokens are automatically recorded, and fees are deducted from the virtual account at the end of the month. In this way, the middle platform transforms from a "department that asks for budget" to a "supplier that provides quotations". This step is the watershed between platform-based organizations and "departments + AI".

03   Back End — From "Setting Game Rules" to "Building Resource Pool"

The establishment of the 6th Cloud Product Department at Tencent Cloud may indicate some directions for the evolution of the back end. Look at the three things it does: building AI-native coding capabilities, building general productivity agents, and advancing commercialization. None of the three things directly generate customer experience, but all three determine how fast the front end can run. This is the positioning of the back end in the agent organization — building the stage, not performing on it.

Why is the back end more likely to be mired in bureaucracy? Because its output cannot be priced or verified. In the three-tier architecture, Musheng Consulting simply summarizes the functions of the back end as "building resource pools" and "setting game rules", but they often prefer the latter, positioning themselves as "rule makers and maintainers". The reason is simple: this positioning can increase their power, make their value more difficult to assess, and hide in a comfortable "black box".

Once the output of the back end is encapsulated into APIs, even the "game rules" are written into agents, clearly priced, and voted on by the front end with their choices, the "black box" is opened, and the back end has to prove its own value. There is a dividing line here — in the past, the middle and back end liked to say "how bad things would be without us"; now, they have to speak with their contributions, and must prove "how good things can be with us".

04   Between the Three Tiers — Connected by Market Prices

After the rearrangement of the three tiers is completed, the last question will definitely come up — how do they settle accounts with each other?

If services, computing power, data interfaces, and model calls are all clearly priced, and the front end purchases them on demand with internal currency, employees will naturally do the math — is it cheaper to use more AI or hire more people? Which AI is more cost-effective? This step will quickly eliminate inefficient middle and back-end units. Valuable services will be paid for and retained; services with insufficient value will not be selected, and can only cut prices, improve, or be replaced by external suppliers.

What is used for settlement? Token.

It supports atomic, high-frequency micro-settlement. The value of a single transaction is extremely low, and one API call may only cost 0.001 yuan; the frequency is extremely high, reaching tens of thousands of times per second. Fiat currency is indivisible and must be traded through statutory institutions, so it cannot handle this level of granularity. Tokens recorded on the ledger can achieve millisecond-level settlement at near-zero cost. It can also be combined with smart contracts to realize "condition-triggered automatic payment": the payment is automatically transferred once the report is successfully delivered, and automatically refunded if the quality fails to meet the standard. When employees need to withdraw cash, the tokens can be converted into currency according to the agreed exchange ratio.

But one thing must be stated in advance. Points or chips are never equal to currency, they are only incentive measurement units within the enterprise. Once monetized or quasi-monetized, it will touch the red line of violating laws and regulations. If this boundary cannot be held, all the previous designs will only cause trouble for the company itself.

As for the incentive itself, I designed three market-oriented forms in my book, which is known in the industry as the "Incentive Sandwich".

Transaction Mode — The incentive amount equals the unit price multiplied by the usage volume. The buyer bears the effect risk, which is suitable for middle and back-end units that provide standardized services, APIs, computing power and data.

Mezzanine Mode — The incentive amount equals the discounted price plus the performance sharing. The two parties share the risk, which is suitable for middle and back-end units that provide non-standardized services.

Co-investment and Performance Bet — The incentive amount equals the commission rate multiplied by the excess profit amount. The co-investor bears the main risk, which is suitable for business units and BPs entering the business units; plus an additional layer of overall company co-investment and performance bet, covering the senior management team and public service departments of the middle and back end.

The subtlety of this design is: it finally makes "hiding in the middle and back end" a very costly thing.

05   Beyond Large Enterprises — How to Take Action?

Most enterprises do not have the scale of Tencent, ByteDance or Alibaba, and do not need to complete the three-tier rearrangement all at once. But there are three things that can be done as early as this year.

First, find your "3 to 5 people" team first.

Instead of simply dividing departments into smaller ones, re-divide units based on "operation units" that undertake tasks. Which tasks can be completed in a closed loop by one natural person and several agents? Mark these tasks out, grant authorization, implement independent accounting, and give a certain share of profits when conditions permit to build pilot projects.

Second, give your middle and back end (functional departments) a quotation, and define their scale according to actual demand.

Pick one of the most mature capabilities — data analysis, material production, customer service knowledge base, etc. — encapsulate it as an internal API, mark the price, measure usage and deduct fees. Then, promote the "pricing" of various functions of the middle and back end in turn. Functions that cannot be priced are most likely redundant. Usually, one month after pricing, you will see the real distribution of internal demand, which is the exact scale that your middle and back-end functional departments should have.

Third, don't rush to modify the organizational chart, sort out the core "workflow" first.

The three-tier architecture is not a diagram, but a set of pricing relationships that ultimately point to customers. Don't flip the pyramid upside down, don't rename departments, the diagram and names can remain unchanged for the time being. The key is to connect the "operation units" of human-machine collaboration, form a "workflow" pointing to customers, and sort out the pricing relationships of transaction, mezzanine and co-investment.

Once this step is taken, several "arteries" that transfuse blood from the market to the enterprise will be formed, and the organizational chart will change naturally; if this step is not taken, no matter how beautiful the diagram is, it is just an "enhanced version of the pyramid (Hierarchy Pro)".

Therefore, when I judge whether an organization has truly transformed, I never look at what new concepts it has shouted, how many layers of structure it has drawn, or how many committees it has set up. I only look at one thing: whether the first real "market-oriented transaction" has ever occurred within this organization. If it has never happened, all its marketization, platformization and agility are just publicity slogans.

This article is from the WeChat Official Account "Musheng Firm" (ID: hrm-yun), author: Mu Sheng, published with authorization from 36Kr.