Animated explainer: Rebuilding Manus with Manus

Tao Zhang, co-founder and Chief Product Officer of Manus, published a long essay: “Rebuilding Manus with Manus: What changed, what broke, and how we work now”. It is not about a new feature. It is about what happened to the engineering, product and marketing teams at a company that builds agents once its own people started working alongside agents by default — and which parts have not worked.

The story starts in late September, during the final push on Manus 2.0. Zhang sent one of the engineers a few feature requests and bug reports on Slack. Later he went to see how it was going: the engineer's screen had a row of open agent sessions, some in Manus and some in Codex. He clicked into one.

The prompt was his Slack message:

The request went into the agent as-is.

A year ago, the engineer would have read the message, worked out what it meant, then written the code. Now an agent reads the request, finds the relevant code and proposes a change. The engineer does three things: directs the work, checks it, and owns the result.

Most of the time a request is running, not waiting on him. At Manus it is now common for one engineer to have 10 to 20 requests moving at once.

The same person's work, a year ago and now:

Requests run; they don't wait on people.

Zhang says he is proud of how quickly the team adapted, and also uneasy: is this pace right? What haven't they noticed yet?

Manus holds itself to two rules: use its own product for real work, and keep looking for the places where AI stops working. The essay follows both. It covers engineering, product and marketing, including what hasn't worked. Zhang frames it as a report of an experiment in progress, not a definition of an “AI-native organization.”

The conclusions first

The essay opens with six things learned so far:

• There's no halfway point: adding AI to old ways of working sometimes just added noise. Things changed only when the loop closed.
• Agents need the whole picture: better context did more than better prompts.
• Trust comes from tests and context, not from model quality alone.
• Autonomy needs a finish line: agents can run on their own only when success can be checked; everywhere else, a person decides.
• The bottleneck moves: once engineering got faster, deciding what to build became the constraint.
• The role of people hasn't diminished; it has become more focused on higher-impact things.

Put together, the six read roughly as one line:

Six points, all still in the experiment.

Each section that follows maps more or less to one of them.

No halfway point

Before 2026, Manus did what most companies did: it added AI to the way it already worked. Support flagged issues with AI summaries, engineers used coding assistants, and bots posted analysis in channels.

Each piece was useful on its own, but the pieces weren't connected.

Until the loop closed, they were working the old way, just with a lot of AI talking over each other:

Without a closed loop, it's just more AI talking over each other.

The team often comes back to one line: software engineering is programming integrated over time. Writing code is easy to measure; keeping a complex product healthy for years is not. A high share of AI-written code can mean real progress, or a pile of slop someone will have to clean up later.

So the test they care about is harder: Manus is a complex product that has been live for more than a year. Under new ways of working, can it keep improving without collapsing, while each person gets more done?

Zhang's answer: so far, yes.

Give the agent the whole picture

Like most tech companies, Manus lost the most time at handoffs. A frontend engineer and a backend engineer would each interpret a request, agree on an interface, then spend days fixing the mismatches. Two people rarely understand a requirement the same way.

If AI can write code across the stack, could one person own a request end to end? The obstacle was context: the code lived in separate repositories, and no agent could see the whole system at once.

The answer began with an internal experiment — how far could AI go in building a product with as little human input as possible and almost no hand-written code? The method that emerged became the internal tool Manus-mono, or Mono.

Mono doesn't merge the repositories. It is a single entry point plus a manual written for the agent: what each repository does, how they fit together, how the team works. The agent pulls in what it needs. There is also a library of architecture decision records, so every agent session starts with the reasoning behind past decisions, not just the code.

Whoever works with the agent, the agent carries the context of everyone who came before:

Don't merge the repos; give the agent the whole picture.

Mono grew in steps, each fixing the bottleneck the previous step exposed:

1. See the whole system: add the business context no single repository contains, and use Git worktrees for parallel work.
2. Verify locally: a push to the test environment used to take 5 to 10 minutes; now the full Manus stack runs on a laptop and checks take seconds.
3. Debug production issues: with scoped permissions, Mono can read the logs, configuration and error reports needed to diagnose production bugs.
4. Run releases end to end: Mono handles the release steps where work used to stall; people still make the approval decisions.
5. Test end to end: when verification became the slow part, Mono started running real user flows with test accounts, in a browser and a mobile simulator.

Five steps, one at a time:

Each step fixes what the last one exposed.

(The original includes a video on how Mono works and how it evolved, made by a teammate with Manus.)

People often ask whether Mono is a code wiki. Documentation is one part; the rest is everything around the code: how they test, how they release, what they decided and why, and what the agent is and isn't allowed to touch.

