Manus co-founder Zhang Tao reviews the practice of transforming the organization with Agents

This is an article published on a WeChat official account by Manus co-founder Zhang Tao @hidecloud. The engineering value of Agents is extremely high, and I strongly recommend it to all AI developers.

WeChat official account: https://mp.weixin.qq.com/s/I_hNNAf7LFBf5nJ0rEJHig?scene=1

Manus ties "building Agent products" and "using Agents to transform the organization" together: engineers often throw the original Slack requirements directly at a row of Codex/Manus Sessions, with one person running a dozen or more requirements in parallel; the overhead shifts from "person-to-person alignment" to "supplying people with context, tools, and approval nodes." The article uses four threads—Manus-mono, product managers writing code and video PRDs, the marketing "digital colleague," and roughly $10,000 in AI spend per person—to explain: people are moving from Human in the loop to more of Human on the loop, setting rules, watching key nodes, and being accountable for results.

The opening scene

When pushing toward 2.0 in September, Zhang Tao would give engineers requirements/bugs, then go check on progress: on screen was a row of Sessions, with the input almost word-for-word the original Slack text. In the past, a person analyzed first and then wrote; now finding the relevant code and making changes is mostly done by AI, and people are more in command and accountable. One person simultaneously juggling a dozen or twenty requirements has become the norm, and Zhang Tao is both excited and uneasy: fast enough, or too fast? Are there invisible pitfalls?

Premise: An Agent company inevitably must "eat its own dog food" + explore the boundaries of usage; once human-machine collaboration is the default, how should the organization work? The following only writes up slices from three teams.

R&D: The biggest overhead used to be integration → Manus-mono

Old pipeline: review → frontend and backend developed in separate repos → integration → test and release. Integration was the most expensive, with interfaces and understanding hard to align. The idea was: AI can write code across ends, blurring the division of labor, so one person can fully grasp a requirement and push frontend/backend/mobile, reducing handoffs. But code was scattered across multiple repos, and a single owner still lacked unified context.

