Essai · architecture d’agents

Grok Bot n’est pas un harness de coding. Voilà ce que ça change.

Cette page répond à une question précise : qu’est-ce qu’un harness classique (Claude Cowork, OpenAI Codex, GitHub Copilot coding agent), et en quoi l’architecture publique de Grok Bot s’en distingue — sans nier les recouvrements.

Lecture guidée des docs publiques · septembre 2026

1. La question que cette page tranche

Les produits d’agents se ressemblent de loin. Tous enveloppent un modèle avec des outils, une boucle de travail, et souvent un bac à sable. Dire « Grok Bot est un agent » ne dit donc presque rien. La distinction utile est plus étroite : qui tient la boucle, sur quelle machine, et pour quel objet de travail.

Les guides publics de x.ai décrivent Grok Bot comme un agent avec un ordinateur dans le cloud — bureau, système de fichiers, terminal, applications — que l’on interroge en chat, que l’on programme par routines, et que l’on peut chaîner avec d’autres bots. Dans le cas du software engineering, ce bot n’est pas le runtime qui écrit le code. Il prépare le prompt, puis délègue la construction à un Cursor cloud agent. C’est une boucle externe autour d’un harness interne.

Cowork, Codex et Copilot coding agent restent, chacun à sa manière, des harness : une session d’agent (parfois plusieurs sous-agents) centrée sur un dossier, un dépôt, ou un ticket. Ils savent déjà beaucoup de choses que l’on attribue trop vite à Grok Bot (MCP, skills, plannings). La différence n’est pas « l’un a des outils, les autres non ». C’est le produit d’organisation persistante — ordinateur partagé, flotte de spécialistes, routines toujours allumées — versus le runtime de tâche.

Périmètre. Les affirmations ci-dessous s’appuient sur des pages publiques (guides x.ai, docs Anthropic, OpenAI et GitHub). Pas de détails de cabinet privé, pas de métriques internes présentées comme des faits de ce site.

2. Ce qu’est un harness classique

Un harness, dans le vocabulaire des agents de coding, est le runtime qui entoure le modèle. OpenAI le dit sans détour à propos de Codex : le harness gère l’état de conversation, appelle les outils, applique le sandbox et la politique d’approbation, et enchaîne les tours jusqu’à ce que la tâche soit considérée comme terminée. Ce n’est pas « le LLM ». C’est tout ce qui transforme un endpoint de génération en agent.

Le motif partagé, chez Cowork, Codex et Copilot, ressemble à ceci :

  1. un objectif (prompt, issue, dossier, rapport à produire) ;
  2. un contexte borné (repo, workspace, dossiers autorisés) ;
  3. des outils (fichiers, shell, navigateur, MCP, skills) ;
  4. un sandbox et des approvals ;
  5. une boucle « raisonner → appeler un outil → observer → continuer » jusqu’à un livrable.

La session est en général une unité de travail. On peut paralléliser des sous-agents ou lancer plusieurs jobs, mais le produit reste centré sur l’exécution d’une tâche, pas sur une petite organisation qui vit toute la journée sur la même machine.

Harness classique Une session unique enveloppe le modèle avec outils, sandbox, approvals et une boucle de tâche. HARNESS CLASSIQUE Utilisateur objectif Une session d’agent modèle + outils + contexte sandbox · approvals · boucle Codex · Copilot · Cowork Livrable PR, fichier, rapport
Le harness classique enveloppe une session. Il n’est pas « moins agent » — il est borné à une tâche.

Claude Cowork — agent de knowledge work

Cowork est le produit Anthropic pour déléguer du travail de connaissance, pas du software engineering de premier ressort. La doc officielle le dit clairement : Claude Code sert à écrire, déboguer et livrer du code ; Cowork sert à la recherche, l’analyse, la création de documents et les tâches multi-étapes hors coding. L’approche agentique est la même que Claude Code, exposée dans l’app desktop (web et mobile en bêta).