Mono has also become a shared knowledge base that gets better as people add to it. One example: the ops engineer got tired of being asked to help with releases, so he wrote the release process into Mono. Now anyone can run a release, and so can the agent, but approval still sits with people who have release rights.

One person fixed his own frustration, and the whole company got a little faster:

Anyone can release; approval stays with people who have release rights.

The team now assumes one person can ship a request on every platform. The mobile team has been seven people throughout, maintaining four apps across two products and keeping pace with web.

Mono spread through the company with no top-down mandate. Zhang credits culture as much as the tool: testing AI's limits is part of why they exist, and the organization is flat. A tool goes only as far as the organization lets it.

Closing the loop: from a bug report to a verified fix

Mono let anyone work on any part of the product. That was half of it. The other half was letting agents find problems on their own.

At most internet companies, a user's bug report passes through support, product and triage before it reaches an engineer who can fix it.

At Manus, an internal agent now investigates the report first, traces the issue back to the change that caused it, then posts in Slack and tags the engineer who owns that change. The engineer decides whether it's theirs to fix and hands it to their own agent. A separate agent checks the fix by running the relevant tests and flows.

Three agents, three roles: triage, do the work, verify. The person in the middle makes the calls.

The path one bug report takes:

Three agents, a person in the middle.

A growing share of engineering work now starts this way: an agent bringing a problem to a person.

The loop has clear limits. The agent that reads user reports can't change code; it can only investigate and report back. Changes come from the engineer's own agent, after the engineer decides. Nothing ships without approval from a person with release rights.

Trusting agent-written code

For a long time, every change into the main branch needed sign-off from one of two senior engineers. The team didn't trust AI enough to skip that step. As agents produced more code, that review became the bottleneck.

On pure coding ability, the models were already strong. The gap came down to two things:

First, people know how to test their work. Second, people have been part of the discussions upstream and downstream, so they know what “right” means for the business.

Correct code isn't the same as the correct product:

Correct code ≠ the correct product.

So they addressed both:

• Let agents join the discussion: each engineer's agent now sits in the Slack threads it has been added to and follows the context. When someone finally says “Go,” the agent already knows what the team decided and why.
• Let agents test end to end: working with the backend team, they gave agents the ability to run real flows and regression tests in Manus after each change. As test coverage grew, trust grew with it.

Today every change goes through that verification and through a code review bot running the strongest model available, with extra rules for sensitive areas such as payments.

The bot replaced the queue, not the human decision:

The bot replaces the queue, not the decision.

An agent can open a pull request, but it can't merge into main without explicit approval from a person. People still decide what gets built and who can release.

Autonomy needs a finish line

Trust has limits. They found this out the hard way.

At one point everyone was excited about fully autonomous agent loops, so they tried one: an agent collected feedback from internal feedback channels and started a project for each item. A teammate let it run over a weekend.

Take a look:

Monday morning: more than 200 items waiting for his decision.

Why not let the agent make those decisions too? Because autonomous loops work only when the system can check whether the goal has been met. Tests pass or fail; a page loads or it doesn't. Most real work has no such check, and a person has to judge whether it's done, and whether it was worth doing.

That weekend left two lessons. First, people can't make decisions as fast as an unchecked loop creates them. Second, if no one decides whether something should be done, no one owns the result.

Whether you can let go depends on whether there's a finish line:

Let go where it can be checked; a person decides where it can't.

The bug-fixing loop above works because tests define success. Product decisions don't have tests, so every product change at Manus still starts with a person deciding whether it's worth doing.

The bottleneck moved to product

A traditional product process has many handoffs, and priorities drift a little at each one. As coding agents made engineers faster, a new problem appeared: there weren't enough product managers to write good requirements.

For the first time, engineering wasn't the constraint.

Manus tried two things first. One was asking a few engineers to become “builders” who own a problem from discovery to launch, but few people had both technical and product judgment. The other was letting PMs change code, which also stalled: the handoffs were still there, and without an engineer's instincts, PMs could change copy and interactions but not the underlying logic.

How the bottleneck moved:

Once engineering speeds up, the constraint moves to deciding what to build.

Mono solved both problems because it carries the rules with it:

• Any change that touches model calls or cost needs the owner's sign-off before code is written.
• Every change goes through the same review and testing as an engineer's change.
• Mono can walk through sign-up and payment with test accounts and record each step, so a PM can point to the exact moment something breaks.

What does that look like? A PM working on speech-to-text had Manus benchmark more than 10 models, then chose one. She pulled the frontend code through Mono, built a demo in the design system, and had Manus render each user scenario as an image for her to review. She turned the demo into a video. The plan was clear enough that she built the feature herself, including the web and desktop UI.

