Manus hat beschrieben, wie das Unternehmen seinen eigenen Agenten-Stack für den Alltag in Engineering, Produkt und Marketing nutzt. Der Blogbeitrag Rebuilding Manus with Manus stammt von Mitgründer und CPO Tao Zhang und datiert auf Ende Oktober 2026. Es ist kein Launch-Post, sondern ein Praxisbericht: was sich geändert hat, was kaputt ging und was Menschen weiterhin entscheiden.
Primärquelle ist der offizielle Manus-Blog. Die Zahlen darin stammen laut Nachsatz aus internen Aufzeichnungen; Teamgrößen und PM-Zahlen beziehen sich auf Ende Oktober. Einige Punkte sind Schätzungen oder Einzelberichte, keine unabhängigen Messungen.
Rebuilding Manus: die Ausgangslage
Zhang schildert eine Szene aus dem Endspurt zu Manus 2.0: Feature-Requests und Bug-Reports gingen per Slack an einen Ingenieur. Auf dessen Bildschirm liefen zehn bis zwanzig Agenten-Sessions parallel – teils in Manus, teils in Codex. Der Prompt war die Slack-Nachricht im Wortlaut. Die Rolle des Menschen verschiebt sich vom Schreiben des Codes zum Steuern, Prüfen und Verantworten.
Zwei Regeln nennt Manus für sich selbst: das eigene Produkt für echte Arbeit nutzen, und gezielt nach Stellen suchen, an denen KI scheitert. Der Text deckt drei Teams ab und betont ausdrücklich, dass es sich um ein laufendes Experiment handelt, nicht um die Definition einer „AI-native Organization“.
Mono: Kontext statt Prompt-Tricks
Der technische Kern heißt Manus-mono, kurz Mono. Es merged keine Repositories. Es ist ein Einstiegspunkt plus ein Handbuch für den Agenten: was jedes Repo tut, wie die Teile zusammenhängen, und wie das Team arbeitet. Dazu kommen Architecture Decision Records, damit Sessions mit Begründung starten, nicht nur mit Code.
Mono wuchs in Schritten, jeweils gegen den gerade größten Engpass:
- Systemüberblick und Git-Worktrees für parallele Arbeit
- lokaler Vollstack auf dem Laptop statt fünf- bis zehnminütiger Test-Pushes
- eingeschränkte Produktionsdiagnose (Logs, Konfiguration, Fehlerberichte)
- Release-Schritte end-to-end, Freigaben bleiben bei Menschen mit Release-Rechten
- End-to-End-Tests mit Testkonten im Browser und Mobile-Simulator
Das Mobile-Team soll laut Text die ganze Zeit sieben Personen umfassen und trotzdem vier Apps über zwei Produkte im Takt mit dem Web halten. Mono habe sich ohne Top-down-Mandat ausgebreitet. Das ist Herstellerdarstellung; externe Verifikation fehlt.
Drei Agenten, ein Mensch in der Mitte
Für Bug-Reports beschreibt Manus eine Kette: Ein interner Agent untersucht zuerst und findet den verursachenden Change. Er postet in Slack und taggt den zuständigen Engineer. Der Engineer entscheidet und übergibt an seinen eigenen Agenten. Ein dritter Agent prüft den Fix über Tests und relevante Flows. Der triage-Agent darf keinen Code ändern. Nichts geht ohne Freigabe einer Person mit Release-Rechten live.
Vertrauen in agentengeschriebenen Code entstand laut Text nicht aus Modellqualität allein, sondern aus Tests und geteiltem Kontext. Agents sitzen in ausgewählten Slack-Threads. Nach dem „Go“ kennen sie die Entscheidung schon. Ein Code-Review-Bot mit dem stärksten verfügbaren Modell und Extra-Regeln für sensible Bereiche wie Payments ersetzt die Warteschlange zweier Senior-Engineers – nicht die menschliche Merge-Entscheidung. Agents dürfen Pull Requests öffnen, aber nicht ohne explizite Freigabe in den Main-Branch mergen.
Autonomie braucht ein Ziel, das man prüfen kann
Ein gescheitertes Wochenend-Experiment zeigt die Grenze: Ein Agent sammelte internes Feedback und legte für jedes Item ein Projekt an. Montag warteten mehr als 200 Entscheidungen auf eine Person. Manus’ Schluss: Autonome Schleifen funktionieren nur, wo Erfolg prüfbar ist – Tests bestehen oder nicht, eine Seite lädt oder nicht. Produktentscheidungen haben diese Prüfung nicht. Jede Produktänderung beginnt deshalb weiterhin mit einer menschlichen Entscheidung, ob sie überhaupt lohnt.
Als Engineering schneller wurde, wurde Produkt der Engpass. Manus ließ zunächst einige Engineers als „Builder“ von Discovery bis Launch arbeiten, dann PMs Code ändern – beides stockte. Mono trägt Regeln mit: Änderungen an Modellaufrufen oder Kosten brauchen Owner-Freigabe, derselbe Review- und Testpfad wie bei Engineers, und Mono kann Sign-up und Zahlung mit Testkonten durchspielen. Laut Text shippen heute etwa die Hälfte der PMs Features selbst; jeder PM hat Code committed. Ein PM soll den Großteil der Manus-Studio-Oberfläche in 2.0 geschrieben haben, ein anderer den Video Editor. Zahlen und Beispiele sind interne Angaben.
Marketing-Teammate und weniger Unterbrechungen
Im Marketing verbindet ein „AI Teammate“ Vertrag, Freigaben, Launch und Performance in einem internen Workflow mit scoped Zugriff. Er verwaltet eine eigene Queue, lernt aus weitergeleiteten Strategie-Threads und hält langfristige Ziele im Blick. Menschen behalten wichtige Entscheidungen, ungewohnte Fälle und Kurskorrekturen.
Über Teams hinweg soll eine Slack-Bot auf Mono zuerst Fragen beantworten: Wie funktioniert Feature X? Wo steht dieser String? Ist etwas schon live? Sessions sollen teilbar werden – Fortschritt liegt nicht mehr nur in privaten Chats. Schreiben in fremde Sessions braucht Zustimmung; Permissions sind laut Text noch unfertig.
Mensch on the loop statt nur in the loop
Zhang beschreibt den Rollenwechsel so: Früher erledigte KI 70 bis 80 Prozent einer Aufgabe und Menschen füllten den Rest. Nun setzen Menschen Regeln, beaufsichtigen mehrere Agents, prüfen an Schlüsselstellen Methoden und Ergebnisse und verantworten das Outcome. Manche PMs reichen statt Spec und Mockups ein kurzes Anforderungsvideo, das Use Case, Screens, Klicks und Edge Cases zeigt. Gleichzeitig warnt das Produktteam vor dem Reflex, alles zu shippen, nur weil Bauen billig geworden ist. Die Kontrollfrage lautet: Würdest du es shippen, wenn es eine Sekunde dauerte und nichts kostete?
Kosten, Fragmentierung und nächste Schritte
Manus gibt zu, viel für KI auszugeben, und trackt den Spend, ohne ihn als Leistungsbeurteilung zu nutzen. Stärkste Modelle laufen vor allem in Verifikation und Code Review. Mehr Entwicklung soll in Manus Studio stattfinden, damit Verschwendung im eigenen Produkt sichtbar wird. Dass Kosten stark fallen, nennt Zhang eine Erwartung, kein Versprechen.
Was noch nicht funktioniert: Aufmerksamkeit fragmentiert stärker – wer früher vier bis fünf Dinge am Tag bewegte, stößt jetzt oft 20 bis 30 parallel an. Information ist verstreuter; der Head of Product fragt Mono manchmal per Screenshot, wer etwas geändert hat. Permission-Design und Supervision über mehrere Agents sind frühe Fixes.
Geplant sind geteilte Sessions als gemeinsame Arbeitsräume, Arbeit über Geräte und Personen hinweg sowie Agents, die Optionen vorschlagen statt nur Anweisungen auszuführen – zuerst intern, dann für Nutzer.
Einordnung
Der Text ist wertvoll, weil er Grenzen so klar benennt wie Erfolge. Er ersetzt keine unabhängige Studie und keine Sicherheitsprüfung. Für Teams, die Coding-Agents vergleichen, ergänzt er eher den Blick auf Organisation und Harness als reine Modell-Benchmarks – siehe auch unseren Harness-Vergleich, den Beitrag zu Gemini Computer Use und den Blick auf Agenten-Modelle wie LongCat-2.5. Offen bleibt, wie gut die beschriebenen Kontrollen unter Last halten und ob andere Firmen ohne flache Kultur und eigenes Agentenprodukt ähnliche Schleifen schließen können.