Concrètement, tu donnes un objectif. Cowork travaille dans les dossiers et les outils que tu as choisis, peut ouvrir un navigateur intégré, découper le travail en sous-agents, et livrer un fichier à relire. Les tâches planifiées existent (horaire, quotidien, hebdo, jours ouvrés, ou à la demande). MCP, skills et plugins font partie du même socle Claude. Le laptop fermé, une tâche cloud peut continuer — mais l’accès aux dossiers locaux ou au navigateur desktop suppose encore, selon l’aide Anthropic, que l’app desktop soit joignable pour ces surfaces-là. Cowork n’est pas vendu comme une « org » de bots spécialistes qui s’écrivent entre eux toute la journée. C’est un agent de knowledge work, éventuellement assisté de sous-agents, sur un périmètre de fichiers et de connecteurs.

OpenAI Codex — harness de coding terminal / cloud

Codex est le coding agent d’OpenAI. Le CLI travaille contre le dépôt local : lire, éditer, lancer les outils déjà installés, avec sandbox OS et politique d’approbation. Codex Cloud exécute des tâches en arrière-plan dans un conteneur isolé, puis tu ramènes le diff ou tu ouvres une PR. Le post Unrolling the Codex agent loop décrit exactement le cœur du harness : l’utilisateur, le modèle, et les outils (shell Codex, outils de l’API, MCP utilisateur) dans une boucle de tours. OpenAI a même publié ce harness comme plateforme (CLI, SDK, app-server). Skills, plugins, sous-agents, MCP et passage local → cloud existent. L’unité reste le thread de coding, repo-centré, pas un ordinateur de bureau persistant partagé par une flotte de personas.

GitHub Copilot coding agent — harness natif GitHub

GitHub documente désormais ce produit comme Copilot cloud agent (l’ancien nom « coding agent » désigne le même geste : issue → agent asynchrone → branche / pull request). L’agent tourne dans un environnement éphémère alimenté par GitHub Actions. Tu l’assignes depuis une issue, VS Code, le panneau Agents, ou une automatisation. Il explore le repo, planifie, code, lance tests et linters, et ouvre une PR. MCP, custom agents, skills, hooks et instructions de repo sont prévus. Copilot peut aussi travailler en mode agent dans l’IDE, en local et en synchrone. C’est un harness de coding GitHub-natif. Il n’est pas un ordinateur cloud personnel avec desktop et sessions web déjà connectées.

3. Les briques d’architecture de Grok Bot

Le guide Grok Bot 101 (Matt Palmer) pose la définition courte : Grok Bot is an agent with a computer. Le guide Grok Bot for Engineering (Lingxi Li) décrit comment une flotte de bots spécialistes pilote des Cursor cloud agents. Les briques ci-dessous viennent de ces deux textes, pas d’un reverse-engineering.

Ordinateur cloud persistant

Desktop, filesystem, terminal, apps. On peut l’utiliser comme un bureau distant. Le même ordinateur est joignable depuis le téléphone et le desktop. Les identifiants survivent à la session : un bot Marketplace peut chercher sur Facebook parce que Facebook est déjà connecté.

Persona et réglages

Un bot est un jeu d’instructions. Les settings publics se réduisent à trois champs (nom, titre, description), plus le prompt de workflow. On le définit en chat ou dans Settings. Palmer donne l’exemple d’un bot DevRel qui lit des bookmarks, rédige un prompt, attend une approbation, puis lance un Cursor cloud agent.

Skills, plugins, connecteurs MCP

Grok Bot prend les mêmes MCP servers, plugins et skills que Cursor. Plusieurs comptes par service sont possibles (mail perso et pro, plusieurs Slack). Ce n’est pas unique à Grok Bot — Cowork, Codex et Copilot exposent aussi MCP / skills — mais c’est le socle qui permet au bot de lire Slack, Notion, GitHub, le calendrier, etc.

Trois façons de parler au bot

Chat. Routines et déclencheurs (le bot pose son propre planning, ou écoute Slack / une PR GitHub). Les autres bots : ils peuvent s’envoyer des messages et se déclencher mutuellement.

Permissions et agent de revue