People made three decisions along the way: she chose the model; product and design reviewed the demo; an engineer with release rights reviewed the code.

One PM, from choosing a model to shipping:

A year ago, none of this would have been possible.

They describe the shift as moving from human in the loop to human on the loop. AI used to do 70–80% of a task and people filled in the rest; now people set the rules, supervise several agents, check methods and results at key points, step in when needed, and own the outcome.

The difference between the two positions:

From filling in the tail to setting rules and checking key points.

Some PMs now hand off a short video instead of a written spec or mockups. In a few minutes it shows the use case, each screen, what each click does, how edge cases behave, and how it works underneath. Design, engineering and QA agree on what “done” means faster, and the PM explains it once. (The original includes a product requirement video for voice input.)

Today about half of the PMs ship features on their own, and every PM has committed code. Designers have started too. One PM wrote most of the Manus Studio interface in Manus 2.0; another wrote the Video Editor. Behind each is someone who spent months pushing past what their role used to cover. Zhang says that's what he's proudest of.

That doesn't mean everyone has to be a builder. When anyone in a company can build, people may ship things that shouldn't exist. The product team often asks: “If this took one second and cost nothing, would you ship it?” Sometimes the answer is no.

So they still need module owners who decide what gets built, what doesn't, and what users finally see, and people who maintain infrastructure like Mono. When building gets easy, deciding what to build matters more.

An AI teammate in marketing

A marketing partnership moves through script review, pricing, contracts, approvals, payment, launch and results review. Those steps live in email, contract tools, approval systems, spreadsheets and ad platforms. Much of the job used to be moving information between them, leaving little time for creative work that needs judgment.

They started with one small problem: when partner content or an ad went live, the team often heard about it late. So they had AI write a script that detects when content is published. Then they wanted performance data. Then a review of past partnerships. Then the whole internal workflow connected: when a contract is signed or an approval clears, the agent updates the status and notifies whoever owns the next step.

From one script to a whole line:

It grew from one small problem.

Manus built all of this into an internal site. For people, it's dashboards and a calendar; for the agent, it's a set of tools. The agent that uses those tools inside this workflow is what they call an AI teammate. It works only in the channels and systems the team has connected it to, with access scoped to this workflow.

It manages its own queue. Many people message it at once, so it talks to everyone in one “front desk” session and hands tasks to parallel sessions. It decides whether a message is relevant to it, then whether to interrupt current work or wait. It proposed these rules itself during development, and the team reviewed them before keeping them.

One front desk, several parallel jobs behind it:

The front desk talks; the sessions behind it work in parallel.

It learns from forwarded context. A strategy change used to mean a meeting and a written brief; now the marketing lead forwards the discussion and says, “Learn this.”

It keeps long-running goals in view. Once, in a Slack thread it had been added to, teammates couldn't recall where a project stood. Without being tagged, it replied:

Take a look:

Nobody tagged it; it remembered A and B.

It also checks facts with other teams. After 3D model rigging launched, it asked the product team what was supported and learned that rigging covers seven categories, including fish, snakes and quadrupeds, so marketing's descriptions stayed accurate.

Teammates now bring it into script and pricing reviews, because it has read the past partnership records. People still make the call.

The internal site can also improve from its own users, including the agent. When the agent hits friction, it files a request through a feedback endpoint; the request opens a development task in Manus through Automations in Manus 2.0; an engineer reviews the change before it ships.

The site gets fixed by its users:

Fixed by its users — but only a week in.

This mechanism has run for about a week. Zhang is blunt: they need many more cases before they rely on it.

So what do the people on the team do? Three things stay with them: they make and own every important decision; they handle cases the agent hasn't seen and teach it what to do or whom to ask; and they redirect it whenever its analysis points to a new angle.

Interrupt each other less

Across these teams, many questions no longer require interrupting someone. The essay describes three habits.

Ask the agent first. A teammate built a Slack bot on Mono that runs on a cloud computer and replies in the thread. Non-engineers use it most: How does this feature work? Where is this string? Has this shipped? They no longer need to find the owner first.

Open the session instead of asking for a status update. An engineer's progress used to live in their own AI chats, invisible once they logged off. So the team built an internal feature that lets project members see each other's sessions and ask to join. An engineer might build most of a feature with the agent, then a PM joins the same session to adjust spacing, styles and copy. Posting in someone else's session requires their approval, and the permissions are still being worked out.

Decide only what needs deciding. The company's heaviest AI user keeps one main session with a single job: list what needs his decision, with a recommendation for each. When Slack gets busy, he stays out of it and asks, “What do I need to decide right now?”

