L'infrastructure pour une économie d'agent à agent

L'économie d'agent à agent n'est pas bloquée par le renseignement, elle est bloquée par l'infrastructure

Il est tentant de croire que le plus grand défi des agents d'IA est le renseignement. Cela a été vrai pendant longtemps. Les modèles avaient du mal à raisonner, les outils étaient fragiles et les tâches en plusieurs étapes se désintégraient facilement. Mais cette phase est en grande partie derrière nous.

Les agents modernes peuvent déjà faire beaucoup. Ils peuvent raisonner en plusieurs étapes, appeler des outils, invoquer des serveurs MCP et même se coordonner avec d'autres agents. Avec les bonnes instructions et les bons modèles, de nombreuses équipes peuvent créer des prototypes d'agents impressionnants en un temps étonnamment court. Les démos semblent convaincantes. Les premiers résultats semblent magiques.

Et pourtant, lorsque ces mêmes systèmes sont poussés vers une utilisation réelle, ils commencent à échouer de manière silencieuse et confuse.

C'est cet écart qui définit l'économie émergente d'agent à agent. Ce n'est pas un manque d'intelligence, mais un manque d'infrastructures.

Le faux sentiment d'achèvement dans les premiers systèmes d'agents

La plupart des premières implémentations d'agents suivent un schéma d'une simplicité trompeuse. Un utilisateur envoie une entrée, l'agent raisonne dessus, appelle éventuellement un outil et renvoie une réponse. Ce flux linéaire est facile à comprendre et à déboguer. Cela correspond également bien à la façon dont les développeurs ont l'habitude de penser aux applications.

Mais ce modèle cache une hypothèse qui ne survit pas au contact de la réalité : l'exécution des agents est éphémère, isolée et autonome.

Dès que les agents commencent à interagir avec d'autres agents, cette hypothèse est annulée. Un agent délègue le travail à un autre. Une action de suivi est déclenchée ultérieurement. L'invocation d'un outil entraîne une décision secondaire. Les chemins d'exécution se ramifient, se rejoignent et parfois s'interrompent complètement.

À ce stade, le système cesse de se comporter comme une fonctionnalité d'application et commence à se comporter comme un système distribué composé de composants autonomes.

Cette transition est subtile, mais essentielle. Les équipes ne se rendent souvent pas compte que c'est arrivé avant que les choses ne commencent à mal tourner.

D'où viennent réellement les échecs

Lorsque les systèmes d'agents rencontrent des difficultés en production, les défaillances sont rarement dramatiques. Le système ne plante pas du tout. Au contraire, la confiance s'érode lentement.

Une action est déclenchée, mais personne ne sait pourquoi.
Un agent en aval s'exécute, mais avec des autorisations peu claires.
Les coûts augmentent sans cause évidente.
Un flux de travail s'arrête à mi-chemin et aucune trace claire n'explique où ni pourquoi.

Ce ne sont pas des échecs de raisonnement. L'agent a peut-être pris une décision parfaitement raisonnable compte tenu des informations dont il disposait. Le problème est que personne ne peut expliquer ou gouverner de manière fiable ce qui s'est passé dans l'ensemble du système.

C'est à ce moment que de nombreuses équipes essaient instinctivement de « réparer » l'agent lui-même, en ajustant les instructions, en échangeant les modèles ou en ajoutant plus de logique. Mais ces modifications s'attaquent rarement à la cause première, car le problème ne réside pas dans l'agent.

Il vit entre agents.

Pourquoi les améliorations du renseignement ne permettent pas de débloquer la production

Si l'intelligence était le véritable obstacle, nous nous attendrions à un schéma simple : de meilleurs modèles conduiraient à des systèmes de production stables. Ce n'est pas ce que nous voyons.

Ce que nous constatons au contraire, c'est qu'à mesure que les agents deviennent plus capables, les systèmes qui les entourent deviennent plus difficiles à gérer. Une plus grande intelligence entraîne une plus grande autonomie, un comportement plus ramifié et davantage d'effets en aval. Sans une infrastructure adaptée, cette capacité supplémentaire augmente en fait les risques.

L'économie d'agent à agent amplifie cet effet. Alors que les agents commencent à appeler d'autres agents et à opérer dans des outils et des environnements partagés, le coût de l'infrastructure manquante augmente rapidement. L'identité, la coordination, l'application des politiques et l'observabilité cessent d'être des préoccupations facultatives et deviennent des exigences fondamentales.

