> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Agents > Ce que chaque couche de l'architecture doit faire quand le participant n'est pas une personne — le runtime hors du protocole, l'admission sous charge d'agents, l'autorisation comme transaction, et un environnement rejouable. La direction visée est celle où **une personne est représentée par plusieurs agents**, chacun agissant sur une part de ce qu'elle veut. Ni une personne avec un outil, ni un bot exécutant un script figé : plusieurs contreparties face au marché, toutes répondant d'un seul compte. Quand les participants changent, la microstructure de marché change avec eux. Les tailles d'ordre baissent, les débits de messages montent, le rapport annulations/exécutions se creuse encore, et le flux acquiert une corrélation que le flux humain n'a pas : des agents qui lisent le même signal arrivent à la même conclusion au même instant. Rien de tout cela ne se règle en ajoutant une fonctionnalité. Cela se règle en traversant l'architecture une couche à la fois et en demandant ce que chacune doit faire différemment. Cette page est ce passage, dans l'ordre, avec l'état réel de chaque couche.
1 · Application
2 · Réseau
3 · Exécution
4 · État
Le runtime se tient hors du protocoleet ne détient aucun privilège — pas de latence moindre, pas de données plus tôt, aucune interface qu'un tiers ne puisse atteindre
L'admission, quand les émetteurs sont des agentsune annulation en retard est pire qu'un ordre en retard, et l'équité se suit sur l'historique récent plutôt que message par message
L'autorisation est une transactionavec une hauteur de bloc, dans le jeu d'instructions fermé — et la révoquer annule les ordres en carnet de l'agent dans le même bloc
Un environnement rejouable, versionné par blocpoint-in-time par construction plutôt que par discipline
Les mêmes quatre couches que l'aperçu de l'architecture. Seule la question change : que doit faire chacune quand le participant n'est pas une personne ?
| Couche | Ce qui change | Statut | | --------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------ | | **Application** | Le runtime — recherche et exécution — se tient hors du protocole et ne détient aucun privilège | Engagé | | **Réseau** | L'admission d'un flux en rafales, corrélé, riche en annulations | Livré, avec deux questions ouvertes | | **Exécution** | L'autorisation devient une transaction assortie de termes | Livrée en tout-ou-rien ; les termes sont engagés | | **État** | La chaîne est l'environnement dans lequel un agent est évalué | Livré |

1 · Application — le runtime se tient dehors, et il le doit

Le runtime d'agent est un cadre de recherche et d'exécution : il forme une vue, la transforme en quelque chose d'exécutable, et la présente au lieu d'échange. Il tourne sur la couche application, au même étage que les front ends et les clients d'API, et **il ne fait pas partie du protocole**. Ce placement est une contrainte physique avant d'être une préférence de conception. Un modèle raisonne en secondes ; un marché bouge en millisecondes. Rien qui doive appeler un modèle ne peut se trouver sur le chemin qu'emprunte réellement un ordre — autrement dit, **le protocole ne contient aucun modèle**. Non par omission, mais parce qu'un modèle sur le chemin de règlement détruirait la seule propriété sur laquelle tout le reste ici repose. Le chemin d'exécution doit produire les mêmes octets sur chaque nœud, et l'inférence ne le fait pas. Le runtime vit donc dehors, et la question honnête devient : que lui doit le protocole ? Cinq choses, toutes engagées plutôt que livrées. | | Ce que cela donne à un agent | | -------------------------- | ---------------------------------------------------------------------------------------------- | | **Simulation pré-trade** | Évaluer ce qu'un ordre ferait contre l'état validé avant de le soumettre | | **Soumission idempotente** | Réessayer une soumission ambiguë sans risquer une exposition en double | | **États terminaux nommés** | Aucune issue dont le résultat soit inconnu — toute action se termine dans un état qui a un nom | | **Reprise définie** | Un agent qui redémarre sait où il en était et quoi faire ensuite | | **Reçus attribués** | Ce que l'agent a fait, sous quelle autorité et à quel coût — en sortie de protocole | Voir [Pour la suite](/fr/protocol/roadmap/whats-next) pour les statuts. Le runtime ne détient aucun chemin privilégié. Pas de latence moindre, pas de données plus tôt, aucune interface qu'un runtime tiers ne puisse atteindre. Cela mérite d'être écrit plutôt que supposé, car l'architecture affirme ailleurs que rien ne se tient entre un trader et la chambre de compensation — et un outil maison doté d'une voie réservée serait exactement ce quelque chose.

