Aller au contenu principal
Série A2A · 2 / 4

Déployer un agent GAM et le rendre
découvrable en A2A

Du local au cloud : adk deploy agent_engine, l'auth managée (connecteur Agent Identity), l'Agent Registry, et un orchestrateur qui découvre puis délègue en A2A. Avec la page self-service « Connecter un agent ».

OA
OrbiAds Engineering
Publié le 30 juin 2026 · Lecture 12 min

Dans l'article 1, l'agent GAM tournait en local et la connexion OAuth était prouvée. Place à l'étape qui le rend utile à d'autres agents : le déployer dans le cloud et le rendre découvrable en A2A.

Déployer sur Vertex Agent Engine

Une seule commande empaquette l'agent et crée une ressource reasoningEngine dans Vertex AI Agent Engine (Agent Platform) :

adk deploy agent_engine \
  --project=PROJECT_ID --region=us-central1 \
  gam_sentinel

⚙️ Deux pièges qui font perdre du temps : installer google-cloud-aiplatform[agent_engines] (pour vertexai), et épingler opentelemetry==1.42.1 (les versions plus récentes cassent l'ADK).

Agent déployé dans l'Agent Platform
L'agent GAM déployé dans l'Agent Platform (Vertex AI Agent Runtime) — framework google-adk, région us-central1.

L'auth managée (connecteur Agent Identity)

Un agent déployé ne peut pas ouvrir un navigateur pour consentir. La voie propre est l'Agent Identity Auth Manager : un connecteur OAuth 3LO managé par Google. L'utilisateur consent une fois (dans le navigateur), Google stocke et rafraîchit les jetons et les injecte à l'agent — aucun code de refresh à écrire.

Tant qu'aucun utilisateur n'a consenti via le connecteur, l'agent renvoie Failed to retrieve credential. C'est normal — la preuve que le runtime fonctionne et que la porte d'entrée est l'autorisation utilisateur, pas un secret d'agent.

Agent Card + Agent Registry

Le déploiement sert l'Agent Card (/.well-known/agent-card.json, vue à l'article 1) et enregistre l'agent dans l'Agent Registry — l'annuaire des agents découvrables — en type CUSTOM. À partir de là, n'importe quel autre agent peut le retrouver et lui déléguer une tâche.

L'orchestrateur : découvrir puis déléguer

C'est le vrai moment « A2A ». Un orchestrateur (1) découvre l'agent GAM via une recherche dans le registre (registry_search_agents), puis (2) lui délègue via un RemoteA2aAgent qui lit sa carte et lui transmet la tâche (transfer_to_agent). La réponse remonte à l'orchestrateur. Deux agents qui dialoguent :

Communication A2A inter-agents
Communication A2A : l'orchestrateur découvre l'agent (registry_search_agents) puis lui délègue (transfer_to_agent) → réponse.

La page « Connecter un agent »

Côté OrbiAds, pas besoin de bricoler les identifiants à la main : une page self-service provisionne un client OAuth pour l'agent. On saisit un nom et l'URL de redirection ; OrbiAds renvoie un client_id et un secret affiché une seule fois.

Page « Connecter un agent »
Page « Connecter un agent » : on saisit un nom et l'URL de redirection de l'agent.
Client agent créé
Le client est créé : client_id + secret affichés une seule fois, à copier immédiatement.

L'URL de redirection du client doit correspondre au callback du connecteur Agent Identity, sinon le consentement échoue à l'exécution. La page affiche le gabarit exact à utiliser.

La suite

L'agent est déployé, découvrable, et un orchestrateur sait lui déléguer. Dans l'article 3, on compose un vrai cas métier multi-agents : un forecast et une reco de formats en parallèle, fusionnés en un plan d'optimisation.

Le code complet, prêt à cloner

Les 4 agents, le tutoriel pas à pas et les exemples — sur GitHub, sous licence MIT.

FAQ

Questions fréquentes

Comment déployer un agent ADK sur Vertex Agent Engine ?

Avec la commande adk deploy agent_engine. Elle empaquette le code de l'agent et crée une ressource reasoningEngine dans Vertex AI Agent Engine (Agent Platform). Pièges courants : installer google-cloud-aiplatform[agent_engines] (pour vertexai) et épingler opentelemetry==1.42.1 (compat ADK).

Comment un agent déployé s'authentifie-t-il sans navigateur ?

Via l'Agent Identity Auth Manager : un connecteur OAuth 3LO managé par Google. L'utilisateur consent une fois, Google stocke et rafraîchit les jetons et les injecte à l'agent — aucun code de refresh à écrire. Tant qu'un utilisateur n'a pas consenti, l'agent renvoie « Failed to retrieve credential » : c'est le comportement attendu, pas un bug.

Qu'est-ce que l'Agent Registry et l'auto-enregistrement CUSTOM ?

L'Agent Registry est l'annuaire où les agents se déclarent pour être découverts en A2A. adk deploy y enregistre automatiquement l'agent (type CUSTOM). Un autre agent peut alors le retrouver via une recherche dans le registre puis lui déléguer une tâche.

Comment un agent en délègue-t-il un autre en A2A ?

L'orchestrateur découvre l'agent cible (recherche dans l'Agent Registry), puis lui délègue via un RemoteA2aAgent qui lit son Agent Card (/.well-known/agent-card.json) et lui transmet la tâche (transfer_to_agent). La réponse remonte à l'orchestrateur.