Boucle Agentic Foundry

Coordonnez la solution et utilisez microsoft-foundry pour les opérations de plateforme. Les choix explicites de l'utilisateur remplacent les valeurs par défaut. Réutilisez le contexte connu, posez des questions uniquement pour les décisions manquantes, lisez uniquement les références dont une étape a besoin, et rapportez les décisions, les blocages et les endpoints de manière concise.

Bootstrap (une fois par session)

1. Skill Foundry. Si microsoft-foundry n'est pas disponible, demandez-le, puis installez-le (copilot plugin install azure@awesome-copilot, ou gh skill install microsoft/azure-skills microsoft-foundry --agent github-copilot --scope project) et rechargez les skills.
2. Canvas et workflow. Ce plugin fournit foundry-agentic-loop-canvas et foundry-agentic-loop-workflow, listés comme foundry-agentic-loop:<name> ou <name>. Appelez extensions_manage avec operation: "list". N'installez jamais d'extensions à partir d'une URL et n'éditez jamais les fichiers de configuration de Copilot. Si l'un n'est listé sous aucun des deux noms, dites à l'utilisateur lequel manque et qu'il est fourni avec le plugin, puis demandez avant d'exécuter copilot plugin install foundry-agentic-loop@awesome-copilot ; après approbation, appelez extensions_reload une fois. S'il est désactivé, dites à l'utilisateur de le réactiver dans ses paramètres d'extension et continuez dans une nouvelle session : les sessions en cours le gardent désactivé, même après un rechargement. S'il a échoué, inspect-le et rapportez son journal. Sans le canvas, continuez en Chat ; sans le workflow, SDD ne peut pas démarrer, donc proposez un prototypage rapide.
3. Canvas. Quand le travail commence depuis Chat, ouvrez-le une fois : open_canvas avec canvasId: "foundry-agentic-loop-canvas", instanceId: "foundry-agentic-loop" et input: { mode }. Les prompts commençant par [Agentic Loop canvas action] proviennent du canvas ; suivez littéralement leurs instructions de cible, approbation et reprise.

Choisir le mode

Sinon, posez la question une fois avec les choix « Prototypage rapide (projet Foundry existant) » et « SDD (nouveau projet, déployé avec azd) ».

Verrouillez-le. Avant toute autre écriture dans l'espace de travail (dans la vérification préalable rapide, ou juste avant le démarrage du workflow SDD), insérez la section depuis agents-md-rapid.md ou agents-md-sdd.md dans la racine AGENTS.md : remplacez tout entre ses marqueurs de début et fin foundry-agentic-loop, ou ajoutez-la en conservant le reste du contenu ; puis relisez-la. La section achemine les commandes courtes telles que deploy et verrouille le mode pour Chat, le canvas et le workflow. Les paramètres Azure ne vont que dans .azure/deployment-plan.md, jamais dans AGENTS.md. Le mode Improve ne l'écrit jamais.

Défauts

• Agents : Agents Foundry hébergés exposant l'API Responses, Python 3.13, déploiement de code. Créez-les via le foundry-agent/create/quick-start-hosted.md de microsoft-foundry avec l'Exemple Basic, résolu par ce skill, jamais une URL devinée. Utilisez son workflow avancé uniquement quand quick-start ne peut pas supporter une capacité, en gardant ces défauts. Sollicitez les agents uniquement quand demandé.
• Framework : le SDK Copilot pour les agents utilisant des skills runtime (recette, agent de référence) ; Microsoft Agent Framework pour les agents basiques et les workflows explicites. Si un workflow a aussi besoin de skills, clarifiez. Un framework par agent.
• Modèles : rapid garde le déploiement de modèle de l'exemple Basic, ou vérifie et réutilise celui fourni ; SDD utilise par défaut gpt-5.4-mini sauf si la spec en a besoin. Exécutez le preflight de placement commun dans foundry-models.md avant de créer des ressources. Ne codez jamais en dur un remplacement et ne dupliquez pas silencieusement un déploiement.
• Outils et connaissances : une boîte à outils Foundry gouvernée pour les outils intégrés, les connexions MCP et les skills d'agent ; les agents utilisent son endpoint, pas les URLs d'outils codées en dur. Les connaissances privées utilisent Foundry IQ via la boîte à outils, avec des citations pour les affirmations supportées et une réponse déterministe d'insuffisance de preuves ; testez les deux. Ajoutez Search uniquement quand nécessaire. Réutilisez les skills de run que l'utilisateur nomme depuis le catalogue de run skills au lieu de les régénérer.
• App : React + Vite, FastAPI et FastMCP (HTTP streamable) sur Azure Container Apps. Rapid déploie avec az containerapp up --name <app> --source <dir> --resource-group <rg> --environment <env> ; SDD utilise azd avec une couche microsoft.foundry plus une couche app Bicep (AVM), remoteBuild: true et un ACR tiré par identité managée. Ajoutez les services depuis l'architecture de référence uniquement quand la solution en a besoin.
• Accès à l'app : décidez-en selon les données. Quand tout ce que l'app affiche est exemple, synthétique ou délibérément public, utilisez par défaut aucune connexion d'utilisateur final, même pour les utilisateurs du staff ; les services s'authentifient encore avec les identités managées et n'ont besoin d'aucun contournement de session anonyme ou de vérification d'identité. Quand elle affiche des données privées, sensibles ou spécifiques à l'utilisateur, demandez le modèle d'accès avant le déploiement et utilisez par défaut un ingress interne ou une connexion Entra ; l'accès anonyme nécessite une approbation explicite. Avec connexion, l'API pré-autorise le SPA, la spec dit comment les tests de navigateur automatisés obtiennent un jeton utilisateur, et Implement prouve ce chemin de jeton dès que les enregistrements d'app existent.
• Identité et sécurité : identités managées et RBAC keyless au moindre privilège (contrat ; preflight avec check_rbac_preflight.py). Vérifiez les droits du plan de gestion, du plan de données et d'assignation de rôle séparément ; Owner d'abonnement n'accorde pas les rôles du plan de données Foundry. Planifiez les rôles pour les identités pas encore créées et vérifiez les principals réels après création. Pas de credentials dans le code navigateur ou Git ; guardrails Foundry activés.
• Observabilité : OpenTelemetry depuis le backend, les agents, les serveurs MCP et les appels de modèle dans une Application Insights unique connectée au projet (observability.md). La capture de contenu sensible reste désactivée sauf approbation avec contrôles de redaction et rétention.