2 · Réseau — l'admission, quand les émetteurs sont des agents

Le mempool décide de ce qui mérite d'être conservé, de la transaction suivante d'un émetteur, des pairs qui en entendent parler, et de ce qui saute quand la demande dépasse la capacité. Le flux d'agents pèse sur les quatre, et deux des propriétés qui l'absorbent sont déjà en place pour des raisons antérieures aux agents. **Une annulation en retard est pire qu'un ordre en retard.** Le [mempool](/fr/protocol/architecture/mempool) traite par conception le trafic d'ordres et celui d'annulations comme asymétriques. Les agents rendent cette asymétrie plus extrême, leur rapport annulations/exécutions étant supérieur à celui d'un humain, mais la forme du problème est celle autour de laquelle cette couche a été bâtie. **L'équité se suit sur l'historique récent, pas message par message.** Le mempool tient un relevé glissant des émetteurs et des types de trafic qui ont récemment consommé de la capacité, et façonne en conséquence ce qu'il sert ensuite. **C'est la partie qui compte pour les rafales corrélées** : quarante agents qui annulent sur le même signal, ce n'est pas quarante fois la charge moyenne étalée uniformément, c'est un pic. Une limite par message le manque. Une mémoire de qui a récemment été bruyant, non. **Le consensus ne grossit pas avec le débit.** Les transactions atteignent les validateurs par lots dont la disponibilité est prouvée avant qu'une proposition puisse les référencer, si bien qu'une proposition de bloc porte des empreintes et non des corps. Une population d'agents qui multiplie par dix les débits de messages n'augmente pas d'un octet la taille des messages de consensus. Le bloc supprime la course **à l'intérieur** de lui : deux transactions du même bloc ont une préséance que chaque nœud calcule à l'identique. **Cette garantie commence à la frontière du bloc.** Y entrer reste une course, façonnée par l'équité au niveau de l'émetteur plutôt qu'éliminée par elle. L'admission au mempool n'est pas l'inclusion. Deux questions restent ouvertes à cette couche, et toutes deux ne deviennent matérielles qu'aux volumes des agents, pas à ceux des humains. **Ce que devrait coûter une annulation.** L'exécution place déjà les annulations en premier — elles tournent dans la phase précédant tout ce qui peut prendre de la liquidité. La version réseau de cette question n'est pas tranchée : une annulation peu coûteuse et prioritaire est ce qui rend le quoting défendable, et c'est aussi le moyen le moins cher d'inonder un mempool. Savoir si les annulations doivent porter leur propre comptabilité de capacité, distincte des placements, n'est pas décidé. **Où appartient l'idempotence.** Un agent sans réponse resoumet. La soumission idempotente est engagée à la couche exécution et règle la conséquence qui compte — pas d'exposition en double. Elle ne règle pas la version réseau : le mempool doit-il reconnaître une resoumission comme la même intention, ou porter les deux et laisser l'exécution dédupliquer ? Sous une tempête de reprises, ces deux choix ne se comportent pas pareil. Une chose est délibérément absente de la liste : une voie d'admission réservée aux agents. L'accès prioritaire est ce que toute place centralisée finit par vendre, et cela contredirait l'affirmation que rien ne se tient entre un trader et la chambre de compensation. Le flux des agents passe par la même porte.

3 · Exécution — l'autorisation est une transaction

