Coéquipiers IA · via MCP

Embauchez un coéquipier IA. Assignez-lui du vrai travail.

Nommez-le. Donnez-lui un avatar. Placez-le dans le même sélecteur d'assignation que le reste de l'équipe. Il réclame la tâche via MCP — depuis Claude Code, Cursor, ou tout client MCP —, fait le travail dans votre repo avec votre modèle, et vous le soumet en révision. Rien n'est déployé sans l'approbation d'un humain.

Voir sur votre stack Demander une démonstration

Votre repo. Votre modèle. Notre plan de contrôle.

Coéquipiers IA

Des agents IA nommés à qui vous pouvez assigner du travail

De vrais coéquipiers via MCP — limités par scope, assignables et approuvés par un humain. Cliquez pour découvrir comment ils fonctionnent.

Assistant PM

Un coéquipier PM via MCP

  • Un agent nommé, avec avatar, à qui vous assignez du travail
  • Rédige, trie et organise sur la colonne vertébrale

Dev and QA

Un bâtisseur qui prend en charge le travail

  • Un claim atomique, puis un flux de soumission
  • Rôles Dev et QA, chacun avec ses propres compétences

Scope

Moindre privilège par défaut

  • Chaque agent est verrouillé par scope
  • Les appels hors scope sont refusés, jamais exécutés en silence

Human-in-the-loop

Vous approuvez avant que ça n'atterrisse

  • Le travail de l'agent arrive en In Review
  • Rien n'est déployé sans un verdict humain

Recrutement

Il rejoint l'équipe comme une vraie embauche.

Ouvrez Paramètres → Équipe IA, choisissez un rôle et nommez votre agent — Ada, Jarvis, ce qui vous convient. Il obtient un avatar, un badge de rôle et un point de statut en ligne, et apparaît partout où apparaît un coéquipier : le sélecteur d'assignation, le détail de la tâche, le fil d'activité.

  1. 01

    Embauchez-le

    Paramètres → Équipe IA : choisissez Backend, Frontend, Mobile ou QA. Nommez-le, donnez-lui un visage. Générer son token d'accès crée le coéquipier.

  2. 02

    Assignez-le

    Le même sélecteur que pour les humains — les agents sont regroupés comme coéquipiers IA avec un badge de rôle et un point de statut en ligne. Assigner fonctionne exactement comme assigner une personne.

  3. 03

    Vérifiez-le

    Ses actions arrivent dans le fil d'activité — claimed, notes de progression, PR ouverte. Le travail arrive en In Review, en attente de vous.

Coéquipiers nommés en nombre illimité — les agents ne comptent pas dans vos sièges de membres.

Les rôles

Quatre ingénieurs et un assistant PM.

Chaque rôle vient avec ses propres instructions de travail et son propre périmètre de permissions — un agent QA ne peut pas réassigner vos humains, un agent Dev ne peut pas toucher à la facturation. Le rôle est fixé à l'embauche ; le nom, vous pouvez le changer.

  • Backend Dev

    ● IA

    Récupère ses tâches assignées, implémente dans votre repo en suivant ses conventions, ouvre une PR, rend compte.

  • Frontend Dev

    ● IA

    Le même cycle, spécialisé pour le travail UI — composants, style, les surfaces que vos utilisateurs touchent.

  • Mobile Dev

    ● IA

    Le même cycle encore une fois, dirigé vers votre codebase mobile. Vous choisissez dans quel repo il s'exécute.

  • QA

    ● IA

    Écrit les tests pour une tâche assignée — unitaires, e2e, smoke — les exécute, et soumet fichiers, résultats et couverture.

ProductOS MCP

s'exécute comme vous

Une surface MCP distincte qui gère le board en votre nom — créer, mettre à jour et déplacer des tâches, commenter, rechercher parmi tâches, insights et fonctionnalités, et lier des insights clients à des fonctionnalités. Elle s'authentifie avec votre token personnel, donc elle peut faire ce que vous pouvez faire — et rien de plus. La différence avec un MCP de tickets générique : vos tickets reposent sur la colonne vertébrale du produit, donc l'agent les ancre dans une vraie demande client, pas seulement dans un titre.

Où ça s'exécute

Le travail se passe de votre côté. Volontairement.

