Le harnais open-source CUGA d'IBM évite la plomberie et va directement à l'invite

La plupart des applications agentiques commencent par une semaine de plomberie avant que l'agent ne fasse quelque chose d'utile. Vous choisissez un framework, câblez un client de modèle, écrivez des adaptateurs d'outils, construisez un moyen de diffuser l'état vers une interface utilisateur, et quelque part là-dedans, vous décidez aussi de l'objectif réel de l'agent. La partie intéressante arrive en dernier. the-migration-isnt-finished-until-the-build-server-says-it-is-why-ai-agents-keep-failing-at-enterprise-java

CUGA inverse cela. C'est un harnais open-source pour agents d'IBM qui gère la planification, la boucle d'exécution, les appels d'outils et la gestion d'état pour vous. Ce qui reste est la partie qui est réellement la vôtre : les outils auxquels l'agent peut accéder, et ce que vous lui dites de faire. Pour montrer comment cela fonctionne en pratique, l'équipe a construit cuga-apps : deux douzaines de petites applications fonctionnelles, chacune étant un seul fichier FastAPI encapsulant un CugaAgent, allant d'un recommandeur de films à un conseiller en architecture IBM Cloud. Elles sont conçues pour être lues et copiées. Vous pouvez parcourir la galerie en direct. opid-on-policy-skill-distillation-boosts-language-agent-training-without-external-memories

Ce que CUGA vous évite d'écrire

CUGA répond à la question légitime : qu'est-ce qui vous évite d'écrire ? L'orchestration autour d'un modèle que vous devriez sinon reconstruire à chaque fois. Il planifie avant d'agir, puis exécute avec un mélange d'appels d'outils et de code généré via CodeAct. Sur une tâche longue qui s'exécute en vingt étapes, CUGA conserve les résultats intermédiaires et exécute une étape de réflexion qui peut détecter un mauvais appel et replanifier au lieu de foncer tête baissée. Cette machinerie explique pourquoi il a dominé les benchmarks d'agents comme AppWorld et WebArena. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

Vous définissez également le compromis coût/latence à partir de la configuration plutôt que du code : modes de raisonnement Rapide, Équilibré et Précis, avec exécution de code dans le bac à sable de votre choix : local, Docker/Podman, ou cloud E2B. La plupart des harnais supposent qu'un modèle de pointe se trouve en dessous et s'appuient sur lui pour se remettre d'un plan qui tourne mal ; CUGA fait ce travail lui-même. La planification, l'étape de réflexion, le suivi des variables qui maintient une longue exécution sur la bonne voie, c'est le harnais qui supporte la charge que le modèle devrait autrement assumer, ce qui permet à un modèle plus petit à poids ouvert de tenir là où il ne le ferait normalement pas. the-verification-horizon-why-rewarding-coding-agents-is-getting-harder

Un agent en un seul fichier : le conseiller IBM Cloud

Voici le conseiller IBM Cloud, un agent qui recommande de vrais services IBM Cloud pour une architecture. Le tout tient dans un seul fichier : un main.py avec la fabrique d'agent, les outils et l'invite, plus une petite interface utilisateur.

L'agent tout entier se résume à ceci :

def make_agent():
    from cuga import CugaAgent
    from _llm import create_llm
    return CugaAgent(
        model=create_llm(
            provider=os.getenv("LLM_PROVIDER"),
            model=os.getenv("LLM_MODEL"),
        ),
        tools=_make_tools(),
        special_instructions=_SYSTEM,
        cuga_folder=str(_DIR / ".cuga"),
    )

Quatre arguments. Le modèle provient d'une petite fabrique appelée create_llm qui parle à OpenAI, Anthropic, watsonx, LiteLLM ou Ollama selon une variable d'environnement. Rien dans le code de l'application ne sait quel modèle se cache derrière. Les deux arguments qui portent l'application sont tools et special_instructions.