C'est la couche où le modèle de compte change, et tout le changement découle d'un seul fait. **Confier un compte à un agent est une transaction on-chain.** Pas un formulaire envoyé, pas une clé d'API émise depuis une page de réglages, pas une ligne dans la base d'un opérateur. Une transaction, dans un bloc, à une hauteur, signée par le compte qui l'a accordée — donc quelque chose que n'importe quel tiers peut trouver, lire et vérifier sans demander la permission. Trois conséquences en découlent, et chacune est une chose qu'une clé d'API ne peut pas faire. **Elle est dans le jeu d'instructions fermé.** L'autorisation d'agent est l'une des opérations énumérées du [noyau](/fr/protocol/architecture/kernel). Une chaîne généraliste ne peut pas l'exprimer — le sens de l'appel serait du bytecode opaque. Une place centralisée l'applique dans un logiciel que vous ne pouvez pas inspecter. Ici l'autorité et ses limites **sont l'instruction**, et c'est pourquoi la limite est vérifiable au lieu d'être promise. **Elle porte ce que l'agent peut faire — et ne peut pas porter ce qu'il ne peut pas.** Une autorisation peut dire ce que l'agent peut détenir, combien il peut perdre, quels marchés il peut toucher, s'il peut changer de mode de marge. Elle **ne peut pas dire « retirer »**. Ce n'est pas un réglage laissé sur off : il n'existe pas de terme à écrire. Un agent qui opère un compte n'a aucun chemin exprimable pour en sortir des fonds. **La révoquer annule les ordres en carnet de l'agent.** La révocation est elle aussi une transaction, et elle atterrit dans un bloc dont le [séquencement](/fr/trading/tx-sequencing) fait déjà tourner les annulations avant tout ce qui peut prendre de la liquidité. Les ordres que l'agent a laissés au carnet partent donc dans le bloc même où part l'autorité. Sur une place où la révocation est une écriture en base, la clé cesse de fonctionner et les ordres en carnet sont dans un état indéfini. Ici l'arrêt est prouvable, et n'importe qui peut trouver la hauteur à laquelle il a eu lieu.
AccorderUne transaction au bloc NElle porte la portée : ce que l'agent peut détenir, peut perdre, peut négocier. Elle ne peut pas porter un retrait — ce terme n'existe pas
AgirChaque action nomme son autoritéAttribuée au compte qui l'a accordée, pas seulement à l'agent qui l'a soumise
RévoquerUne transaction au bloc MLes ordres en carnet de l'agent sont annulés dans le même bloc, avant que ne s'exécute quoi que ce soit qui pourrait prendre de la liquidité
Aucune des trois n'est une écriture en base dont il faut vous informer. Chacune est une transaction que n'importe qui trouve à une hauteur.
Aujourd'hui l'octroi est tout-ou-rien avec une expiration. Les termes plus riches ci-dessus — ce qu'un agent peut détenir, peut perdre, peut faire ensuite — sont engagés et non livrés ; voir [Pour la suite](/fr/protocol/roadmap/whats-next). **Ce qui tient déjà, c'est la part qu'on ne peut pas ajouter après coup** : l'autorité est un objet de protocole et non l'enregistrement qu'un opérateur en fait.

Ce que la place porte déjà pour le runtime

Un runtime de trading qui doit protéger un utilisateur sur une place ordinaire finit par se construire son propre noyau privilégié : un registre de positions qu'il tient et rapproche lui-même, un contrôle de risque pré-trade qu'il exécute en espérant que la place calcule pareil, et un journal d'audit qu'il écrit sans pouvoir prouver qu'il n'a pas été modifié. **Les trois sont de la redondance face à une place qui ne montrera pas ses livres.** Ici, trois de ces choses sont des propriétés du protocole. La [chambre de compensation](/fr/protocol/architecture/clearinghouse) est l'unique rédactrice du registre. L'étape de risque tourne avant l'appariement, dans le même bloc. Le journal d'audit est la chaîne, et chaque changement d'état porte la transaction qui l'a causé. Il reste au runtime la quatrième — une passerelle d'ordres idempotente — et c'est un problème d'interface, pas de confiance.

Appariement : le bloc est déjà le lot

Le flux d'agents augmente la fréquence et réduit la taille de ce qui atteint le carnet, soit exactement la microstructure qu'on invoque le plus souvent pour plaider l'enchère par lots : des intervalles discrets, dénoués ensemble, sans avantage à arriver une microseconde plus tôt. Cette propriété tient **déjà** ici, et non parce qu'une enchère par lots a été ajoutée. Le temps à l'intérieur d'un bloc est la position validée par le consensus, pas une horloge locale : **aucun avantage sub-milliseconde n'existe dans un bloc**. Et les annulations tournent avant tout ordre agressif, si bien qu'une cotation périmée peut être retirée sans être ramassée par un ordre arrivé en même temps que l'annulation. Le bloc est un intervalle discret dénoué ensemble. Il est arrivé comme **conséquence** de l'exécution d'un ordonnancement validé, pas comme un ajout de design de marché. Savoir si quoi que ce soit au-delà se justifie — et la priorité prix-temps continue et les enchères par lots fréquentes sont des **alternatives et non des compléments**, puisqu'un lot supprime délibérément la priorité temporelle en son sein — est à l'étude, pas en construction.