Redéfinir les agents en tant que composants d'infrastructure

C'est là qu'un changement de mentalité devient nécessaire. Les agents ne peuvent pas être traités comme un simple élément de la logique de l'application. Dans un véritable écosystème d'agents, les agents sont des acteurs de longue date qui participent aux flux de travail, délèguent le travail et opèrent sous différentes autorités.

Des plateformes comme Centre d'agents de TrueFoundry reflètent cette évolution. Au lieu de supposer que les agents sont une logique intégrée privée, Agent Hub les traite comme des composants enregistrés et détectables dotés d'interfaces et de propriétaires explicites. Les agents sont publiés, versionnés et invoqués via une surface de contrôle partagée au lieu de s'appeler directement via des chemins de code ad hoc.

Ce recadrage ne rend pas les agents plus intelligents. Cela rend le système qui les entoure utilisable.

L'économie d'agent à agent n'attend pas une avancée en matière de raisonnement. Il attend une infrastructure capable de soutenir l'autonomie sans perdre le contrôle.

La première étape consiste à comprendre comment les systèmes d'agents évoluent une fois qu'ils entrent en production et pourquoi les approches traditionnelles échouent. À partir de là, le rôle des plans de contrôle, des passerelles et des API d'exécution explicites devient incontournable. C'est là que commence le vrai travail.

Lorsque les agents entrent en production, les parties les plus simples sont déjà résolues

Au moment où un système d'agents entre en production, la plupart des équipes ont déjà résolu les problèmes évidents.

Ils savent comment envoyer des demandes à un LLM.
Ils savent comment câbler des outils ou des serveurs MCP.
Ils savent comment faire appel à un agent et obtenir une réponse.

Ces capacités ne sont plus expérimentales. Ils sont stables, bien documentés et faciles à reproduire. En fait, c'est précisément pour cela que les équipes gagnent en confiance si rapidement. Les premiers succès donnent l'impression que le système est « presque terminé ».

C'est dans la production que cette illusion se brise.

La production n'ajoute pas de complexité, elle la révèle

Ce que fait réellement la production, c'est exposer tout ce que les prototypes cachent commodément.

Dans une démo, un agent fonctionne généralement de manière isolée. Il gère une seule demande, effectue un petit nombre d'actions et se ferme. Il n'y a qu'un seul chemin d'exécution et un seul résultat. Le débogage est simple car l'ensemble du contexte s'inscrit dans la tête du développeur.

En production, les agents ne se comportent pas de cette façon.

Ils fonctionnent en continu.
Ils déclenchent des actions de suivi.
Ils appellent d'autres agents.
Ils fonctionnent dans tous les environnements, les équipes et les autorisations.

L'exécution cesse d'être une interaction unique et devient une flux de travail, qui se développe souvent au fil du temps.

C'est là que les systèmes d'agents commencent à ressembler à des systèmes distribués, non pas parce qu'ils utilisent des microservices ou des files d'attente, mais parce que le comportement est désormais réparti entre plusieurs acteurs autonomes.

Les questions qui comptent soudainement

En cas de problème en production, les équipes ne demandent pas si l'agent était « assez intelligent ». Au lieu de cela, ils posent des questions qui semblent familières à tous ceux qui ont exploité des systèmes distribués :

Qu'est-ce qui a déclenché cette action ?
Quel agent a pris la décision ?
Sous quelle identité a-t-il été diffusé ?
Pourquoi la succursale des exécutions a-t-elle eu lieu ici ?
Pourquoi est-ce que ça s'est complètement arrêté ?

Ces questions sont d'une simplicité trompeuse et il est impossible d'y répondre de manière fiable sans support d'infrastructure.

Dans la plupart des premières configurations d'agent, le contexte d'exécution se trouve dans l'agent lui-même. Une fois qu'un agent appelle un autre agent ou invoque un outil, ce contexte disparaît souvent à moins que chaque développeur ne le propage soigneusement. Au fil du temps, les journaux se fragmentent, le traçage s'interrompt et le système devient opaque.

L'agent produit peut-être encore des résultats, mais il devient difficile de raisonner sur le système dans son ensemble.

Pourquoi les correctifs locaux ne sont pas évolutifs