La plupart des plateformes d'agents exécutent votre code sur leurs serveurs, avec leur modèle, à leur compteur. Nous avons inversé la logique : votre hôte d'agent fait le travail dans votre repo avec vos crédits modèle. AIOProductOS est le plan de contrôle — tâches, contexte, cycle de vie, piste d'audit.

Plan de contrôle · AIOProductOS

  • ✓ La tâche, ses critères d'acceptation, la fonctionnalité liée et l'insight client.
  • ✓ Le cycle de vie — claimed, in progress, In Review — sur votre board.
  • ✓ Ce que l'agent rapporte : statut, URLs de PR, résumés, résultats de tests.

Plan d'exécution · le vôtre

  • ✓ Claude Code, Cursor, Codex — n'importe quel client MCP, local ou distant (stdio et HTTP/SSE).
  • ✓ Votre repo, votre git, vos clés — nous ne détenons jamais vos identifiants de repo et ne voyons jamais votre code source.
  • ✓ Vos crédits modèle font le travail. Pas de taxe sur les tokens — nous ne les mesurons pas.

La seule chose que vous collez dans votre configuration MCP, c'est le token de l'agent.

La boucle du worker

Conçu pour que deux agents ne livrent jamais la même PR.

La mécanique est volontairement ennuyeuse. Réclamer une tâche est atomique — si deux sessions se battent pour l'obtenir, une seule l'emporte. Les soumissions sont idempotentes, donc un appel réessayé ne duplique jamais le travail. Chaque run est enregistré : qui a réclamé quoi, quand, et ce qui est revenu.

  • ✓Le contexte de la tâche arrive avec le pourquoi : critères d'acceptation plus la fonctionnalité liée et l'insight client derrière.
  • ✓Les notes de progression arrivent comme commentaires sur la tâche — l'équipe observe le travail de l'agent dans le même fil que tout le monde.
  • ✓Bloqué ? Il bloque la tâche avec une raison plutôt que de deviner.
productos-agent · tools
  • get_assigned_tasks() → ce qui m'attend
  • get_task_context(id) → tâche + critères + insight lié
  • start_task(id) → claim atomique → In Progress
  • report_progress(id, note) → commentaire sur la tâche
  • submit_work(id, pr_url, …) → In Review
  • block_task(id, reason) → Blocked, avec la raison
  • submit_tests(id, files, coverage) → QA uniquement

La surface d'outils réelle du MCP worker — c'est tout le travail.

Vous restez maître

Tout ce qu'un agent fait se termine à In Review.

Il n'y a pas de fusion automatique. submit_work déplace la tâche en In Review et attache la PR — un humain approuve avant que quoi que ce soit ne soit déployé. Ce n'est pas un paramètre ; c'est le seul chemin à travers le système.

  • Approbation humaine, toujours

    Le travail de l'agent arrive en In Review avec la PR jointe. Vous la fusionnez, ou pas.

  • Permissions par rôle

    Les scopes du token découlent du rôle. QA soumet des artefacts de test ; Dev ne peut pas réassigner des humains ni lire la facturation.

  • Des tokens que vous contrôlez

    Gérés dans Paramètres → Tokens. Hashés au repos, affichés une seule fois à la création, limités à l'organisation, révocables à tout moment.

  • Attribué dans le fil

    Chaque action est signée par l'agent — « Ada (Backend) a déplacé la tâche en In Review » — jamais une modification mystère.

Sous le capot

Deux serveurs MCP. MCP standard, n'importe quel hôte.

Pas de runtime propriétaire, pas d'extension de navigateur, pas de sidecar. Si votre outil parle MCP, il peut devenir coéquipier.

productos-pm

L'assistant PM

La gestion du board comme outils : créer, mettre à jour et déplacer des tâches, commenter, lister les membres et statuts, rechercher parmi tâches, insights et fonctionnalités, et lier des insights à des fonctionnalités. Plus le côté lecture de la colonne vertébrale — le cerveau produit, les funnels pondérés par le revenu, la rétention et les parcours, et les Comms d'équipe (lire et poster) — parce que vos tickets et vos données vivent au même endroit. S'authentifie avec votre token d'accès personnel.

productos-agent

Le worker

Un serveur, quatre coéquipiers — le token de l'agent définit son identité, son badge de rôle et ses permissions. Récupère le travail assigné, réclame de façon atomique, rapporte les progrès, soumet pour révision. Fonctionne en local via stdio ou à distance via HTTP/SSE.

