Ten Thousand Dollars in Tokens Per Capita: Using Manus to Transform Manus
Building an AI-Native Organization: Practices and Reflections
Defining what makes a company "AI-native" is still an open question. AI keeps evolving, and so do the ways people work, their relationship with AI, and the organizational forms that emerge from all of this. But for an Agent company like Manus, "exploring the boundaries of AI has always been the team's pursuit."
A month ago, when most people still measured their AI usage against monthly Max Plans costing a few hundred dollars, the average per-person token spend at Manus had already exceeded $10,000, with a few team members hitting $70,000 or $80,000.
Below, Manus co-founder Tao Zhang recounts the exploratory journeys of the R&D, product, and marketing teams. Beyond the product itself, these stories carry an additional aspiration for the future. As Red Xiao put it in a repost: "AI lets ordinary people do extraordinary things better."
This is also the question that Manus 2.0 will keep answering.
In September, when the Manus team was going all-in on developing Manus 2.0, there was one day that left a deep impression on me.
I had sent an engineer several feature requests and bug reports. When I checked in on progress later, I saw his screen filled with Codex and Manus sessions. I clicked on one at random—the input was exactly what I'd just sent him on Slack, word for word.
In the past, an engineer would receive a request, analyze it themselves, then start coding. Now, whether it's a new feature or a new bug, everyone basically hands it straight to AI. The AI finds the relevant code itself, makes the changes itself. Throughout the process, the parts that humans physically execute grow smaller and smaller; the share of work devoted to directing AI and taking responsibility for its output grows larger and larger.
What surprised me even more was realizing that our engineers' typical work rhythm had become one person handling ten to twenty requests simultaneously.
These days, plenty of companies use AI to write code and boost development efficiency—nothing unusual there. But even so, one engineer juggling a dozen or two dozen requests at once is still somewhat extreme.
At Manus today, this has become the norm.
As the team has gone deeper with Manus and various AI tools, and as Manus 2.0 has unlocked more new capabilities, that scene I witnessed behind the engineer was just a microcosm. From product and R&D to marketing, operations, and beyond—organizational methods, human-AI relationships, information flow, and each individual's capability boundaries are all being adjusted, even reshaped, almost without anyone noticing.
My feelings are complicated. There's excitement—happiness and pride in the team's continuous iteration and change. There's also unease: Is this pace right? Fast enough, or too fast? Could this way of working bring problems we haven't seen?
I tried working with colleagues to document some of Manus's recent AI-native practices and explorations. The process of change itself is valuable. As a company building AI Agents, Manus holds itself to one requirement and one pursuit: "eating our own dog food" and exploring the boundaries of AI use.
Beyond the product, there's another question Manus must inevitably explore: Since work now and in the future will default to human-AI collaboration, how should an organization operate to let both sides collaborate more effectively?
Due to space constraints, I'm only sharing the situations of three teams here, documenting the practices and thinking currently unfolding inside our company. It's a process of exploration, not our final answer on what AI-native means.
R&D: AI Isn't Just an Assistant—It Can Run the Full Process
Traditionally, a request would come in, get reviewed, then get split between frontend and backend developers. After coding, they'd align interfaces and catch issues—"integration testing"—then test and deploy.
The biggest waste was in integration. Frontend and backend each had to understand the request, then agree on interface rules. Misalignment meant back-and-forth communication and revisions. Often it wasn't that people weren't trying hard enough—it's just genuinely hard for humans to fully align.
Manus had this problem too.
So we thought: since AI can write code across platforms, could we blur the division of labor? One person fully understands the request, then drives implementation across frontend, backend, and mobile—reducing the waste of cross-platform handoffs.
But code was scattered across different repositories. Even with one person in charge, AI still couldn't see the full picture in a single context.
So we built Manus-mono.
We created a code repository called Manus-mono, or Mono for short. It didn't merge the code together; instead, it provided a unified entry point, paired with a manual written for AI: what each repository does, how they work together, what development standards to follow. When AI needs to modify something, it pulls the corresponding repository.
Mono grew step by step, each step solving problems exposed by the previous one:
- Let AI see the big picture. Filled in business knowledge beyond individual repositories, made cross-repository collaboration possible, then supported parallel development through Git worktree.
- Let AI validate locally. Previously, every code change meant pushing to a test environment and waiting 5-10 minutes. Now, a complete Manus can run on a local machine, with validation taking just seconds.
- Let AI troubleshoot production issues. Under access controls, Mono can read production logs, configurations, and exception records, getting the information needed to diagnose bugs.
- Let AI complete the release process. For steps where releases tend to get stuck, we kept adding AI operational capabilities—but approval authority remains with humans.
- Let AI do end-to-end validation. Once validation became a new time sink, we had Mono use test accounts to walk through real flows, checking results in browsers and phone emulators.
Gradually, Mono became something like a knowledge base paired with a super-admin who knows the rules. The more people used it, the more knowledge accumulated. For example, ops colleagues were constantly being asked to help with releases, found it annoying, and wrote the release process into Mono. From then on, everyone knew how to do it—and could have AI do it.
I love this example: one small thing someone did to free themselves up ended up making the whole company a little faster.
By now, the team has reached consensus: one request, one person can write all platforms. The most vivid example is that our mobile team has only 7 people, simultaneously handling 2 products across 4 mobile apps, keeping pace basically in sync with the web version.
How a tool and its philosophy spread within a company depends on both the tool itself and the company's culture and organizational structure.
At Manus, rolling out Mono encountered virtually no resistance. I think there are three reasons:
- Exploring AI's boundaries of use is our pursuit. This means such explorations get encouragement, and there are always people pushing them forward.
- The team can't tolerate inefficiency. Everyone has very low tolerance for repetitive tasks, and for things AI can already judge and handle efficiently, still being done manually.
- The organization is flat enough. Whether top-down or bottom-up, most decisions can reach the whole organization quickly.
What about teams beyond R&D?
Product: End-to-End Shipping, Expressing Requirements Through Video
The "traditional" product development process goes: product manager gets an idea, does research, looks at competitors, finds data, then works with designers on prototypes and interfaces. Then review, dev scheduling and development, finally acceptance, testing, and launch.
There are many people in this chain, and information gets lost at every handoff. The same requirements document can produce completely different prototypes from product versus design.
But what's even more painful is priority misalignment. What's most important to one person may not be to another. The more people involved, the worse the misalignment.
After Claude Code and Codex emerged, engineer efficiency jumped dramatically—and a new problem arose: there weren't enough product managers, unable to supply enough high-quality requests fast enough.
This is a subtle moment. In the past, dev resources were always the bottleneck; for the first time, it's reversed.
Internally, our experiment was to first let a small number of engineers become Builders: one person owning the entire process from problem discovery to launch, reducing communication waste and priority misalignment from handoffs. But at the time, engineers who both understood technology and had product judgment weren't plentiful.
So we launched an internal program to blur role boundaries, letting product managers directly modify code too. But two problems emerged: handoffs still existed—after product made changes, they handed to dev, who couldn't always pick up immediately; and product lacked an engineering perspective. So back then, product could only change copy and interactions, not underlying logic.
Mono solved both problems.
First, it embedded standards and confirmation requirements. Modifications involving model calls or costs had to be confirmed with the responsible colleague before code changes, per standard.
Second, we built our own code review bot, using the best model to review all code, with specialized check rules for critical modules like payments. Mono could also use test accounts to walk through registration, payment, and other flows, recording screen captures. Product managers could watch the recordings and point out what was wrong.
Now, all product managers have submitted code, and video has become the new PRD.
Here's a story.
One of our product managers, working on a speech-to-text feature, first had Manus test over ten models, then selected one to integrate. Next, she got frontend code through Mono, built a demo following existing design standards, and had Manus generate images for every user scenario she could think of. She checked each one, and had Manus fix whatever was off.
After revisions, she used Manus's video editing features to turn the demo into a video. The plan was clear enough that she decided to keep going and finish the feature herself. Both web and desktop interfaces were completed by her.
Throughout, human involvement concentrated in three types of judgment: selecting the model, product and design review of the demo, and code review by engineers with release authority.
One product manager, pushing a feature from model selection to launch. A year ago, this would have been nearly impossible.
We see this as a huge shift from Human in the Loop to Human on the Loop. Before, AI completed 70-80%, with humans filling in the rest; now, AI's share has risen dramatically. Humans design the rules, increasingly supervise multiple AI's work, judge methods and results at key nodes, intervene when necessary, and take responsibility for final outcomes.
Worth noting: Manus 2.0 significantly boosted video production capabilities—both generating video from images and creating animations through code. So some product managers' deliverables are no longer traditional PRDs or design mockups, but complete videos.
In a few minutes, the video conveys the feature's key information: what scenario the user is in, how the interface is designed, what happens after clicking, how different states and edge cases are handled, and the implementation logic behind it.
I don't know if other companies do this. For us, video genuinely makes alignment easier upstream and downstream. Design, dev, and test all watch the same demo, more easily understanding what the final product should be, without having to explain repeatedly to different people. After I shared this at an internal product meeting, more and more colleagues started writing requirements this way.
Below is the product requirement video (PRV) for the voice input feature.
Currently, about half our product managers can independently complete and launch requirements, and all product managers have submitted code to Manus. Recently, designers have started writing code too. In Manus 2.0, most interfaces that Manus Studio users see were written by one product manager; the Video Editor was too.
Writing this, I'm somewhat moved. Behind these stories are colleagues who, in just a few months, actively broke through their own capability boundaries.
This is what makes me proudest of our team.
Marketing: Digital Colleagues Enter the Workflow
The marketing team has had two recent experiments.
Marketing teams often do content partnerships. One partnership goes through: making contact, confirming collaboration, reviewing scripts, approving pricing, contract and payment, then publish tracking and performance review. Ad campaigns have their own long flow: checking data across multiple platforms, building ad series, filling in creatives, then analyzing performance and adjusting.
These steps are scattered across email, contract platforms, internal approvals, project spreadsheets, and various platform backends. People often have to "carry" information between systems: contract signed, go update spreadsheet status; content published, notify relevant colleagues.
Small team, long process—most energy gets consumed in managing the workflow, squeezing time for the creative work that actually requires ideas and judgment. We had this problem too.
Using Manus to transform Manus, for the marketing team, started from a very small problem.
We found that after content partnerships or ads went live, we often couldn't find out immediately. News had to pass through several layers of people, and by the time we knew, it was already a bit late.
So we first had AI write scripts, automatically detecting when content goes live. Once we knew publish time, we wanted to see performance data; since we could see data, we might as well review historical partnerships too.
Then we strung the process together. After contract signing, internal approval, and other steps completed, the system signals, and AI updates progress, finds relevant colleagues, and pushes to the next step.
These features were built by Manus into an internal site. For humans, it's data, dashboards, and calendars; for AI, it's a set of callable tools.
AI that can use these tools to participate in work became our digital colleague.
The biggest difference between a digital colleague and an ordinary tool is that they truly participate in the team's workflow.
They receive and arrange work like a colleague. Many colleagues reach out to them at once, so they maintain one "workbench" session for conversations with everyone, then break out specific tasks to other sessions for parallel execution.
This way, their own "attention" doesn't get maxed out.
There's a lot of Slack traffic; they don't reply to every message immediately. They first judge: is this message relevant to me? If relevant, they split into "interrupt what I'm doing" versus "handle after finishing" categories. These rules weren't taught by us—they were designed by the AI during development.
They get new information into execution faster. Before, when the team developed new strategies or product understanding, they'd present at a meeting, then write a brief. Now, the marketing lead forwards discussion to them, saying "learn this." They update their knowledge accordingly, and apply it in every subsequent execution.
They remember long-term goals. Once, colleagues were discussing two projects in Slack, and momentarily couldn't recall what stage one was in. No one @-mentioned them, but they proactively reminded: "B is still in testing phase—should we wait for A's results before looking at B?"
The first time I heard about this, I was delighted. In that moment, they didn't feel like a tool—more like a colleague who'd been listening carefully the whole meeting.
They proactively align across teams. After product colleagues launched 3D model generation and skeleton rigging features, they proactively asked about the feature's applicable conditions. They learned that skeleton rigging currently supports seven categories of objects, like fish, snakes, and quadrupeds. They noted these details, so when introducing this feature externally later, they could speak accurately.
Colleagues also started proactively inviting them to review scripts and pricing together. The reason is simple: humans can only review so much material in limited time, while they've seen all historical records.
But the final call still belongs to humans.
Normally, the digital colleague works through our built internal site—whatever features the site has, they use. If the site is poorly designed, they can only make do, or tell us, and we modify the site.
But we didn't want to play telephone in the middle.
So we opened a feedback interface on the site. When they find something awkward to use, they can directly submit requests through this interface. Requests coming in automatically trigger Manus development tasks. This uses Manus 2.0's Automations feature: receiving an external notification automatically starts a task.
This way, the digital colleague can not only work with existing systems, but when encountering functionality the system doesn't yet support, can directly request new features from Manus, and start using them once development completes.
Information No Longer Requires Asking People—Reducing Interruptions
These scenarios share one common change: many things that previously required asking someone no longer need to interrupt that person.
Inside Manus, we've gradually formed some consensus.
For product and development matters, ask AI first. A colleague used Mono to build a Slack bot running on cloud computers—receives tasks, processes them, replies in the original message thread. It's used most by non-engineering colleagues. Want to know how a feature is implemented, where copy is located, whether some feature is live? No need to first find out who owns it—just ask them.
Check progress by opening a session. Before, engineers' progress lived in their own AI conversations. Others could only ask them directly, and when they were off work, progress was invisible. So we built a collaboration feature currently for internal use only: members on the same project can see each other's sessions by default, and can request to enter conversations to speak.
For example, engineering colleagues first do extensive work with AI, then a product manager enters the same session to adjust spacing, styling, and copy. Two people and AI alternate pushing forward.
Sending messages in someone else's session still requires their approval. We're still refining this permission design.
Schematic of engineers, product managers, and designers collaborating in the same session. Content is simulated, not from actual work sessions.
I want to emphasize something here. The "no longer needing to ask people" mentioned above isn't about reducing human-to-human communication. I think the more important meaning is reducing the time and energy waste from being "interrupted mid-task" in organizational collaboration.
Make decisions—or even just look at what you need to decide. One colleague who uses AI the most has perhaps the most "extreme" working method. He maintains one master Manus session responsible for only one thing: listing what needs his decision, with recommended options attached. While everyone's discussing heatedly on Slack, he doesn't need to open Slack, and rarely opens code repositories. He only asks AI: "What needs my decision now?"
AI lists several items, explains where each is stuck, and he makes the call.
I use this method too. I have over twenty to-dos daily; I've shared in some settings that I have ADHD, and for me, the hardest part is starting.
Now, I hand all to-dos to a dedicated Manus project, which breaks each into independent tasks. What it can do, it starts directly. What it's uncertain about, it asks me for context, asks which product manager I want to follow up. Then it does initial research combining information from Slack, Gmail, and Notion, and delivers requirements plus research to the relevant product manager.
What the product manager receives is no longer a one-sentence to-do, but a complete brief with full context. For me, this isn't just an efficiency change.
It reduces my daily anxiety about not knowing where to start.
Is $10,000 Per Capita in AI Spending Worth It?
Early this month I shared on Moments: The company's September AI spend exceeded $10,000 per person on average. Not everyone used this much—a few individuals spent $70,000 or $80,000 each.
After posting this, some questioned whether the spending was excessive. I read these criticisms carefully. Here's my direct response:
First, this money buys not labor, but time and attention. As teams grow, communication costs rise. What AI saves is each person's attention, giving everyone more complete ownership of what they're responsible for.
Second, it's expensive because we use the best models—this is core to understanding AI's boundaries. The colleague responsible for engineering efficiency told me our code review bot has been in use for quite a while, and in the past half year he hasn't heard of any production incidents caused by merging problematic code—bearing in mind that after AI coding became widespread, our daily code submission volume is extreme. So in this scenario we use the most capable model available at this stage; on one hand this solves our problems, on the other it helps us understand how far current model capabilities have evolved. He thinks this may be the company's most worthwhile expenditure.
Third, costs will decrease through product improvement. As more development work happens on Manus Studio—our own product—we can see from internal usage data where tokens are being wasted. We improve the product, waste decreases, and costs come down. Users benefit too.
Of course, all of this ultimately stems from the requirement and pursuit I mentioned earlier: "eating our own dog food" and exploring AI's boundaries of use.
We also believe costs will keep falling. The way of working that today costs $10,000 monthly may only need a few hundred dollars in two years.
The new ways of working and organizing accumulated through this process are the more valuable assets.
Opportunities We See
These experiments and questions have also revealed some product opportunities. The pitfalls we've stumbled into are likely ones peers will encounter too.
First, sessions themselves become objects of multi-person collaboration. Before, one person had one task, completed through one conversation, then moved to the next task; now, one person raises a problem, a designer produces a solution, an engineer implements it, a product manager continues operations—all can progress within the same session. It carries a complete piece of work, needing clearer state transitions, and possibly better management panels.
Second, cross-device collaboration. We can already let one person manage multiple computers through Agents; next is connecting local and cloud, and supporting collaboration between colleagues. The goal is letting ideas flow more smoothly into output, letting work continue even when people aren't glued to their computers.
Third, Agents proactively discovering solutions. After entering a company's systems and knowledge base, Agents don't just execute assigned tasks—they can also use available tools, knowledge, and resources to find solutions humans hadn't thought of.
These are what Manus needs to do well next. We'll try them ourselves first, then put them in users' hands.
What Do Humans Do in the End?
Returning to that stunning scene from the beginning: engineers handing requirements directly to AI, simultaneously pushing forward a dozen tasks.
This isn't just higher efficiency—it's the way organizations operate changing. Before, organizations relied on division of labor and hierarchy to transmit information; how much one person could accomplish depended on how many people and resources they could mobilize. Now, we spend more energy filling in context for AI, preparing tools, then judging and deciding.
AI's completion level is already very high, but what to do still gets decided by humans.
We've also joked: since Manus can do so much, do we even need to come to the office anymore—just let our respective Agents work together? Of course not. A company's key questions still need humans to raise, discuss, and decide.
A company's atmosphere, philosophy, and trust between people come from daily磨合 and shared experiences at critical moments.
So our current understanding is: in an AI-native organization, the human role hasn't shrunk—it's become more concentrated. Defining problems, judging quality, deciding what's worth doing, and taking responsibility for results.
And one more crucial point: growing together with AI.
Humans still matter, so we're still hiring. Human capability and value remain essential in this way of working.
Writing this, I suddenly became curious: if I write on this topic again in six months or a year, what will our way of working look like? I have no answer. AI's capability boundaries are still expanding, and organizations must keep exploring how to work with it.
Every company's goals, structure, working methods, and culture differ. How AI-native organizations should operate may not have a standard answer, nor a final form. But for an AI Agent company like Manus, exploring how humans and AI can collaborate is an inevitable proposition.
We'll keep answering this question.