Manus has described how it uses its own agent stack for day-to-day work in engineering, product, and marketing. The blog post Rebuilding Manus with Manus is by co-founder and CPO Tao Zhang and dates to late October 2026. It is not a launch note. It is a field report: what changed, what broke, and what people still decide.
The primary source is the official Manus blog. A closing note says 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, not independent measurements.
Rebuilding Manus: the starting point
Zhang describes a late-September push on Manus 2.0: feature requests and bugs went to an engineer on Slack. That engineer’s screen showed ten to twenty agent sessions at once — some in Manus, some in Codex. The prompt was the Slack message verbatim. The human’s job shifts from writing the code to directing, checking, and owning the result.
Manus holds itself to two rules: use its own product for real work, and keep looking for where AI stops working. The post covers three teams and stresses that this is an experiment in progress, not a definition of an “AI-native organization.”
Mono: context over prompt tricks
The technical core is Manus-mono, or Mono. It does not merge repositories. It is a single entry point plus a manual for the agent: what each repo does, how the pieces fit, and how the team works. Architecture decision records mean sessions start with prior reasoning, not only code.
Mono grew in stages, each fixing the previous bottleneck:
- whole-system context and Git worktrees for parallel work
- full Manus stack on a laptop instead of five- to ten-minute test pushes
- scoped production diagnostics (logs, configuration, error reports)
- end-to-end release steps, with approvals still held by people with release rights
- end-to-end tests with test accounts in a browser and mobile simulator
The mobile team is said to have stayed at seven people while maintaining four apps across two products in step with web. Mono spread without a top-down mandate. That is the company’s account; there is no external verification.
Three agents, one person in the middle
For bug reports, Manus describes a chain: an internal agent investigates first and traces the change that caused the issue. It posts in Slack and tags the owning engineer. The engineer decides and hands work to their own agent. A third agent checks the fix with tests and relevant flows. The triage agent cannot change code. Nothing ships without approval from someone with release rights.
Trust in agent-written code, the post says, came from tests and shared context more than raw model quality. Agents sit in selected Slack threads. After someone says “Go,” the agent already knows the decision. A code-review bot on the strongest available model, with extra rules for sensitive areas such as payments, replaced a two-senior-engineer queue — not the human merge decision. Agents can open pull requests but cannot merge to main without explicit human approval.
Autonomy needs a checkable finish line
A failed weekend experiment marks the limit: an agent collected internal feedback and opened a project for each item. On Monday more than 200 decisions waited for one person. Manus’s conclusion: autonomous loops work only where success can be checked — tests pass or fail, a page loads or it does not. Product decisions lack that check. Every product change still starts with a person deciding whether it is worth doing.
As engineering got faster, product became the bottleneck. Manus first asked some engineers to become “builders” from discovery to launch, then let PMs change code — both stalled. Mono carries rules with it: model-call or cost changes need owner sign-off, the same review and testing path as engineers, and Mono can walk sign-up and payment with test accounts. About half of PMs now ship features on their own, and every PM has committed code, according to the post. One PM wrote most of the Manus Studio interface in 2.0; another wrote the Video Editor. Those figures are internal claims.
Marketing teammate and fewer interruptions
In marketing, an “AI teammate” connects contracts, approvals, launch, and performance inside an internal workflow with scoped access. It manages its own queue, learns from forwarded strategy threads, and keeps long-running goals in view. People still own important decisions, novel cases, and course corrections.
Across teams, a Slack bot on Mono is meant to answer first: How does feature X work? Where is this string? Has it shipped? Sessions are becoming shareable so progress does not live only in private chats. Posting in someone else’s session needs their approval; permission design is still unfinished.
Human on the loop, not only in the loop
Zhang describes the role shift this way: AI used to do 70–80% of a task and people filled in the rest. Now people set rules, supervise several agents, check methods and results at key points, and own the outcome. Some PMs hand off a short requirement video instead of a written spec and mockups, showing the use case, screens, clicks, and edge cases. At the same time the product team warns against shipping everything just because building got cheap. The control question: if this took one second and cost nothing, would you still ship it?
Cost, fragmentation, and what comes next
Manus says it spends heavily on AI and tracks that spend without using it to judge individual performance. The strongest models mainly run in verification and code review. More development is moving into Manus Studio so waste shows up in the product itself. Zhang calls large cost declines a belief, not a promise.
What still fails: attention fragments — people who once moved four or five items a day may now push 20 or 30 at once. Information is more scattered; the head of product sometimes screenshots a problem and asks Mono who changed it. Permission design and multi-agent supervision are early fixes.
Next product work includes shared sessions as common workspaces, work that moves across devices and people, and agents that propose options rather than only follow instructions — tried internally first, then shipped to users.
Takeaway
The post is useful because it names limits as clearly as wins. It is not an independent study and not a security audit. For teams comparing coding agents, it adds organizational and harness context beyond model scores — see also our harness comparison, Gemini Computer Use, and agent models such as LongCat-2.5. Open questions remain: how well the described controls hold under load, and whether other companies without a flat culture and their own agent product can close similar loops.