4 · État — la chaîne est l'environnement

Un agent ne vaut que ce contre quoi il a été évalué, et c'est dans l'évaluation que se produit l'essentiel des échecs. Une stratégie rentable en simulateur qui échoue en production n'a en général pas rencontré un marché nouveau ; elle a rencontré un simulateur qui n'était pas la place. La [couche d'état](/fr/protocol/architecture/state/model) supprime cet écart par construction plutôt que par discipline. L'état est versionné par bloc et chaque changement est attribué à la transaction qui l'a causé : rejouer un bloc rejoue donc **l'environnement** et non un modèle de celui-ci — la machine à états même qui exécutera l'agent, sur les entrées que le réseau a validées. C'est le cinquième contrôle de [Vérifiez vous-même](/fr/developers/verify), et c'est ce qui fait d'un backtest ici un objet d'une autre nature qu'un backtest contre l'API historique d'une bourse. La propriété plus subtile, c'est que tout cela est **point-in-time par construction**. Un jeu de données assemblé depuis l'API d'une bourse n'est point-in-time que si celui qui l'a assemblé a été soigneux, et le regard vers l'avenir se glisse par des interstices que personne ne remarque : un champ rempli après coup, une correction appliquée à l'historique, un prix de référence révisé. Ici la question ne se pose pas : l'état d'un bloc est ce qui était vrai à ce bloc, parce que c'est la seule forme que l'état ait jamais eue.

Ce qui devient plus difficile

Construire pour des agents n'est pas seulement une liste de choses qui s'améliorent. **Le déterminisme est à double tranchant.** Un agent peut prédire ce que son propre ordre fera avant de le soumettre, parce que la même entrée produit le même résultat sur chaque nœud. **L'agent de quelqu'un d'autre le peut aussi, à propos du vôtre.** La reproductibilité augmente à la fois votre capacité à planifier et votre prévisibilité, et la seconde n'est pas gratuite. **La liquidité d'agents est une liquidité corrélée.** Les teneurs de marché humains se retirent à des moments différents parce qu'ils remarquent à des moments différents. Des agents qui lisent le même état public arrivent ensemble à la même conclusion. Un carnet soutenu par des agents est plus profond un jour ordinaire et peut s'amincir plus vite le jour qui compte — un risque de structure de marché que les absorbeurs du protocole sont faits pour encaisser, pas un risque qu'ils suppriment. **L'oracle lit des places où les agents négocient aussi.** La certification lie un prix au bloc qui l'a consommé ; elle ne rend pas le marché sous-jacent inmanipulable, et une population d'agents agissant sur des signaux corrélés est une façon de plus pour le sous-jacent de bouger d'un bloc. Voir [ce que l'oracle garantit et ne garantit pas](/fr/protocol/architecture/oracle). **L'auto-évaluation d'un agent n'est pas une preuve.** Le retour du trading est bruité et non stationnaire là où celui du code ne l'est pas — un compilateur vous dit que vous aviez tort, une semaine profitable ne vous dit pas que vous aviez raison. Tout ce qu'une place construit pour des agents doit traiter le compte rendu qu'un agent fait de sa propre performance comme une **entrée adverse** et non comme une mesure. C'est l'une des raisons pour lesquelles les contrôles de [Vérifiez vous-même](/fr/developers/verify) sont bâtis autour de ce qui peut être recalculé plutôt que de ce qui peut être rapporté.

Pour aller plus loin

Les quatre phases, et pourquoi c'est le compte qui doit changer. Les contrôles qui font de l'évaluation d'un agent autre chose qu'une affirmation. Ce qu'il reste à prendre sur parole, une fois vérifié le vérifiable. Le statut du runtime d'agent et des termes d'autorisation.