Agentnative le framework ou lagent et linterface p
|

AGENT-NATIVE : le framework où l’agent et l’interface partagent le même état

⏱️ Temps de lecture estimé : 3 minutes

https://github.com/builderio/agent-native

📌 AGENT-NATIVE est un framework TypeScript open source pour construire des applications où un agent et une interface React travaillent sur la même base, les mêmes actions et le même état d’application.

Quand on embarque un agent dans un produit existant, le problème n’est presque jamais le modèle. C’est le contrat entre les deux. L’agent appelle des outils, l’interface appelle des handlers, et les deux vivent chacun de leur côté. Agent-Native supprime l’écart en faisant de l’action l’unique source de vérité : une opération s’écrit une fois dans un fichier actions/, puis réapparaît partout ailleurs.

Un defineAction() suffit. Le hook React useActionQuery("hello", { name: "Alex" }) et l’appel de l’agent comme outil partent de la même fonction, avec le même schéma zod, la même validation, les mêmes permissions. Le framework monte en plus le transport HTTP, une commande CLI (pnpm action nom), un outil MCP et un outil A2A pour les autres applications du workspace. Cinq ou six points d’entrée, une seule implémentation à maintenir. C’est la partie que je trouve convaincante : elle attaque exactement la logique dupliquée qui fait dérailler un agent dès que le produit grossit.

Les données obéissent à la même logique. Tout l’état — métier comme interface — vit dans PostgreSQL via Drizzle, avec PGlite en local pour développer sans base à monter. L’UI écrit une clé navigation à chaque changement de route, l’agent la lit avant d’agir : il sait quel fil ou quel graphique vous regarde, sans que vous rédigiez le contexte à la main. Quand l’agent écrit, la modification arrive en SSE sur /_agent-native/events, avec un repli polling pour les hébergeurs stateless. Vous ne construisez pas de couche de synchronisation, elle est déjà là.

Interface de l'application Mail d'Agent-Native, avec l'agent qui priorise les messages

Le framework se lit en trois couches. Core est le socle : actions, base, authentification, état applicatif, exécution de l’agent. Toolkit regroupe les pièces d’interface réutilisables — éditeurs, partage, collaboration, réglages. Templates sont des applications complètes, forkables. La galerie en aligne plus de dix : Clips pour enregistrer son écran, Mail pour trier une boîte de réception, Analytics pour poser des questions à ses données, Plans pour dessiner des maquettes, Dispatch comme poste de pilotage avec boîte partagée et coffre de secrets. On démarre minimaliste avec npx --yes @agent-native/core@latest create mon-agent --standalone --template chat, puis on greffe ce qui manque.

Quelques points que je garde en tête :

  • 🧱 Une action, six surfaces : hook React, outil d’agent, HTTP, CLI, MCP, A2A
  • 🔗 Votre modèle, votre runtime : OpenAI Agents, Claude Agent SDK, Vercel AI SDK, AG-UI ou le vôtre
  • 🔒 SQL en lecture seule pour l’agent par défaut, les écritures passent par des actions typées
  • 🌐 PostgreSQL chez vous, sur n’importe quel hôte compatible Nitro : Workers, Netlify, Vercel, Deno, Lambda

Ma réserve porte ailleurs. Le dépôt est né en mars 2026 et dépasse déjà les 6 500 commits : la documentation est immense et l’API bouge vite. Même si le multi-tenant et les rôles sont câblés, l’authentification reste un vrai chantier de configuration. Pour qui sort d’un prototype, c’est un investissement, pas une installation.

Sources

Publications similaires

Laisser un commentaire