Un ordinateur déjà connecté à Amazon peut, en principe, acheter. Le garde-fou public est un trio : permissions en langage naturel (Settings → Agent), un agent de revue distinct qui autorise, bloque ou escalade, et des listes allow/block. Les règles sont un prompt, pas du JSON. Le travail reste dans un environnement isolé. Palmer insiste aussi sur le partage d’auth : si un bot se connecte à un site, les autres y ont accès.

Chaînes multi-bots

Les bots sont traités comme des spécialistes, avec mémoire et contexte limités. Ils se parlent, peuvent vivre dans un groupe, et une routine peut router une demande jusqu’à ce que le travail soit fini. Le guide engineering ajoute un bot d’ops (onboarding, postmortems, alignement quotidien) qui ne code pas.

Handoff vers les coding cloud agents

Palmer : l’agent de boucle externe rassemble le contexte (Slack, Notion, GitHub, docs), rédige le prompt propre, et l’envoie à un Cursor cloud agent pour la boucle interne. « Grok Bot is not writing the code. It is creating the same prompts I would, then sending them to a specialized coding harness that lives inside Cursor. » Lingxi Li décrit la même séparation à l’échelle d’une flotte : chaque bot ingénieur lance des cloud agents, lit les transcripts, exige des preuves (screenshots avant/après), file des follow-ups, et peut viser un worker privé (Mac mini, VPN, simulateur iOS).

Boucle externe Grok Bot et boucle interne Cursor Grok Bot prépare le contexte et le prompt, puis délègue le coding à un Cursor cloud agent qui renvoie PR et preuves. BOUCLE EXTERNE · GROK BOT Ordinateur cloud persistant desktop · filesystem · terminal · apps déjà connectées Persona / skills MCP · plugins Routines chat · events · bots Spécialistes chaînes multi-bots Revue allow / block prompt propre BOUCLE INTERNE · HARNESS DE CODING Cursor cloud agent repo · outils · sandbox · tests · screenshots · pull request Le bot relit le transcript, vérifie la preuve, relance ou interrompt.
Grok Bot orchestre. Le harness de coding (ici Cursor) exécute. Les deux boucles ne se confondent pas.

Le guide engineering insiste sur la boucle de feedback fermée : lancer l’agent ne suffit pas. Il faut un signal de « done » que le bot peut juger tout seul (screenshot, preuve avant/après, CI, commentaires de review). Sans ça, tu redeviens le dispatcher humain. Avec ça, le bot peut débloquer un run coincé, exiger une correction visuelle, et ne te rendre le travail que lorsqu’il passe la barre que tu as écrite.

4. Recouvrement et différences

Si tu listes les features une par une, beaucoup se recoupent. MCP n’est pas un distinguo. Les schedules non plus : Cowork a des tâches récurrentes, Copilot a des automations, Codex a des surfaces planifiées. Les sous-agents et custom agents existent chez Cowork et Copilot. Codex et Copilot savent ouvrir des PR. Grok Bot lui-même s’appuie sur un harness de coding (Cursor) plutôt que de le remplacer.

Dimension Cowork Codex Copilot coding agent Grok Bot
Objet Knowledge work (fichiers, docs, recherche) Coding repo-centré (CLI / cloud / IDE) Coding GitHub-natif (issue → PR) Agent + ordinateur persistant ; org de bots
Machine Dossiers locaux et/ou session cloud ; navigateur intégré Workspace local sandboxé, ou conteneur cloud éphémère Environnement Actions éphémère, un repo à la fois Desktop cloud persistant, logins partagés entre bots
Boucle Tâche multi-étapes, sous-agents possibles Agent loop outils + sandbox + approvals Session cloud asynchrone, custom agents possibles Boucle externe (contexte, routines) + handoff interne
Planning Oui (tâches récurrentes Cowork) Oui sur certaines surfaces Codex / ChatGPT Oui (automations Copilot) Oui (routines, triggers, bots qui se réveillent)
MCP / skills Oui Oui Oui Oui (aligné Cursor)
Multi-agent « org » Sous-agents dans une tâche, pas une flotte persistante Sous-agents dans un thread de coding Custom agents spécialisés, toujours repo/PR Bots spécialistes qui se parlent, ops, revue séparée
Qui code Pas le produit de coding (Claude Code à côté) Le harness lui-même Le harness lui-même Le harness délégué (Cursor cloud agent)