Manus-mono (Mono): It is not physically merging code into one repo, but a unified entry point + a manual for AI (each repo's responsibilities, how they collaborate, conventions); pull whichever one you need to change. The evolution was roughly:

See the whole picture (business knowledge + Git worktree parallelism)

Local verification (the entire Manus can run locally, cutting verification from 5–10 minutes waiting for the test environment to seconds)

Controlled reading of online logs/config/troubleshooting

Go through the release process (add AI operational capability at stuck steps, approvals still with humans)

End-to-end verification (test accounts go through real flows, checked via browser/emulator)

Mono increasingly resembles a knowledge base + a "super-admin familiar with the rules": when ops find releases annoying, they write the process into Mono, and the whole company can have AI do it. Consensus: for one requirement, one person can write all ends; mobile has about 7 people carrying 2 products and 4 apps, with progress roughly in sync with web.

Three reasons it could spread: exploring boundaries is itself the pursuit; they cannot tolerate "AI can already handle it efficiently yet it's still done manually"; the organization is flat enough that decisions move fast up and down.

Product: Fear of priority misalignment → Builders + everyone has submitted code + video as PRD

The old-school product pipeline has many people and information is lost layer by layer; worse is priority misalignment. After Claude Code/Codex raised engineering throughput, the bottleneck flipped: there aren't enough product managers, and high-quality requirements can't be supplied fast enough.

Attempts: a few R&D staff act as Builders (end-to-end from spotting a problem to release); then blur job titles further, letting PMs also change code, but handoffs still stuck and PMs lacked an R&D perspective, so for a while they could only change copy and interactions.

After Mono: mandatory conventions (e.g., model calls/costs must first be confirmed with the owner); a self-built review bot (a strong model reviews all merges, with dedicated rules for critical modules like payments); Mono uses test accounts to go through registration/payment and records the screen step by step, and PMs watch the recording to point out problems.

Case: a PM working on speech-to-text first had Manus test more than ten models before choosing one; via Mono, took the frontend and built a Demo per the design conventions, generated user scenario images and revised them one by one; then used video editing to turn the Demo into a clip, and then wrote the web/desktop interface themselves. People are mainly the bottleneck at: choosing models, Demo product/design review, and R&D with release authority reviewing code. Zhang Tao calls this Human in the loop → Human on the loop: people design rules, supervise multiple AIs, judge at key nodes, and are accountable.

After Manus 2.0's video capabilities improved, some requirements went from PRD/mockups to a few-minute complete video (called PRV in the article): scenarios, interface, post-click behavior, states and boundaries, and implementation logic aligned upstream and downstream in one shot. About half of PMs can take a requirement from start to release independently; all PMs have submitted code to Manus; designers have also started writing code; user-visible interfaces such as Studio and Video Editor were mostly written by PMs.

Marketing: People shuttling between systems → digital colleagues

Content partnership/ad placement processes were scattered across email, contracts, approvals, spreadsheets, and various backends; few people, long processes, and creative time squeezed out. The starting point was small: after partnership content/ads went out, the company often didn't know at the first moment. First have AI detect the publish time → look at data → review history → signal when contract/approval is complete to update progress and push the next step → build it into an internal site: for people it's a kanban calendar, for AI it's a callable toolset, and thus the "digital colleague" was born.

Features of the digital colleague (examples from the article):

A unified "workbench" Session takes requirements, then splits into parallel Sessions, avoiding attention being fully occupied; Slack first judges relevance and whether to interrupt (the rules say the AI designs this itself during development)

The owner forwards discussions to it to "learn a bit," and the strategy enters its knowledge and is carried into later execution

It can proactively remind about project stages even without being @-mentioned ("B is still in testing, do you want to wait for A?")

It proactively asks across teams to clarify capability boundaries (e.g., which object types skeletal rigging supports) before speaking accurately to the outside

When reviewing scripts/pricing, people are willing to pull it in to look at history; the final call is still human

The website opens a feedback interface: if something is awkward to use, just raise a requirement → Automations triggers a development task, a closed loop that pushes the system to improve itself

Cross-cutting: fewer "go find someone and interrupt them"

Product and R&D affairs questions go to AI first (the Slack bot runs on a cloud computer, and non-R&D staff use it the most)

Checking progress: open each other's Sessions (visible by default within the same project; speaking in a conversation still requires approval, and permissions are still being refined)—not less communication, but fewer ad-hoc interruptions

Extreme working method: the master Session only lists "things that need my decision + recommended options"; Zhang Tao describes himself as ADHD with 20+ to-dos, handing them to Manus to break down tasks, directly starting what can be done, asking about background and follow-up owners for what's uncertain, then combining Slack/Gmail/Notion research before handing to PMs

Is roughly $10,000 in AI spend per person worth it?

After questions arose on social media, the article answers three points head-on: what's bought is time and attention (as the organization grows); it's expensive because they use the best models to probe boundaries (after investing in the code review bot, colleagues say they haven't heard of any online incident caused by merge issues in nearly half a year, while daily commit volume is outrageous); costs will fall as their own product (Studio) exposes waste, and users benefit too. The creed remains eating dog food + exploring boundaries; today's ten-thousand-dollar way of working may be a few hundred dollars in two years, and the organizational and working-method assets are more valuable.

Product opportunities seen and "what people ultimately do"

Sessions become multi-person collaboration objects (state transitions, management panels); cross-device (one person managing multiple machines → local/cloud and collaboration with colleagues); after Agents enter systems and knowledge bases, they proactively discover solutions people hadn't thought of.

The human role hasn't shrunk, it's more concentrated: defining problems, judging quality, deciding what's worth doing, being accountable for results, and growing together with AI. Company atmosphere and trust still rely on people accumulating day by day—it's not "if each person's Agent covers for them, they don't come to the office." They are still hiring. Writing again in six months or a year, the shape is unknown; every company's culture differs, and there may not be a standard answer, but for an Agent company this is a mandatory question.