La réaction naturelle à ce stade est de corriger le problème localement. Une équipe ajoute la journalisation des appels d'outils. Une autre enveloppe les agents avec des contrôles d'authentification. Quelqu'un ajoute de nouvelles tentatives à quelques endroits. Aucun de ces changements n'est mauvais en soi.

Mais ensemble, ils créent un réseau fragile de code de colle où :

• le comportement diffère subtilement entre les agents
• les politiques sont appliquées de manière incohérente
• le débogage nécessite des connaissances tribales
• les petits changements semblent risqués

C'est à ce moment que les équipes commencent à se sentir ralenties, non pas parce que les agents ne peuvent pas faire plus, mais parce que tout changement a des conséquences imprévues.

Ce qui émerge ici, que les équipes s'en rendent compte ou non, c'est un plan de contrôle. Il se trouve que c'est accidentel et mal défini.

Rendre l'exécution explicite avec l'infrastructure

C'est là que des plateformes comme True Foundry tracer une ligne claire entre la logique des agents et la responsabilité du système.

Avec le Centre d'agents, les agents ne sont plus invoqués implicitement via des appels de fonctions locaux ou des dépendances cachées. Ils sont enregistrés, détectables et exécutés via une interface partagée. Avec le API d'agent, l'exécution de l'agent devient explicite, contextuelle et observable.

Au lieu qu'un agent appelle discrètement un autre agent, l'exécution apparaît comme une opération gérée.

# Using TrueFoundry's Agent API with registered MCP servers
import httpx

response = httpx.post(
    "https://{controlPlaneURL}/api/llm/agent/chat/completions",
    headers={
        "Authorization": "Bearer {TFY_API_TOKEN}",
        "Content-Type": "application/json"
    },
    json={
        "model": "openai/gpt-4o",
        "messages": [{"role": "user", "content": "Evaluate risk for transaction txn_123"}],
        "mcp_servers": [{"integration_fqn": "common-tools", "tools": [{"name": "web_search"}, {"name": "sequential_thinking"}]}],
        "stream": True
    }
)

# Connecting to MCP server through TrueFoundry Gateway
from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

async def main():
    url = "https://{controlPlaneURL}/api/llm/mcp/common-tools/server"
    transport = StreamableHttpTransport(
        url=url,
        auth="<tfy-api-token>",
    )
    async with Client(transport=transport) as client:
        tools = await client.list_tools()
        result = await client.call_tool("web_search", {"query": "What is Python?"})
        return result

Remarque : Le contrat d'API Agent Hub est actuellement en cours de développement actif. Pour connaître la syntaxe et les fonctionnalités les plus récentes, reportez-vous au Documentation sur l'API des agents.

Cela peut sembler un petit changement, mais il a des conséquences importantes. L'identité voyage avec la demande. Les limites d'exécution sont claires. Les actions en aval peuvent être retracées jusqu'à leur origine. Les politiques peuvent être évaluées avant l'exécution de l'agent, et non après un problème.

L'agent raisonne toujours et décide quoi faire. La plateforme gère la manière dont cette décision est exécutée en toute sécurité.

Le véritable changement

Une fois que les agents sont arrivés en production, les principaux problèmes ne sont plus liés au renseignement. Elles concernent la coordination, l'identité, la visibilité et le contrôle. Ces préoccupations n'ont rien à voir avec le code de l'agent, car elles concernent tous les agents, les flux de travail et les équipes.

C'est pourquoi de nombreuses équipes recherchent ensuite un raccourci : placer un routeur devant leurs agents en espérant que cela suffira.

C'est rarement le cas.

Comprendre pourquoi cette approche échoue constitue la prochaine étape pour comprendre à quoi doit ressembler une véritable infrastructure d'agents.

Pourquoi « juste un routeur » tombe en panne dans les systèmes agent-à-agent

Une fois que les équipes se rendent compte que leur système d'agents devient difficile à gérer, le premier réflexe est généralement pragmatique : ajouter un routeur devant les agents.

Cette approche me semble familière. Les passerelles et routeurs API sont bien connus. Ils ont travaillé pour les microservices, alors pourquoi ne pas réutiliser le même modèle pour les agents ? Placez une couche de routage au premier plan, décidez quel agent appeler et passez à autre chose.

Pendant un court moment, cela fonctionne. Ensuite, le système commence à se plier d'une manière que le routeur n'a jamais été conçu pour gérer.

Les hypothèses sur lesquelles les routeurs s'appuient discrètement