Ce qui se recouvre

Tous sont des agents outillés. Tous (à des degrés divers) ont des connecteurs, des instructions réutilisables, une politique d’accès, et une boucle jusqu’à un livrable. Cowork et Grok Bot peuvent tous les deux travailler quand tu n’es pas devant l’écran, et tous les deux savent planifier. Codex et Copilot sont tous les deux des harness de coding cloud, comparables au Cursor cloud agent que Grok Bot appelle — pas à Grok Bot lui-même. Copilot documente même des custom agents spécialisés (frontend, docs, tests). Dire que « seul Grok Bot a des spécialistes » serait faux.

Ce qui diverge vraiment

Trois écarts tiennent dans les docs, une fois les features listées mises de côté.

1. La machine n’est pas la même. Codex et Copilot te donnent un sandbox de coding, souvent éphémère, borné au workspace ou au repo. Cowork te donne des dossiers choisis, un navigateur à lui, parfois l’écran. Grok Bot te donne un ordinateur cloud qui reste là, avec un vrai desktop et des sessions web déjà authentifiées. Palmer le compare à envoyer un message à un collègue qui a le même accès machine que toi.

2. L’unité de produit n’est pas la session, c’est l’org. Cowork, Codex et Copilot savent déléguer à l’intérieur d’une tâche. Grok Bot est décrit comme une collection de bots qui vivent en parallèle, se parlent, ont des domaines (mobile, desktop, infra, harness), un ops bot, des 1:1 matinaux, des audits de nuit. Ce n’est pas qu’un marketing de « team » : le guide engineering en fait le mécanisme pour tenir plus de travail que ce qu’une fenêtre de contexte unique peut porter.

3. Grok Bot refuse d’être le harness de coding. Palmer le formule comme une hygiène de contexte : si le même agent lit Slack, débat du spec, puis code, il arrive dans la boucle interne avec un contexte sale. La boucle externe prépare un prompt propre ; le harness interne (Cursor) construit. Codex et Copilot sont ce harness interne. On peut évidemment les piloter depuis un autre agent, mais ce n’est pas le produit que vendent leurs pages d’accueil.

5. Quand utiliser quoi

Codex CLI / Codex Cloud
Le travail est un changement de code dans un dépôt, tu veux la boucle d’outils sous les yeux (terminal) ou un job cloud dont tu récupères le diff. Sandbox et approvals sont le sujet. Reste sur Codex.
Copilot coding agent (cloud agent)
Le travail est déjà une issue GitHub, tu veux une PR native, des logs Actions, et que l’équipe review dans GitHub. Custom agents et automations suffisent si le périmètre est un repo à la fois.
Claude Cowork
Le livrable n’est pas une PR : mémo, deck, tableur, revue de contrats, briefing hebdo à partir de Drive et Slack. Tu veux borner Claude à des dossiers et des connecteurs, avec un navigateur intégré. Claude Code reste le cousin pour le coding.
Grok Bot
Tu as besoin d’un ordinateur qui reste allumé, de workflows qui ne tiennent pas dans une session (veille, CRM, ops, relances), de plusieurs spécialistes qui se parlent, et — pour le software — d’une boucle externe qui nourrit des Cursor cloud agents avec preuves. Le bot n’est pas un remplaçant de Codex ou Copilot ; c’est l’étage au-dessus du harness de coding que tu as choisi (ici, Cursor).

En pratique, ces produits se composent. Un ingénieur peut garder Copilot sur les tickets GitHub, Cowork sur le reporting, et Grok Bot comme dispatcher qui prépare les prompts Cursor. La question n’est pas « lequel est l’agent », c’est à quel étage tu places l’orchestration.

6. Sources

Tous les liens ci-dessous sont des pages publiques. Les formulations entre guillemets anglaises sont celles des guides x.ai.