Fichiers de l'espace de travail

Règles de travail

• Contrat d'abord. Verrouillez les noms de services, les variables d'environnement, les protocoles, les endpoints, les schémas, l'auth, le streaming, les erreurs et les versions (implementation-contract.md) avant le travail parallèle.
• Intégration d'abord. Passez le checkpoint d'intégration hébergée avec un agent minimal avant de construire l'orchestration complète, l'UI ou le backend : toujours une requête de modèle, plus un chargement de skill de boîte à outils et un appel MCP sûr uniquement quand l'architecture en a besoin. Enregistrez les capacités exclues comme N/A avec la raison, jamais comme passées, et n'ajoutez jamais celles inutilisées pour satisfaire le checkpoint.
• Preuve, pas signaux. HTTP 200, exit 0 ou active ne passent jamais seuls ; exigez une complétion terminale, une sortie valide selon le schéma, une preuve d'exécution et des traces corrélées. Corrigez avec des diagnostics bornés, pas des redéploiements inchangés.
• Attendre par complétion. L'approvisionnement, les déploiements, la propagation d'assignation de rôle et la disponibilité d'agent se terminent quand leur commande ou vérification de statut le dit : exécutez la commande synchroniquement avec une attente initiale longue, ou interrogez son statut tous les 30-60 s contre une deadline déclarée. Ne chaînez jamais des sleeps fixes ; continuez le codage pendant qu'Azure fonctionne.
• Sous-agents. Avant le checkpoint, parallélisez uniquement la recherche et le preflight. Après, donnez à chaque worker un objectif borné, des fichiers ou dossiers exclusifs relatifs à l'espace de travail, des références de skills, un contexte vérifié, le contrat, les vérifications d'acceptation et les conditions d'arrêt. Un propriétaire (le coordinateur, ou le lead de phase SDD) détient le contrat et les fichiers partagés : azure.yaml, infra/, docs/, .env, .azure/, .agentic-loop/, AGENTS.md et les lockfiles racine. Gardez les équipes petites, évitez la délégation récursive, sérialisez les mutations Azure partagées et intégrez centralement ; le succès du worker n'est pas l'acceptation. La délégation n'accorde aucune approbation supplémentaire. Sans sous-agents, travaillez séquentiellement et dites-le.
• Sécurité. Réutilisez les ressources ; confirmez les changements facturables, de sécurité ou de conformité ; supprimez sans approbation uniquement une ressource créée par ce build dont l'approvisionnement a échoué ; ne vous connectez jamais pour l'utilisateur ; ne rapportez jamais un déploiement non vérifié comme réussi.
• Limite de l'espace de travail. Les builds restent dans l'espace de travail : lisez les leçons uniquement depuis son propre docs/LOOP.md, échafaudez depuis les exemples Foundry et ces références, et utilisez le code d'autres dossiers uniquement quand l'utilisateur les nomme. Seul le mode improve lit les exécutions passées ailleurs.
• Contexte Work IQ. Uniquement quand l'utilisateur ou un prompt du canvas le demande, interrogez le serveur MCP workiq avant les questions de clarification, intégrez uniquement les requirements qui importent, citez chacun par type de source et confirmez-les. Ne copiez jamais de contenu confidentiel, de données personnelles ou de secrets dans l'espace de travail ; si Work IQ n'est pas disponible ou nécessite un consentement, dites-le et continuez sans.
• Companions et SDKs. Vérifiez les APIs SDK installées contre la dernière release stable (ou la plus nouvelle que l'index de packages du build sert, en enregistrant l'écart) et verrouillez les versions avant de générer du code ; les sources de packages surpassent l'orientation obsolète. Consultez le catalogue de build skills uniquement pour les capacités nécessaires ; respectez les pins, demandez avant les installs et routez les défauts de skills tiers en amont.

Leçons

Juste après qu'une correction soit vérifiée (la sonde défaillante ou une vérification de limite équivalente réexécutée avec succès ; une édition, un commit ou un déploiement seul ne sont pas une résolution), insérez une leçon dans le docs/LOOP.md de l'espace de travail depuis le modèle avant le travail non associé, puis relisez-la. Gardez les notes utilisateur, mettez à jour les leçons correspondantes au lieu de les dupliquer, et n'incluez jamais les secrets, les valeurs .env brutes ou les payloads. Le coordinateur, ou le lead de phase SDD, détient les écritures ; les workers rapportent les preuves. Les leçons n'autorisent jamais les édits de skills ou les gates plus faibles ; le mode improve les applique avec approbation.