Les routeurs sont conçus pour un monde très spécifique. Ils partent du principe que les requêtes sont de courte durée, que les chemins d'exécution sont pour la plupart linéaires et que l'identité est soit uniforme, soit résolue une fois à la périphérie. Ils transmettent le trafic de manière efficace, mais ils ne comprennent pas l'intention.

Les systèmes agent-agent violent ces hypothèses presque immédiatement.

Les agents ne se contentent pas de répondre aux demandes. Ils initient des actions, délèguent le travail à d'autres agents et déclenchent des effets secondaires qui se manifestent au fil du temps. Une seule décision peut donner lieu à de multiples exécutions en aval, certaines immédiates, d'autres différées. L'identité n'est plus un en-tête unique ; c'est quelque chose qui doit être préservé et raisonné à chaque saut.

Un routeur peut transmettre une demande. Cela ne peut pas expliquer pourquoi cette demande existe.

Là où la logique de routage commence à présenter des fuites

À mesure que les systèmes d'agents se développent, les équipes commencent à confier de plus en plus de responsabilités au routeur. Des règles d'authentification sont ajoutées. La sélection du modèle est codée dans les itinéraires. Les contrôles de politique sont codés en dur dans la logique de routage. Le contexte est assemblé à l'aide d'en-têtes et de conventions.

Rien de tout cela ne semble mal pris isolément. Mais au fil du temps, le routeur devient un dépotoir pour des problèmes qu'il n'était pas censé gérer. Il se transforme en un point d'étranglement fragile où :

• l'identité est déduite plutôt qu'explicite
• les politiques sont éparpillées et difficiles à auditer
• les changements de comportement nécessitent des redéploiements coordonnés
• les échecs sont difficiles à retracer au-delà du premier saut

Ironiquement, le routeur qui était censé simplifier le système devient celui qui ralentit tout le monde.

Pourquoi la gouvernance n'a pas sa place dans un routeur

Le problème le plus profond est que les systèmes d'agents n'ont pas seulement besoin de gérer le trafic. Ils ont besoin de gouvernance.

Les équipes chargées de la sécurité et de la conformité ne demandent pas quel itinéraire a été emprunté. Ils demandent qui a accédé à quoi, en vertu de quelle autorité et pourquoi. Les équipes produit ne veulent pas simplement savoir où est allée une demande ; elles veulent comprendre comment une décision s'est propagée entre les agents et les outils. Les opérateurs doivent suivre l'évolution des coûts et du comportement sur l'ensemble d'un flux de travail, et pas seulement à la périphérie.

Ces questions ne peuvent pas être résolues uniquement par le routage, car elles dépendent de l'intention, de la délégation et des actions dérivées. Ces concepts ne sont pas naturels dans un routeur.

Au-delà du routage grâce à un contrôle explicite

C'est là que la distinction entre un routeur et un plan de contrôle devient claire.

Avec Centre d'agents de TrueFoundry, les agents ne sont pas des points de terminaison anonymes derrière une table de routage. Ce sont des entités nommées et enregistrées avec des interfaces et des droits de propriété explicites. Lorsqu'un agent en appelle un autre, il le fait par le biais d'une couche d'exécution gérée plutôt que d'un saut réseau opaque.

Le API d'agent renforce cette séparation. L'exécution n'est pas cachée derrière un itinéraire ; il s'agit d'une opération explicite intégrant l'identité, les métadonnées et l'évaluation des politiques. La passerelle applique les règles de manière cohérente, tout en préservant le contexte des interactions agent-agent.

Cela n'enlève rien à la flexibilité. Il le restaure. En gardant le routage centré sur le trafic et en transférant la gouvernance vers une infrastructure dédiée, les équipes peuvent faire évoluer le comportement des agents sans transformer leur couche de routage en un monolithe fragile.

La conclusion incontournable

« Juste un routeur » échoue non pas parce qu'il est mal implémenté, mais parce qu'il résout le mauvais problème. Les systèmes agent-agent ne sont pas des routeurs de requêtes dotés de terminaux plus intelligents. Il s'agit de systèmes distribués dotés d'un comportement autonome.

Une fois que les équipes l'acceptent, la prochaine prise de conscience s'ensuit naturellement : les systèmes d'agents se comportent comme des systèmes distribués, mais avec des enjeux plus importants.

