Pour les agents

Agents

Un agent devrait pouvoir remettre à quelqu’un une base de données qui fonctionne sans qu’un humain ouvre un tableau de bord. Voici tout ce que nous publions pour cela.

01

Le point de départ

Une part croissante des projets est démarrée par un agent et seulement relue par une personne. Cet agent a besoin de trois choses de la part d’un fournisseur de bases de données : un moyen de découvrir ce qu’est le produit, un moyen d’agir sur le compte, et un moyen de rendre à l’humain quelque chose qui marche.

Nous publions les trois. Rien de tout cela n’est une surface de démonstration : le serveur MCP et la CLI appellent la même API que le tableau de bord, avec les mêmes permissions et la même piste d’audit.

02

Découverte

  • -/llms.txt - l’index qu’un assistant lit en premier et qui renvoie vers tout le reste
  • -/agents.md - des instructions exécutables pour provisionner une base pour le compte d’une personne
  • -/pricing.md, /about.md, /changelog.md - des miroirs markdown des pages marketing, générés depuis les mêmes sources que le HTML
  • -/webmcp.md - la surface d’outils navigateur que publie le tableau de bord
  • -Le site de documentation publie son propre index et un corpus complet pour la recherche
  • -Un flux RSS du changelog, pour qu’un agent guettant les ruptures n’ait pas à interroger une page

03

Agir sur un compte

Deux surfaces, une seule API. Le serveur MCP convient quand l’agent vit dans un éditeur ou un client de discussion ; la CLI convient quand l’agent dispose d’un shell.

Les deux s’authentifient avec une clé d’API limitée à une organisation, ou via une connexion par appareil que l’humain approuve dans un navigateur. Un agent n’a jamais besoin d’un mot de passe, et ne devrait jamais en recevoir un.

# In a shell
capydb login
capydb create --name my-app
capydb env pull

# In an editor, over MCP
npx -y @capydb/mcp

04

Les agents dans le navigateur

Le tableau de bord publie une surface d’outils aux agents navigateur qui la prennent en charge, afin qu’un agent pilotant la page agisse via des outils nommés plutôt qu’en devinant le DOM. Les outils destructeurs demandent confirmation par la même interface qu’une personne verrait.

La surface publiée est documentée dans /webmcp.md, et c’est délibérément un sous-ensemble : les restaurations qui écrasent la production ne sont pas exposées à un agent du tout.

05

Garde-fous

  • -Le SQL destructeur via le serveur MCP exige la création préalable d’un point de restauration
  • -La restauration écrasant la production n’est exposée comme outil d’agent sur aucune surface
  • -Les clés d’API sont limitées à une organisation et révocables depuis le tableau de bord dès qu’une exécution dérape
  • -Les bases de preview ont une durée de vie, pour qu’une expérience ne devienne pas silencieusement une facture
  • -Chaque action d’un agent apparaît dans le journal d’audit de l’espace de travail, sous la clé qui l’a exécutée

06

Pourquoi c’est simple ici

Parce qu’il n’y a pas d’API de données propriétaire à apprendre. L’agent provisionne une cellule, obtient une URL PostgreSQL standard, puis utilise le pilote que le projet possède déjà. Tout ce qu’un agent sait déjà de Postgres se transpose sans changement, et c’est la différence entre une tâche qui réussit du premier coup et une qui demande trois allers-retours dans la documentation.