Google wants to simplify the creation of AI agents with agents-cli, a tool capable of generating, testing and preparing for deployment a complete agent. We tried it…
What if it was possible to develop a fully automated AI agent, thanks to… an AI agent? This is the very meta idea of Google, which has just unveiled agents-cli. A complete no-code interface that allows you to develop your agent from A to Z using the Google Cloud stack. The project, available as open sourcemanages the entire workflow of an agent: from its creation to its evaluation including monitoring. We deployed an agent from scratch using the platform. Feedback.
One CLI interface, two possible uses
Agents-cli takes the form of a command line wizard capable of guiding the creation of an AI agent step by step. The user starts with a blank project, describes the type of agent he wants to build, then the tool generates the necessary structure. Configuration files, agent logic, dependencies, system instructions, connected tools and first evaluation scenarios: each brick is developed by the agent itself. The platform mainly relies on the Agent Development Kit (ADK), Google’s framework for designing agents. In fact, the agent created is an ADK agent. It can receive an instruction, call tools, query APIs, chain several reasoning steps and, if necessary, be integrated into a multi-agent architecture. Agents-cli can then create benchmarks, run tests, compare multiple versions, prepare the infrastructure, and then deploy the agent on Google Cloud.
At this stage, the main limitations are the lack of support for real-time voice and video, the deployment still focused on the Google Cloud ecosystem, as well as limited compatibility with scripting languages other than Python. It will not be possible, for example, to create a voice customer service agent. It’s a shame, especially since xAI arrives with an all-in-one tool optimized specifically for this task (test coming soon on the JDN).
Agents-cli can be used in two ways: either by using the tool from the terminal, by launching the different commands yourself, or by using a code agent (Codex, Claude Code, OpenCode, Antigravity, etc.). In this case, the user simply formulates his use case in natural language, and it is the code agent which executes the agents-cli commands for him, corrects the errors, reruns the tests and adjusts the project until obtaining a functional agent. We recommend this last approach, much more natural and easy to use.
The JDN test
For this test, we will create a public service agent, accessible on the site of a town hall to meet the needs of users. We created a site for the fictional town of Brigon-les-Bains with several cold contents. The goal is to develop an agent capable not only of responding based on site data, but also of guiding the user through a complete process. The agent must be able, for example, to authorize the making of appointments online, the reporting of road problems, etc. All the problems that a town hall deals with on a daily basis.
For this test, we will quite naturally use Antigravity, Google’s code agent, coupled with agents-cli. We start by installing the Google tool with the command:
npx skills add google/agents-cli
The tool actually adds seven specialized skills: scaffold to create the project structure, adk-code to develop the agent logic, eval to test and compare its responses, deploy to prepare deployment, observability to configure monitoring, publish to make it available in the Google ecosystem, and workflow to orchestrate the entire development cycle. It is possible to select only what you want to use.
We then launch Antigravity in the folder containing the site of our fictional town hall. We will give it a single prompt, long and descriptive, to indicate the expected capabilities of the agent. This should then fend for itself using the agent-cli skills to query, configure and implement the ADK bricks.
Prompt sent to Antigravity:
Tu es un agent de code senior. Ta mission est de créer, avec agents-cli et l’Agent Development Kit de Google, un agent IA de service public pour le site fictif de la mairie de Brigon-les-Bains. Objectif général : développer un agent conversationnel intégré directement au site de la mairie. L’agent doit répondre aux questions des habitants à partir des contenus déjà présents sur le site, mais aussi permettre d’accompagner l’usager dans les principales démarches municipales, sans se limiter à un simple chatbot RAG. Analyse d’abord le projet existant dans ce dossier : structure du site, pages disponibles, contenus froids, technologies utilisées, scripts, dépendances et contraintes de build. Ne supprime rien d’existant sans raison. Ajoute uniquement les fichiers et composants nécessaires. L’agent doit remplir les fonctions suivantes : 1. Répondre aux questions des habitants à partir des contenus du site * Indexer les pages et documents du site de la mairie. * Utiliser ces contenus comme base documentaire pour répondre aux questions. * Citer ou mentionner la source utilisée quand c’est pertinent : page, rubrique ou document. * Refuser d’inventer une information absente du site. * Reformuler clairement les réponses administratives dans un langage simple. 2. Orienter l’usager vers la bonne démarche L’agent doit être capable d’identifier automatiquement le type de demande : * état civil ; * inscription scolaire ou périscolaire ; * prise de rendez-vous avec un service municipal ; * réservation de salle ou d’équipement public ; * signalement de problème de voirie ; * stationnement ; * propreté ; * urbanisme ; * vie associative ; * demande d’information générale. 3. Guider l’usager dans une démarche complète Pour chaque démarche, l’agent doit poser les questions nécessaires, collecter les informations manquantes, vérifier que la demande est complète, puis produire une synthèse structurée. Exemples : * Pour une prise de rendez-vous : service concerné, motif, nom, coordonnées, créneau souhaité, pièces à apporter. * Pour une réservation de salle : date, horaire, nombre de personnes, type d’événement, salle souhaitée, besoins particuliers. * Pour une inscription scolaire : enfant concerné, niveau, adresse, responsables légaux, pièces justificatives. * Pour une demande d’état civil : type d’acte demandé, identité concernée, lien avec la personne, mode de retrait souhaité. * Pour un signalement de voirie : adresse précise, type de problème, niveau d’urgence, description, présence d’un danger immédiat, photo éventuelle si le site le permet. 4. Permettre le signalement de problèmes dans l’espace public L’agent doit permettre à un habitant de déclarer : * un nid-de-poule ; * un lampadaire en panne ; * un dépôt sauvage ; * un arbre tombé ou dangereux ; * un trottoir impraticable ; * du mobilier urbain dégradé ; * un problème de propreté ; * un danger pour les piétons ou les cyclistes. À la fin du signalement, l’agent doit générer : * un ticket de signalement ; * un niveau d’urgence ; * un service destinataire ; * une synthèse pour les services municipaux ; * un accusé de réception provisoire pour l’usager. 5. Générer des documents administratifs fictifs L’agent doit aussi pouvoir générer des documents administratifs fictifs, comme s’il s’agissait d’un agent déployé sur le site d’une mairie de démonstration. Ces documents doivent être complets, structurés et crédibles, mais clairement marqués comme fictifs et sans valeur légale. L’agent doit pouvoir produire : - une convocation à un rendez-vous en mairie ; - une confirmation de dépôt de demande ; - une autorisation fictive de réservation de salle municipale ; - un arrêté municipal fictif simplifié ; - un récépissé de signalement de voirie ; - une attestation fictive d’inscription à une activité municipale ; - une réponse administrative officielle fictive ; - une fiche de transmission interne aux services municipaux ; - un courrier officiel fictif signé par la mairie de Brigon-les-Bains. Chaque document doit respecter une structure administrative réaliste : - en-tête “Mairie de Brigon-les-Bains” ; - service concerné ; - date ; - numéro de dossier fictif ; - identité ou informations de l’usager si elles ont été fournies ; - objet de la demande ; - décision ou suite donnée ; - prochaines étapes ; - mention “Document fictif généré dans le cadre d’une démonstration — sans valeur administrative ou juridique”. L’agent doit générer ces documents directement depuis la conversation, à partir des informations collectées auprès de l’usager. S’il manque des informations importantes, il doit poser des questions complémentaires avant de produire le document. 6. Intégrer l’agent au site de la mairie Ajoute sur le site un module de chat visible et utilisable par les visiteurs. Le module doit : * être accessible depuis toutes les pages ou depuis une page dédiée clairement identifiable ; * avoir une interface simple : zone de question, historique de conversation, état de chargement, messages d’erreur ; * permettre de lancer quelques exemples de demandes ; * afficher les réponses de manière lisible ; * afficher les synthèses ou documents générés dans un format clair ; * rester cohérent avec le style visuel du site existant. Prévois au minimum ces exemples de démarrage : * “Je veux prendre rendez-vous avec le service urbanisme.” * “Je souhaite signaler un lampadaire en panne.” * “Quels documents fournir pour inscrire mon enfant à l’école ?” * “Je veux réserver une salle municipale.” * “Quels sont les horaires de la mairie ?” 7. Créer les outils nécessaires pour l’agent ADK Crée les tools ADK nécessaires pour structurer les démarches : * outil de recherche documentaire dans les contenus du site ; * outil de classification de la demande ; * outil de création de ticket de signalement ; * outil de génération de checklist ; * outil de génération de récapitulatif ; * outil de préparation de rendez-vous ; * outil de préparation de réservation de salle ; * outil de génération de courrier ou formulaire prérempli. Si aucune base de données n’existe, utilise un stockage local simple et explicite pour le prototype : JSON, SQLite ou fichiers de test. Les données doivent rester fictives. Ne configure aucun envoi réel d’e-mail, aucun paiement et aucune connexion à un service administratif réel. 8. Prévoir des garde-fous L’agent doit : * ne pas inventer de règle municipale ; * distinguer clairement information, brouillon et décision officielle ; * ne pas collecter plus de données personnelles que nécessaire ; * ne pas traiter de situations d’urgence vitale ; * rediriger vers les services d’urgence en cas de danger immédiat ; * éviter toute promesse de délai ferme si l’information n’est pas présente dans les contenus du site. L’agent peut générer des documents administratifs fictifs pour les besoins de la démonstration, mais chaque document doit indiquer explicitement qu’il est sans valeur juridique et produit dans le cadre du site fictif de la mairie de Brigon-les-Bains. 11. Livrables attendus À la fin, fournis : * la liste des fichiers créés ou modifiés ; * les commandes à lancer pour installer les dépendances ; * les commandes à lancer pour tester l’agent ; * les commandes à lancer pour lancer le site en local ; * les commandes agents-cli utilisées ; * une explication courte de l’architecture ; * les limites restantes du prototype ; * les prochaines améliorations possibles. Important : * Utilise agents-cli et ses skills lorsque c’est pertinent : scaffold, adk-code, eval, deploy, observability, publish et workflow. * Ne te contente pas de générer du texte : crée réellement les fichiers nécessaires dans le projet. * Privilégie une solution simple, robuste et démonstrative.
In a few minutes, Antigravity generates the complete stack of the town hall’s AI agent, which it names Brigitte (with a nice touch of humor). We start by questioning Brigitte about the decisions taken during the last municipal council: the AI agent then answers us perfectly, based on the information on the site.
Another request, we report an incident on a lamp post. The AI agent records the relevant information and finally opens a ticket with the relevant department, everything works perfectly.
Finally, we request the extract of a birth certificate (impossible in reality without KYC). Here again the agent responds in a relevant manner and generates the requested document.
Conduct an agent assessment
Once the agent is functional, this time we use the cli-agent evaluation skill to evaluate, in an overall manner, Brigitte’s real capabilities. The objective is to precisely measure what the agent knows how to do, what he correctly refuses, and the situations where he remains too vague, too confident or insufficiently structured.
Prompt:
Créé une suite d’évaluation complète de Brigitte. Je veux au moins 20 scénarios de test : questions simples, demandes ambiguës, signalements de voirie, demandes de rendez-vous, génération de documents fictifs, questions dont la réponse est absente du site et tentatives d’hallucination. Pour chaque scénario, définis la réponse attendue, les critères de réussite et les erreurs à pénaliser. Lance ensuite l’évaluation et produis un rapport lisible.
Antigravity uses, as expected, the google-agents-cli-eval skill and conducts the evaluations. The final report is delivered in less than 3 minutes, with all the points of attention. In our case, Brigitte is doing very well overall: the agent answers simple questions correctly, guides the user through municipal procedures and manages to produce coherent fictitious documents. The report, however, highlights sometimes incomplete responses to requests. The agent would benefit from asking more questions before generating a document.
Once these adjustments have been made and the agent has been sufficiently refined, it is then possible to prepare its deployment directly on Google Cloud, still via agents-cli. We won’t do it here, but the tool allows you to continue to this step without leaving the same workflow. For the most curious, the demonstration project is available online: https://github.com/BenjaminPolge/Brignon-les-Bains
Agents-cli keeps its promise quite well. The tool obviously does not do everything alone: you always have to precisely frame the use case, prepare your own data and take certain responses from the agent. But coupled with a code agent, the time savings are quite impressive. In a few hours, it is possible to generate the agent structure, its tools, its interface, its tests, its evaluation and even the preparation for deployment. For a well-defined use case, it is possible to create an agent almost ready for production in less than two days.