Agent Hub en tant que plan de contrôle pour les systèmes d'agents

Lorsque les équipes se rendent compte qu'un routeur ne suffit pas, un autre modèle commence généralement à apparaître de lui-même. De petits éléments de logique de coordination commencent à apparaître partout. Un agent ajoute des contrôles d'autorisation avant d'appeler un outil. Un autre intègre une logique de nouvelle tentative lors de l'appel d'un agent en aval. Une troisième équipe ajoute une journalisation personnalisée pour suivre ce qui s'est passé après le déclenchement d'une action.

Aucune de ces modifications n'est erronée. En fait, il s'agit de réponses pratiques à de vrais problèmes. Mais pris ensemble, ils indiquent quelque chose de plus profond : il manque au système un plan de contrôle.

Un plan de contrôle n'a pas pour but de faire le travail. Il s'agit de décider comment le travail est autorisé.

Pourquoi les systèmes d'agents ont besoin d'un plan de contrôle

Dans un système agent-à-agent, certaines questions n'ont tout simplement pas leur place dans la logique des agents :

Qui est autorisé à invoquer cet agent ?
Dans quelles conditions ?
Avec quels outils ou quels serveurs MCP ?
Avec quel niveau de visibilité et d'auditabilité ?

Lorsque ces décisions sont intégrées directement dans les agents, elles sont dupliquées et évoluent au fil du temps. Deux agents qui devraient se comporter de la même manière divergent lentement. Les politiques ne sont pas appliquées de manière cohérente. Le débogage devient une conjecture car aucun endroit ne reflète la manière dont le système est réellement géré.

C'est exactement le problème Centre d'agents de TrueFoundry est conçu pour résoudre.

Les agents en tant que composants d'infrastructure de premier ordre

Agent Hub traite les agents non pas comme des détails d'implémentation privés, mais comme entités enregistrées et détectables au sein d'un système partagé. Il fournit des fonctionnalités telles que :

• développement d'agents à l'aide de modèles et de serveurs MCP
• applications d'agent pour les utilisateurs non techniques
• flux de travail multi-agents avec sous-agents
• intégration d'agents compatibles A2A conçus en externe
• le partage et l'orchestration des agents entre les équipes.

Chaque agent est publié avec une interface, une propriété et des limites d'exécution claires. Les autres agents n'y « accèdent » pas par des chemins de code ad hoc. Ils l'invoquent explicitement.

Cela change la nature des interactions agent-agent. Au lieu de dépendances cachées, les relations deviennent visibles. Au lieu d'une confiance implicite, l'exécution passe par une couche gérée.

Pour visualiser cela, il est utile de placer Agent Hub au centre du système :

Composer délibérément des flux de travail multi-agents

À mesure que les systèmes se développent, les flux de travail restent rarement simples. Un agent peut se spécialiser dans la recherche, un autre dans l'évaluation, un autre dans la prise de décisions. Ces agents ne se remplacent pas les uns les autres ; ils collaborent.

Agent Hub prend en charge cela de manière explicite par le biais de sous-agents et de flux de travail multi-agents. Plutôt que de coder en dur la logique d'orchestration au sein d'un seul « méga-agent », les équipes peuvent composer des flux de travail en enchaînant les agents de manière contrôlée.

Cela a deux effets importants. Tout d'abord, cela permet aux agents individuels de rester concentrés et compréhensibles. Deuxièmement, il centralise la logique de coordination afin que les modifications apportées à la façon dont les agents interagissent ne nécessitent pas de réécrire chaque agent impliqué.

Le système devient plus facile à faire évoluer, et non plus difficile.

Éviter la montée en puissance des agents de l'ombre

Un autre avantage discret d'un plan de commande centralisé est la visibilité. Dans de nombreuses organisations, les agents prolifèrent plus rapidement que la gouvernance. Les équipes élaborent ce dont elles ont besoin, copient les informations d'identification et déploient des agents partout où elles le peuvent. Au fil du temps, personne ne sait exactement combien d'agents existent, à quelles données ils accèdent ou à qui ils appartiennent.

Agent Hub fournit une surface partagée où les agents sont enregistrés et découverts. Cela ne ralentit pas les équipes ; cela leur donne une valeur par défaut sûre. Lorsque la voie officielle est facile et visible, il y a beaucoup moins d'intérêt à créer des agents dans l'ombre.

Contrôlez sans centraliser le développement