Les outils mélangent une fonction locale avec une fonction hébergée. Il y a un modèle ici qui tient pour chaque application : une division entre les outils MCP et les outils en ligne. Les capacités génériques et sans état proviennent de serveurs MCP partagés ; tout ce qui est spécifique à cette application est défini en ligne comme une fonction Python normale. L'invite du conseiller cloud indique à l'agent de rechercher dans le catalogue avant de nommer un service, de recommander trois à sept services avec le rôle de chacun dans la conception, et de ne jamais inventer de noms de services. gui-agents-beat-cli-in-desktop-tasks-but-skill-coverage-holds-the-key

Gouvernance intégrée, pas ajoutée après coup

Un agent de démonstration qui recherche dans un catalogue comporte peu de risques. Pointez le même modèle vers quelque chose qui écrit des fichiers, exécute des commandes shell ou touche à la production, et la question change : comment l'empêcher de faire quelque chose que vous regretterez ? CUGA répond à cela dans le runtime, pas dans un wrapper que vous ajoutez après. Le harnais open-source livre un système de politique avec six types de politiques : Garde-fous d'intention, Guides d'outils, Approbation d'outils, Formateurs de sortie, Humain-dans-la-boucle, et la porte de secours CustomPolicy.

Un Garde-fou d'intention vérifie la demande avant que l'agent ne choisisse un outil. L'Approbation d'outils s'exécute après que l'agent a généré son code et inspecte les outils que ce code utilise. Et le Formateur de sortie ne se déclenche qu'une fois que le message final existe. Les déclencheurs vont aussi au-delà de la simple correspondance de mots-clés, ils sont conservés dans un magasin sqlite-vec et mis en correspondance sémantiquement, donc une politique se déclenche sur ce que l'utilisateur veut dire, pas seulement sur un mot-clé exact. from-zero-days-to-autonomous-defense-how-ai-agents-are-rewriting-cybersecurity

D'un agent à plusieurs : délégation multi-agents et compétences

Lorsqu'un seul agent se noierait dans son propre contexte, vous divisez le travail. Un CugaSupervisor délègue à des CugaAgents spécialisés, chacun avec ses propres outils, invite et contexte isolé, et le superviseur ne raisonne jamais que sur le spécialiste auquel confier une sous-tâche. Sa surface de planification reste petite, quel que soit le nombre d'outils en dessous. Les spécialistes peuvent être des agents locaux ou des agents externes atteints via A2A.

Les autres packages d'extension empaquettent du savoir-faire plutôt que des outils : Compétences d'agent (Agent Skills), un dossier avec un playbook SKILL.md que l'agent extrait dans le contexte uniquement lorsqu'une tâche le nécessite. Ouroboros, une application de génération de leads, a un superviseur sur sept spécialistes : éclaireur, auditeur de site, voix-du-client, chercheur de personnes, scanneur de pile, estimateur de revenus et rédacteur d'email de pitch. Chaque spécialiste est une compétence chargée dans un CugaAgent. fast-lewm-parallel-action-prefix-prediction-slashes-latent-world-model-planning-costs

Chemin vers la production : Sovereign Core

Parce que le harnais est petit, open-source, indépendant du modèle et déjà auto-gouverné, l'agent que vous avez écrit sur votre ordinateur portable est le même agent qui s'exécute dans un déploiement verrouillé. IBM Sovereign Core s'appuie sur cela. Il exécute les agents CUGA sous Isolement de Frontière (Boundary Isolation) : données, plan de contrôle et moteur d'exécution à l'intérieur de la même frontière logique. Les déploiements utilisent par défaut gpt-oss-120b fonctionnant complètement en mode air-gapped dans votre infrastructure, et les outils n'atteignent que des VNET privés avec approbation par outil. Chaque étape de raisonnement émet des traces OpenTelemetry dans un backend Grafana Tempo qui reste dans le locataire, sans télémétrie de rappel à la maison.

Le point à retenir pour le développeur est clair : une application agentique peut être un fichier que vous gardez en tête. Les outils et l'invite sont les seules parties que vous écrivez vraiment. Les applications sont une bibliothèque pour apprendre, et lorsque les enjeux augmentent, la gouvernance est déjà dans le runtime.