YC heeft 'QM' gelanceerd, een interne multi-agent harness die organisaties helpt bij het efficiënt beheren van AI-agents. De tool lost belangrijke infrastructurele uitdagingen op, zoals geheugenbeheer, bestandsisolatie en integraties met Slack, GitHub en Notion.
De auteur stelt echter dat er twee kernproblemen blijven bestaan: een gebrek aan heldere communicatie over wat QM precies is (een host voor agents in plaats van een verzamelplek) en het feit dat de tool niet proactief is. Volgens de auteur is QM daarmee nog steeds 'tooling' en geen 'leverage', omdat het pas actie onderneemt na een expliciete opdracht en het contextprobleem van autonome agenten nog niet heeft opgelost.
YC's QM kreeg 12k sterren in een week. Het lost het probleem nog steeds niet op.
Ik heb de multi-agent harness van YC geïnstalleerd in de week dat deze werd gelanceerd. Hier is wat ze goed hebben gedaan, wat iedereen verkeerd begreep en de kloof die nog steeds bestaat.
Op 1 augustus 2026 lanceerde YC 'QM', hun interne multi-agent harness, en binnen een week behaalde het 12.000 sterren. Ik heb het voor mijn team op een VPS geïnstalleerd, en het viel me op dat het angstwekkend veel lijkt op wat wij met Zodus hebben gebouwd.
Deze tekst is mijn visie op wat QM goed heeft gedaan en waar het tekortschiet.
Een korte inleiding
Om te beginnen: QM is een oprecht goede tool en je zou het moeten proberen. Het is een agentic harness die iedereen in een organisatie zijn eigen OpenClaw-achtige agent geeft tegen een fractie van de kosten, met als extra voordeel een gedeelde context.
Het verhaal erachter is simpel: het beheren van zoveel OpenClaw-instanties werd voor YC te hectisch (en waarschijnlijk te duur), dus bouwden ze hun eigen tool om dit beter aan te pakken.
Het probleem
Het probleem is vrij eenvoudig. Elke OpenClaw-instantie heeft zijn eigen machine nodig. Natuurlijk kun je meerdere agents op één box draaien, maar dan ontstaan er nieuwe vragen:
- Hoe beheer je het geheugen?
- Hoe houd je bestanden geïsoleerd?
- Hoe zorg je ervoor dat een agent niet uit zijn sandbox "ontsnapt"? (Ik kijk hierbij naar OpenAI, Anthropic en Meta 👀)
Zelfs als je een '1000x agentic engineer' bent, is het bouwen van eigen infrastructuur iets dat constant onderhouden moet worden. Met het tempo waarin OpenClaw en Hermes worden uitgebracht, is dat een enorme uitdaging.
De oplossing
In theorie is de oplossing simpel: bouw je eigen primitieven rond de agentic loop en voeg deze vervolgens samen tot iets dat schaalt op organisatieniveau. Dat is precies wat YC heeft gedaan. Ze hebben alles gebouwd wat een cloud-harness nodig heeft:
- Een cron-systeem;
- Skill-opslag en bestandsopslag;
- Connectors voor belangrijke tools (Slack, GitHub, Notion);
- Compatibiliteit met gevestigde harnesses zoals Pi, OpenCode en Codex.
Wat is dan het probleem?
Er zijn twee zaken die nog niet opgelost zijn.
Ten eerste weet niemand wat QM nu eigenlijk precies is. Het werd een week voor Buzz gelanceerd, waardoor het beeld ontstond dat QM, net als Buzz, een plek was waar agents samenkwamen. De realiteit is echter het tegenovergestelde: QM is de host waarop agents leven, niet de plek waar ze zich verzamelen. Eén lanceerbericht was niet genoeg om dit onderscheid duidelijk te maken.
Ten tweede is QM niet proactief en lost het het contextprobleem niet op. Het werkt alleen als je er actief mee blijft werken via het webportaal of door de agent actief te taggen in Slack. De agent wacht op jou.
Dat is de kloof die ertoe doet: agents die wachten tot ze gevraagd worden, zijn tooling; agents die zelf dingen opmerken, zijn leverage. Het dichten van deze kloof vereist een persistent begrip van wat het bedrijf doet en agents die bereid zijn actie te ondernemen zonder dat ze worden opgeroepen. Dat is het moeilijke gedeelte, en dat is nog steeds niet opgelost door QM, en eerlijk gezegd, door niemand.
Conclusie
Voor wat het waard is: QM is goed gebouwd door mensen die het probleem goed begrijpen. Ik ben benieuwd waar het naartoe gaat. Maar op dit moment heeft het nog een lange weg te gaan. En dat geldt voor de hele categorie.
YC's QM kreeg 12k sterren in een week. Het lost het probleem nog steeds niet op.
Ik heb de multi-agent harness van YC geïnstalleerd in de week dat deze werd gelanceerd. Hier is wat ze goed hebben gedaan, wat iedereen verkeerd begreep en de kloof die nog steeds bestaat.
Op 1 augustus 2026 lanceerde YC 'QM', hun interne multi-agent harness, en binnen een week behaalde het 12.000 sterren. Ik heb het voor mijn team op een VPS geïnstalleerd, en het viel me op dat het angstwekkend veel lijkt op wat wij met Zodus hebben gebouwd.
Deze tekst is mijn visie op wat QM goed heeft gedaan en waar het tekortschiet.
Een korte inleiding
Om te beginnen: QM is een oprecht goede tool en je zou het moeten proberen. Het is een agentic harness die iedereen in een organisatie zijn eigen OpenClaw-achtige agent geeft tegen een fractie van de kosten, met als extra voordeel een gedeelde context.
Het verhaal erachter is simpel: het beheren van zoveel OpenClaw-instanties werd voor YC te hectisch (en waarschijnlijk te duur), dus bouwden ze hun eigen tool om dit beter aan te pakken.
Het probleem
Het probleem is vrij eenvoudig. Elke OpenClaw-instantie heeft zijn eigen machine nodig. Natuurlijk kun je meerdere agents op één box draaien, maar dan ontstaan er nieuwe vragen:
- Hoe beheer je het geheugen?
- Hoe houd je bestanden geïsoleerd?
- Hoe zorg je ervoor dat een agent niet uit zijn sandbox "ontsnapt"? (Ik kijk hierbij naar OpenAI, Anthropic en Meta 👀)
Zelfs als je een '1000x agentic engineer' bent, is het bouwen van eigen infrastructuur iets dat constant onderhouden moet worden. Met het tempo waarin OpenClaw en Hermes worden uitgebracht, is dat een enorme uitdaging.
De oplossing
In theorie is de oplossing simpel: bouw je eigen primitieven rond de agentic loop en voeg deze vervolgens samen tot iets dat schaalt op organisatieniveau. Dat is precies wat YC heeft gedaan. Ze hebben alles gebouwd wat een cloud-harness nodig heeft:
- Een cron-systeem;
- Skill-opslag en bestandsopslag;
- Connectors voor belangrijke tools (Slack, GitHub, Notion);
- Compatibiliteit met gevestigde harnesses zoals Pi, OpenCode en Codex.
Wat is dan het probleem?
Er zijn twee zaken die nog niet opgelost zijn.
Ten eerste weet niemand wat QM nu eigenlijk precies is. Het werd een week voor Buzz gelanceerd, waardoor het beeld ontstond dat QM, net als Buzz, een plek was waar agents samenkwamen. De realiteit is echter het tegenovergestelde: QM is de host waarop agents leven, niet de plek waar ze zich verzamelen. Eén lanceerbericht was niet genoeg om dit onderscheid duidelijk te maken.
Ten tweede is QM niet proactief en lost het het contextprobleem niet op. Het werkt alleen als je er actief mee blijft werken via het webportaal of door de agent actief te taggen in Slack. De agent wacht op jou.
Dat is de kloof die ertoe doet: agents die wachten tot ze gevraagd worden, zijn tooling; agents die zelf dingen opmerken, zijn leverage. Het dichten van deze kloof vereist een persistent begrip van wat het bedrijf doet en agents die bereid zijn actie te ondernemen zonder dat ze worden opgeroepen. Dat is het moeilijke gedeelte, en dat is nog steeds niet opgelost door QM, en eerlijk gezegd, door niemand.
Conclusie
Voor wat het waard is: QM is goed gebouwd door mensen die het probleem goed begrijpen. Ik ben benieuwd waar het naartoe gaat. Maar op dit moment heeft het nog een lange weg te gaan. En dat geldt voor de hele categorie.
Groetjes,