Il est important de bien comprendre ce qu'un plan de contrôle n'est pas. Ce n'est pas un endroit où toute logique vit, et ce n'est pas un goulot d'étranglement que les équipes doivent négocier pour chaque changement. Agent Hub ne dit pas aux agents ce qu'ils doivent penser. Il définit la manière dont les agents participent au système.

Les agents raisonnent toujours de manière indépendante. Les équipes expédient toujours rapidement. Mais les règles d'engagement, d'identité, d'invocation et de coordination sont gérées de manière cohérente dans l'ensemble de l'écosystème.

Cette séparation est ce qui rend les systèmes d'agents durables au fur et à mesure de leur croissance.

Une fois qu'un plan de contrôle existe, la dernière pièce du puzzle devient évidente : l'exécution doit être appliquée et observée au moment de l'exécution. C'est là qu'entrent en jeu les passerelles et les API d'agent explicites, et c'est ce que nous examinerons ensuite.

API et passerelles pour les agents : rendre l'exécution des agents contrôlable

Une fois qu'un plan de contrôle existe, une question devient inévitable : où est réellement appliqué ce contrôle ?

Dans les systèmes d'agents, les décisions concernant l'identité, la politique et le routage n'ont pas d'importance à moins qu'elles ne soient appliquées au moment de l'exécution, au moment même où un agent essaie d'agir. C'est là que les passerelles et les API d'agent explicites deviennent essentielles. Sans eux, un plan de contrôle n'est que consultatif. Avec eux, ça devient réel.

Pourquoi l'exécution doit être explicite

L'un des modes de défaillance les plus courants dans les systèmes d'agents est l'exécution invisible. Un agent appelle un autre agent en tant que fonction locale. Cet agent invoque un outil. Un effet secondaire se produit. Tout « fonctionne », mais personne ne peut clairement voir ce qui s'est passé ni pourquoi.

Le problème n'est pas que l'exécution soit erronée. C'est parce que c'est caché.

TrueFoundry API d'agent force l'exécution de l'agent à être explicite. Au lieu d'appels implicites enfouis dans du code, les interactions entre agents deviennent des opérations de premier ordre. Chaque invocation est porteuse d'identité, de contexte et d'intention, et passe à chaque fois par la même infrastructure.

# TrueFoundry Agent API - explicit, governed agent execution
import httpx

response = httpx.post(
    "https://{controlPlaneURL}/api/llm/agent/chat/completions",
    headers={
        "Authorization": "Bearer {TFY_API_TOKEN}",
        "Content-Type": "application/json"
    },
    json={
        "model": "openai/gpt-4o",
        "messages": [{"role": "user", "content": "Search for information about Python"}],
        "mcp_servers": [
            {"integration_fqn": "common-tools", "tools": [{"name": "web_search"}]}
        ]
    }
)

Remarque : Le contrat d'API Agent Hub est actuellement en cours de développement actif. Pour connaître la syntaxe et les fonctionnalités les plus récentes, reportez-vous au Documentation sur l'API des agents.

Cet appel peut sembler simple, mais il représente un changement architectural majeur. L'agent n'agit plus de manière isolée. Son exécution fait l'objet d'une médiation, d'un suivi et d'une gouvernance.

Les passerelles en tant que points d'application, pas seulement des proxys

Dans les systèmes traditionnels, les passerelles sont souvent traitées comme des routeurs de trafic. Dans les systèmes d'agents, ce cadre est trop étroit. Les passerelles ne sont pas simplement des demandes de transfert, elles faire respecter l'intention.

La passerelle IA de TrueFoundry se situe entre les agents, les modèles et les serveurs MCP. Chaque exécution d'agent passe par ce canal. Cela permet au système d'évaluer les politiques avant que quoi que ce soit ne se passe : si un agent est autorisé à s'exécuter, à quels outils il peut accéder, quel modèle il doit utiliser et quels éléments doivent être enregistrés ou restreints.

Étant donné que toutes les exécutions passent par une passerelle partagée, l'application devient cohérente par défaut. Il n'est pas nécessaire que chaque agent réimplémente les contrôles d'accès, les nouvelles tentatives ou la journalisation. Ces préoccupations sont là où elles doivent être, en dehors de la logique des agents.

Accès sécurisé à l'outil et au serveur MCP