Three ways to interrupt less:

Not talking less — interrupting less.

The point isn't to talk to each other less; it's to interrupt each other less. (The original shows an illustration of an engineer, a PM and a designer working in one session, noting it isn't a real pricing change.)

Zhang does something similar. He has more than 20 to-dos a day, and — as he has shared publicly — he has ADHD. Starting is the hardest part for him.

Now every to-do goes into a dedicated Manus project that turns each one into its own task and starts what it can. When it's unsure, it asks him for background and which PM should own it. Then, using the access he has given it to his Slack, Gmail and Notion, it gathers the context and hands the PM a complete request instead of a one-line note.

One to-do becomes a complete request:

Starting is the hard part, so it starts for him.

He says the change isn't only about efficiency: he spends much less of his day anxious about where to begin, which is huge on a personal level.

Is it worth the cost?

Manus spends a lot on AI and tracks that spend closely. The data isn't used to judge anyone's performance; it's used to judge the spend itself: is it paying off now, or setting them up for later?

Here's how they reckon it:

• It buys time and attention. As a team grows, coordination eats into everyone's attention. AI protects each person's attention and gives them fuller ownership of their work. And they're still hiring.
• Using the best models is how they learn where AI's limits are. The verification and code review setup above runs on the strongest models they can get. The colleague who leads developer productivity calls it their best-value spend.
• The cost should fall through the product. More development now happens in Manus Studio, their own product, so usage data shows where tokens are wasted; the fixes go into the product and should make Manus more efficient for users too. They expect today's costs to fall substantially as models get cheaper and waste is removed.

Three entries in the ledger:

Money buys attention; the product pushes the cost down.

On that last point Zhang adds: it's a belief, not a promise.

What isn't working yet

Fewer interruptions, more fragmented attention. Someone who used to handle four or five things a day may now push 20 or 30 forward at once. Every switch means reloading context. AI expands what people can do, and it also pushes them to do more. One PM said that whenever a task is running, she can't resist starting another agent.

Doing more things isn't the goal. They treat this as a problem to solve, not a pace to celebrate.

The same person, from four or five things to twenty or thirty:

Doing more isn't the goal.

Information is more scattered. The head of product used to know every change and why it was made. Now he sometimes screenshots a problem and asks Mono, “Who changed this?” It's funny, but the question is real: when everyone is empowered to change the product, who is responsible for the whole?

Sharing permissions need a redesign. When work can be shared and handed over, and agents sit in more conversations, they have to decide what's open and what needs approval.

The current fix is basic: one agent supervises the others and reports only what's stuck and what needs a human decision. They know it can be better.

Who changed it, who can see it, who's watching:

Everyone can change it — who owns the whole?

What's next

These problems point to product work other teams will probably need too. The features weren't planned in advance; they came from problems the team kept running into:

• Sessions as shared workspaces: one person raises a problem, a designer proposes a fix, an engineer builds it, and a PM runs it, all in the same place.
• Work that moves across devices and people: local and cloud machines stay connected, so work continues when people step away.
• Agents that find options people hadn't considered: an agent working inside a company's systems, with the right permissions, should be able to suggest solutions, not just carry out instructions.

Three directions:

Try it on themselves first, then bring it to users.

What people do now

Back to the engineer with a row of agent sessions open. Zhang says that isn't just a story about efficiency; it's a change in how the organization runs.

Companies used to move information through roles and hierarchy, and what one person could do depended on how many people and resources they could leverage. Now they spend a little time giving AI context and tools, and more time making judgments and decisions. More and more often, an agent brings the problem to a person; deciding what to do about it remains the person's job.

They've joked: if Manus can do this much, why come to the office? Let the agents work it out. But the important questions still need people to raise them, argue about them and decide. What counts as a good product? Or, to exaggerate a little: build a great product with real revenue that keeps pushing AI's limits, or go for the margin?

AI doesn't know which one they want. They do.

Culture and trust come from working things through together, day after day and in the moments that matter. That's the foundation under the work in every session.

So, for now, their answer is that the role of people hasn't diminished; it has become more focused on where they have the most impact:

Four things still in people's hands.

That's also why Manus is still hiring: people's skills and judgment are at the center of this way of working, and that isn't changing any time soon.

Zhang ends by saying he's curious what the post would say a year from now. Every company has different goals, structures and culture, so there may be no standard answer and no final form. But for a company that builds agents, working out how people and AI work together isn't optional; it's part of the job.

The original closes with a note on the numbers: figures come from internal records; team sizes and PM shipping figures are as of late October; some points are estimates or one person's experience rather than measurements.