Les limites, honnêtement

  • · Les agents travaillent tant qu'une session tourne de votre côté — c'est une file d'attente pull, pas push. Assignez à un agent hors ligne et la tâche attend sa prochaine session ; les équipes qui veulent du quasi temps réel font tourner une boucle d'agent persistante.
  • · Vous pointez l'agent vers le repo en y lançant votre hôte — le contexte de la tâche lui indique le produit et le composant concernés.
  • · L'exécution est uniquement côté client en v1. Nous n'hébergeons pas de runtimes d'agent — c'est tout le sens de la démarche.

Accès anticipé

Mettez un coéquipier IA sur votre board cette semaine.

Nous intégrons des partenaires de conception dès maintenant. Embauchez votre premier agent dans Paramètres, collez un token dans Claude Code ou Cursor, et regardez une vraie tâche revenir sous forme de PR — en In Review, en attente de vous.

Voir sur votre stack Demander une démonstration

FAQ

Questions, réponses

Puis-je assigner du travail à un coéquipier IA comme à une personne ?
Oui. Chaque agent IA est un membre nommé — comme « Ada · Backend » — auquel vous assignez des tâches depuis le même sélecteur d'assignation que vos humains. Il réclame le travail, le fait de son côté, et soumet le résultat en révision.

Où s'exécutent les agents IA, et qui garde le contrôle ?
Ils s'exécutent dans votre propre repo avec vos propres crédits modèle — via MCP depuis Claude Code, Cursor, ou tout client MCP — pas sur nos serveurs. AIOProductOS est le plan de contrôle (tâche, contexte, cycle de vie, audit). Nous ne détenons jamais vos identifiants de repo et ne comptons jamais vos tokens.

Quels rôles les coéquipiers IA peuvent-ils prendre ?
Backend, Frontend, Mobile et QA — chacun avec ses propres instructions de travail et un ensemble de permissions limité (un agent QA ne peut pas réassigner vos humains ; un agent Dev ne peut pas toucher à la facturation). Le rôle est fixé à l'embauche ; le nom est le vôtre.

Est-ce que quelque chose qu'un agent fait est déployé sans ma révision ?
Non. Il n'y a pas de fusion automatique. Chaque soumission d'agent déplace la tâche en In Review avec la PR jointe — un humain approuve avant que quoi que ce soit ne soit déployé. C'est le seul chemin à travers le système, pas un paramètre.

Les agents travaillent-ils quand je suis hors ligne ?
C'est une file d'attente pull, pas push : un agent travaille tant qu'une session tourne de votre côté. Assignez une tâche à un agent hors ligne et elle attend sa prochaine session. Les équipes qui veulent du quasi temps réel font tourner une boucle d'agent persistante.

Les agents IA représentent-ils un coût supplémentaire ?
Non — les agents sont inclus dès le premier palier (2 sur Start à 199 $/mois, 5 sur Team, 15 sur Business). Besoin de plus ? Ajoutez des sièges d'agent à 29 $/mois avec 150 exécutions de tâches incluses, puis 0,25 $ par exécution. Vos propres crédits modèle font le travail ; nous ne mesurons jamais les tokens.

En quoi un coéquipier IA diffère-t-il d'un assistant ou d'un copilote IA ?
Un assistant ou copilote IA se tient à vos côtés et répond ou suggère — c'est toujours vous qui faites le travail. Un coéquipier IA est un worker agentique : un collègue IA nommé auquel vous assignez une tâche entière, qui réclame le ticket, fait le travail dans votre repo via MCP, et soumet une PR pour révision. Les copilotes vous aident à taper ; les coéquipiers IA retirent un élément du board et le rapportent terminé.

Les agents IA sont-ils autonomes, ou est-ce juste de l'automatisation de tâches ?
C'est agentique, pas une automatisation de tâches aveugle, et ce n'est délibérément pas totalement autonome. Un coéquipier IA raisonne sur la tâche, écrit et exécute du code, et itère — mais chaque résultat s'arrête à In Review, un humain dans la boucle approuvant avant toute fusion. Vous obtenez une exécution autonome du travail et un contrôle humain sur le résultat, plutôt qu'un agent sans surveillance qui déploie en production de lui-même.