L'accès aux outils est l'endroit où les systèmes d'agents deviennent souvent dangereux. Les outils peuvent écrire des données, déclencher des systèmes externes ou effectuer des actions irréversibles. Lorsque les agents appellent directement les outils, les informations d'identification et la logique d'accès ont tendance à être copiées, ce qui crée des risques de sécurité et de conformité.

L'API Agent intègre les serveurs MCP via la passerelle, ce qui signifie que les outils sont invoqués dans des conditions contrôlées. Qu'un serveur MCP soit enregistré sur la plateforme ou fourni en externe, l'accès est médiatisé, authentifié et observable. Les agents obtiennent les fonctionnalités dont ils ont besoin sans détenir de secrets ni contourner les politiques.

Cela est particulièrement important dans les flux de travail d'agent à agent, où la décision d'un agent peut se répercuter sur plusieurs appels d'outils en aval.

L'observabilité et le coût en tant que signaux de première classe

Un autre avantage de l'exécution explicite est la visibilité. Comme les appels aux agents passent par une API et une passerelle partagées, il devient possible de suivre le comportement de bout en bout. Les équipes peuvent voir quel agent a initié une action, quels agents et outils en aval ont été impliqués, combien de temps a duré l'exécution et où les coûts se sont accumulés.

Dans les systèmes d'agents, le coût n'est pas simplement une question de facturation, c'est un signal comportemental. Un petit changement de raisonnement peut se traduire par de nombreux appels. Sans observabilité, les équipes perdent la capacité de comprendre ou de contrôler cette amplification.

L'exécution explicite rétablit cette compréhension.

Faire de l'autonomie quelque chose que vous pouvez exploiter

L'objectif des API et des passerelles pour agents n'est pas de limiter ce que les agents peuvent faire. C'est pour adopter un comportement autonome utilisable.

Les agents raisonnent toujours de manière indépendante. Ils continuent de collaborer et de déléguer. Mais ils le font dans le cadre d'un système capable de faire appliquer les règles, d'expliquer les résultats et d'évoluer en toute sécurité au fil du temps.

À ce stade, le schéma de base devient clair. Les systèmes agent-agent ne s'adaptent pas uniquement à l'intelligence. Ils évoluent lorsque l'autonomie est associée à une infrastructure capable de la gérer.

Cela nous amène à la dernière question : qu'est-ce qui détermine réellement le succès d'une économie d'agent à agent sur le long terme ?

L'infrastructure est ce qui fait de l'économie des agents une réalité

À mesure que les capacités des agents continuent de s'améliorer, le renseignement deviendra la partie la moins intéressante du système. Les meilleurs modèles seront plus faciles d'accès. Les techniques d'incitation se répandront rapidement. Ce qui semble avancé aujourd'hui deviendra une référence demain.

Le véritable facteur de différenciation ne sera pas l'intelligence des agents individuels. Il s'agira de savoir si les systèmes qui les entourent peuvent favoriser l'autonomie sans perdre le contrôle.

Les économies d'agent à agent introduisent une nouvelle classe de complexité. Les décisions se propagent entre les agents. Les actions déclenchent des effets en aval. Les coûts et les risques augmentent plus vite que les humains ne peuvent intervenir. Sans infrastructure, ces systèmes deviennent opaques, fragiles et difficiles à faire confiance.

Ce n'est pas la logique interne des agents qui rend les systèmes d'agents durables, mais séparation claire des préoccupations:

• les agents se concentrent sur le raisonnement et l'exécution des tâches
• les plans de contrôle définissent la manière dont les agents sont autorisés à interagir
• les passerelles appliquent l'identité, la politique et l'accès au moment de l'exécution
• l'exécution est observable, traçable et explicable

C'est là que les plateformes sont importantes.

Le hub d'agents et l'API d'agent de TrueFoundry ne cherchent pas à rendre les agents plus intelligents. Ils fournissent la couche d'infrastructure manquante qui permet aux systèmes d'agents de se comporter comme des systèmes distribués bien gérés au lieu de collections imprévisibles de scripts. Les agents deviennent détectables, composables et utilisables. L'autonomie devient une chose à laquelle les équipes peuvent avoir confiance.

L'économie d'agent à agent ne sera pas gagnée par des solutions ponctuelles ou des démonstrations intelligentes. Il sera construit par des plateformes qui fiabilisent l'autonomie à grande échelle. Le renseignement va se banaliser. L'infrastructure se différenciera.