Diop Daily #126 — September 2026

September 29, 2026 · 10 min read · tool contracts · machine recognition · institutional boundaries

The Description Is Part of the Tool

A tool that an agent cannot interpret is an inaccessible capability, even when its endpoint is healthy. The description, schema, authentication rule, quota, and response shape determine what the machine believes it may do before a single request is sent. That makes the tool declaration part of the product, part of the security boundary, and part of the institution's operating language.

Recent public signals make this visible. Google's September 24 announcement of remote Model Context Protocol support in Cloud API Gateway says that a tool's description is the primary signal an LLM uses to decide when to call it. The same announcement describes MCP discovery and REST invocation sharing authentication, quota, and logging policies. Although it is a product announcement rather than independent proof of safe deployment, it exposes the architectural seam: a machine meets an institution first through a declared vocabulary, then through an endpoint.

Before a machine can obey an institution, it has to recognize the institution's terms.

The tool is encountered before it is invoked

Human developers often treat documentation as a wrapper around the real software. An agent experiences the order differently. It encounters a name, a description, an input schema, a permission context, and an advertised result. Those elements shape the choice to invoke, the arguments it constructs, and the confidence it assigns to the response.

This turns language into an operational surface. “Search customers” does not carry the same boundary as “search active customer records for accounts assigned to the requesting team, returning only fields authorized by the account policy.” The second declaration gives the machine a jurisdiction, a population, and a limit. It also gives a reviewer something concrete to inspect when the call is wrong.

The distinction matters for small institutions as much as for large platforms. A community archive, a cooperative inventory system, or a public information service may have an API that works perfectly for a human engineer while remaining semantically opaque to an agent. The missing asset is often not another model. It is a vocabulary that states what the operation means, who may use it, what evidence it returns, and what a refusal looks like.

Discovery is already a policy decision

Google's API Gateway announcement contains a quiet warning alongside its convenience. In the public-preview design, tools/list is unauthenticated by default, which makes development easy while publishing tool names and input schemas to anyone who asks. Production systems are told to require a JSON Web Token for discovery, while the underlying REST authentication still governs tools/call.

The lesson is broader than one gateway: discoverability is a form of exposure. A tool can be protected at execution time and still reveal sensitive institutional structure at discovery time. Names, descriptions, fields, and error messages can disclose the shape of a ledger, the existence of a vulnerable workflow, or the categories by which a public office sorts people.

A serious tool contract therefore answers two different questions:

Recognition: what may an authorized machine understand about this capability, and under which identity may it discover that description?
Invocation: which principal may call it, with which arguments, against which records, under what quota, and with what logged result?

Collapsing these questions produces a thin notion of access control. An agent can be allowed to call a tool while being given a misleading or overbroad description. It can also be denied at the endpoint after learning more than it should about the institution. The boundary needs both semantic precision and policy continuity.

Schemas carry jurisdiction

A schema is often described as a technical shape for data. In agent systems, it also carries a theory of jurisdiction. Field names decide which distinctions are visible. Required fields decide which facts must exist before an action can proceed. Enumerations define the categories the machine can select. Error states decide whether uncertainty becomes a refusal, a retry, or a silent omission.

That is why imported schemas deserve the same scrutiny as imported models. A payment tool built around card settlement may omit the consent and reconciliation steps required by a mobile-money cooperative. A research archive schema may preserve an English title while discarding the local-language name by which a community recognizes the work. A customer record may encode household relations as irrelevant text even when those relations determine who may authorize a transaction.

W3C's June announcement of a workshop on e-commerce for humans and AI agents makes the representation problem explicit. The web has historically been shaped for human readers, even when pages also expose structured data through APIs or embedded JSON-LD. Agents are becoming intermediaries between content and users, so creators and publishers must consider how machine systems interpret what they publish. The workshop focuses on e-commerce, yet the underlying issue reaches archives, public services, education, and cultural production: what a machine can recognize becomes part of how an institution can be reached.

Machine recognition should therefore be treated as an editorial and constitutional task. The institution chooses the categories, examples, language variants, refusal states, and evidence requirements that define a legitimate operation. External frameworks can provide transport and syntax. They cannot decide what a local record means.

Local execution does not remove the need for a contract

Google's September 23 announcement of local model support in the Antigravity SDK describes offline execution, local GPU and RAM use, privacy benefits, and hybrid workflows in which a cloud model plans while local models perform work on-device. The announcement uses a recorded demonstration to report that most tokens in that run were handled locally; that figure remains a vendor-reported example rather than a general performance guarantee.

The architectural point survives the marketing boundary. Local execution can keep code, requests, or culturally sensitive records within an institution's physical or legal perimeter. It does not automatically make the institution's interfaces legible. A local agent can still misunderstand a Wolof term, infer authority from the wrong field, or call a tool whose description hides a consequential side effect.

NIST's AI Agent Standards Initiative places open protocols beside authentication, identity infrastructure, and security evaluations. Its public framing supports a useful division of labor: protocols can help systems interoperate, identity can establish who is acting, and evaluation can test whether the interaction is secure. The institution still needs to define the local semantics that make a call legitimate. Sovereignty lives in that definition, not in the location of the GPU alone.

Where the investable surface is widening

The commercial object is the tool contract: the shared semantic and conformance layer between an institution's capability and the machine that seeks to use it. It sits closer to a revenue-bearing boundary than generic documentation because it determines discovery, eligibility, execution, evidence, and correction.

Contract registries: systems that version names, descriptions, schemas, examples, refusal states, owners, and policy links as one reviewable unit.
Discovery controls: authorization for who may see a capability, its fields, its jurisdiction, and its machine-readable metadata.
Conformance testing: tests that ask whether the declared meaning matches the live endpoint, including permissions, quota behavior, error states, and response provenance.
Semantic translation: layers that preserve local terms, multilingual distinctions, and institutional categories when a common protocol crosses language or system boundaries.
Boundary observability: records of what an agent believed it was calling, what the tool actually received, which policy applied, and how a human corrected the mismatch.

Underwriting can begin with measurable questions. How often does a description lead to an invalid call? Which fields cause the most human correction? Can a new model discover the same capability without being granted broader access? Do schema changes trigger review before they alter agent behavior? Can the institution export the contract, its test cases, and its decision history when it changes gateway or model provider?

OpenAI's September account of AI-native workflows supplies a complementary market signal. The examples of Basis, Clay, and Exa connect agents to company context and tools, preserve persistent workspaces or reusable skills, and keep tests and human review near consequential actions. The cases are vendor-reported, so they should be read as design evidence rather than universal adoption data. Their common pattern is clear: a workflow becomes repeatable when context, permissions, evidence, and decision rights remain attached to the work.

Build one contract before adding another agent

A practical experiment needs one real tool, one named owner, and one consequential boundary. Write the description as if a new machine will encounter it without a private conversation. Define the records it may touch, the identities it accepts, the fields it refuses, the evidence it returns, and the circumstances that require a person. Test discovery separately from invocation. Then ask an independent reviewer to compare the declaration with the live behavior.

Repeat the test in the languages and institutional settings that the system claims to serve. A French description that loses a distinction present in the English schema is a conformance defect. A translation that makes a refusal sound like success is a safety defect. A local-language name that cannot be searched is a distribution defect. These are engineering failures with social consequences, and they can be measured before a fleet makes them expensive.

The next stage of agent infrastructure will be judged at these boundaries. The winning systems will help institutions expose capabilities without exposing more authority than intended, preserve local meaning across machine handoffs, and prove that the declared contract still matches the action. A machine does not enter an institution through intelligence alone. It enters through the words, fields, permissions, and evidence that tell it where it is.

Sources

La description fait partie de l’outil

Un outil qu’un agent ne peut pas interpréter est une capacité inaccessible, même lorsque son endpoint fonctionne. La description, le schéma, la règle d’authentification, le quota et la forme de la réponse déterminent ce que la machine croit pouvoir faire avant l’envoi d’une seule requête. La déclaration de l’outil devient ainsi une partie du produit, une partie de la frontière de sécurité et une partie du langage opérationnel de l’institution.

Les signaux publics récents rendent ce point visible. Dans son annonce du 24 septembre sur la prise en charge du Model Context Protocol à distance dans Cloud API Gateway, Google indique que la description d’un outil constitue le signal principal utilisé par un LLM pour décider de l’appeler. La même annonce décrit une découverte MCP et une invocation REST qui partagent les politiques d’authentification, de quota et de journalisation. Cette annonce de produit ne fournit pas une preuve indépendante de déploiement sûr, mais elle expose la jointure architecturale : une machine rencontre d’abord une institution par un vocabulaire déclaré, puis par un endpoint.

Avant d’obéir à une institution, une machine doit reconnaître ses termes.

L’outil est rencontré avant d’être invoqué

Les développeurs humains traitent souvent la documentation comme une enveloppe autour du véritable logiciel. Un agent vit cette séquence autrement. Il rencontre un nom, une description, un schéma d’entrée, un contexte de permission et un résultat annoncé. Ces éléments orientent le choix d’invoquer l’outil, les arguments construits et le degré de confiance accordé à la réponse.

Le langage devient ainsi une surface opérationnelle. « Rechercher les clients » ne pose pas la même frontière que « rechercher les dossiers clients actifs des comptes attribués à l’équipe demandeuse, en ne renvoyant que les champs autorisés par la politique du compte ». La seconde déclaration donne à la machine une juridiction, une population et une limite. Elle donne aussi au réviseur un objet concret à inspecter lorsque l’appel est erroné.

Cette distinction concerne autant les petites institutions que les grandes plateformes. Une archive communautaire, un système d’inventaire coopératif ou un service d’information publique peut disposer d’une API parfaitement utilisable par un ingénieur humain tout en restant sémantiquement opaque pour un agent. L’actif manquant n’est souvent pas un modèle supplémentaire. C’est un vocabulaire qui précise le sens de l’opération, ceux qui peuvent l’utiliser, les preuves qu’elle renvoie et la forme d’un refus.

La découverte est déjà une décision de politique

L’annonce de Google sur API Gateway contient un avertissement discret à côté de sa commodité. Dans la conception en préversion publique, tools/list n’est pas authentifié par défaut, ce qui facilite le développement tout en publiant les noms des outils et leurs schémas d’entrée à quiconque les demande. Pour la production, le système recommande d’exiger un jeton JSON Web pour la découverte, tandis que l’authentification REST sous-jacente continue de gouverner tools/call.

La leçon dépasse une seule passerelle. La découvrabilité est une forme d’exposition. Un outil peut être protégé au moment de l’exécution tout en révélant, lors de la découverte, la structure sensible de l’institution. Les noms, descriptions, champs et messages d’erreur peuvent dévoiler la forme d’un registre, l’existence d’un workflow vulnérable ou les catégories par lesquelles un service public classe les personnes.

Un contrat d’outil sérieux répond donc à deux questions différentes :

Reconnaissance : que peut comprendre une machine autorisée au sujet de cette capacité, et sous quelle identité peut-elle découvrir cette description ?
Invocation : quel mandant peut l’appeler, avec quels arguments, sur quels dossiers, sous quel quota et avec quel résultat journalisé ?

Confondre ces deux questions produit une notion étroite du contrôle d’accès. Un agent peut être autorisé à appeler un outil tout en recevant une description trompeuse ou trop large. Il peut aussi être refusé par l’endpoint après avoir appris davantage qu’il ne le fallait sur l’institution. La frontière exige à la fois une précision sémantique et une continuité de politique.

Les schémas portent une juridiction

On décrit souvent un schéma comme une forme technique pour les données. Dans les systèmes agentiques, il porte aussi une théorie de la juridiction. Les noms de champs décident quelles distinctions restent visibles. Les champs obligatoires décident quels faits doivent exister avant une action. Les énumérations définissent les catégories que la machine peut sélectionner. Les états d’erreur décident si l’incertitude devient un refus, une nouvelle tentative ou une omission silencieuse.

Les schémas importés méritent donc le même examen que les modèles importés. Un outil de paiement construit autour du règlement par carte peut omettre les étapes de consentement et de rapprochement nécessaires à une coopérative utilisant l’argent mobile. Un schéma d’archive scientifique peut conserver un titre anglais tout en supprimant le nom en langue locale par lequel une communauté reconnaît l’œuvre. Un dossier client peut encoder les relations familiales comme un texte sans importance alors que ces relations déterminent qui peut autoriser une transaction.

L’annonce de juin du W3C sur un atelier consacré au commerce électronique pour les humains et les agents d’IA rend le problème de représentation explicite. Le Web a historiquement été façonné pour des lecteurs humains, même lorsque les pages exposent aussi des données structurées par des API ou du JSON-LD intégré. Les agents deviennent des intermédiaires entre le contenu et les usagers ; les créateurs et les éditeurs doivent donc réfléchir à la manière dont les systèmes machines interprètent ce qu’ils publient. L’atelier porte sur le commerce électronique, mais le problème s’étend aux archives, aux services publics, à l’éducation et à la production culturelle : ce qu’une machine peut reconnaître devient une partie de la manière dont on peut atteindre une institution.

La reconnaissance par machine doit donc être traitée comme une tâche éditoriale et constitutionnelle. L’institution choisit les catégories, les exemples, les variantes linguistiques, les états de refus et les exigences de preuve qui définissent une opération légitime. Les cadres externes peuvent fournir le transport et la syntaxe. Ils ne peuvent pas décider ce que signifie un dossier local.

L’exécution locale ne supprime pas le besoin d’un contrat

L’annonce publiée par Google le 23 septembre sur la prise en charge de modèles locaux dans l’Antigravity SDK décrit une exécution hors ligne, l’utilisation du GPU et de la RAM locaux, des bénéfices de confidentialité et des workflows hybrides dans lesquels un modèle cloud planifie tandis que des modèles locaux exécutent le travail sur l’appareil. L’annonce utilise une démonstration enregistrée pour rapporter que la plupart des tokens de cette exécution ont été traités localement ; ce chiffre reste un exemple déclaré par le fournisseur, et non une garantie générale de performance.

Le point architectural reste valable au-delà de la présentation commerciale. L’exécution locale peut garder du code, des requêtes ou des dossiers culturellement sensibles dans le périmètre physique ou juridique d’une institution. Elle ne rend pas automatiquement les interfaces de cette institution intelligibles. Un agent local peut toujours mal comprendre un terme wolof, déduire l’autorité du mauvais champ ou appeler un outil dont la description dissimule un effet conséquent.

L’AI Agent Standards Initiative du NIST place les protocoles ouverts à côté de l’authentification, de l’infrastructure d’identité et des évaluations de sécurité. Son cadrage soutient une division utile du travail : les protocoles peuvent aider les systèmes à interopérer, l’identité peut établir qui agit et l’évaluation peut tester la sécurité de l’interaction. L’institution doit encore définir les sémantiques locales qui rendent un appel légitime. La souveraineté réside dans cette définition, et non dans l’emplacement du GPU seul.

Là où la surface d’investissement s’élargit

L’objet commercial est le contrat d’outil : la couche sémantique et de conformité partagée entre la capacité d’une institution et la machine qui cherche à l’utiliser. Cette couche se trouve plus près d’une frontière génératrice de revenus qu’une documentation générique, parce qu’elle détermine la découverte, l’éligibilité, l’exécution, la preuve et la correction.

Registres de contrats : systèmes qui versionnent les noms, descriptions, schémas, exemples, états de refus, responsables et liens de politique comme une seule unité révisable.
Contrôles de découverte : autorisation de ceux qui peuvent voir une capacité, ses champs, sa juridiction et ses métadonnées lisibles par machine.
Tests de conformité : tests qui demandent si le sens déclaré correspond à l’endpoint réel, y compris les permissions, le comportement du quota, les états d’erreur et la provenance de la réponse.
Traduction sémantique : couches qui préservent les termes locaux, les distinctions multilingues et les catégories institutionnelles lorsqu’un protocole commun traverse les langues ou les systèmes.
Observabilité de frontière : relevés de ce qu’un agent croyait appeler, de ce que l’outil a réellement reçu, de la politique appliquée et de la manière dont un humain a corrigé le décalage.

La souscription peut commencer par des questions mesurables. À quelle fréquence une description provoque-t-elle un appel invalide ? Quels champs entraînent le plus de corrections humaines ? Un nouveau modèle peut-il découvrir la même capacité sans recevoir un accès élargi ? Les changements de schéma déclenchent-ils une revue avant de modifier le comportement de l’agent ? L’institution peut-elle exporter le contrat, ses cas de test et son historique de décision lorsqu’elle change de passerelle ou de fournisseur de modèles ?

L’analyse publiée par OpenAI en septembre sur les workflows des entreprises natives de l’IA fournit un signal de marché complémentaire. Les exemples de Basis, Clay et Exa relient les agents au contexte et aux outils de l’entreprise, préservent des espaces de travail persistants ou des compétences réutilisables et maintiennent tests et revue humaine près des actions conséquentes. Ces cas sont rapportés par le fournisseur ; ils doivent donc être lus comme des éléments de conception et non comme des données universelles d’adoption. Leur forme commune est claire : un workflow devient répétable lorsque le contexte, les permissions, les preuves et les droits de décision restent attachés au travail.

Construire un contrat avant d’ajouter un autre agent

Une expérience pratique exige un outil réel, un responsable nommé et une frontière conséquente. Rédigez la description comme si une nouvelle machine allait la rencontrer sans conversation privée. Définissez les dossiers qu’elle peut toucher, les identités acceptées, les champs refusés, les preuves renvoyées et les circonstances qui exigent une personne. Testez séparément la découverte et l’invocation. Demandez ensuite à un réviseur indépendant de comparer la déclaration au comportement réel.

Répétez le test dans les langues et les contextes institutionnels que le système prétend servir. Une description française qui perd une distinction présente dans le schéma anglais constitue un défaut de conformité. Une traduction qui fait passer un refus pour un succès constitue un défaut de sécurité. Un nom en langue locale impossible à rechercher constitue un défaut de distribution. Ce sont des défaillances d’ingénierie aux conséquences sociales, et elles peuvent être mesurées avant qu’une flotte ne les rende coûteuses.

La prochaine étape de l’infrastructure agentique sera jugée à ces frontières. Les systèmes les plus solides aideront les institutions à exposer des capacités sans exposer plus d’autorité que prévu, à préserver le sens local lors des transferts entre machines et à prouver que le contrat déclaré correspond encore à l’action. Une machine n’entre pas dans une institution par l’intelligence seule. Elle y entre par les mots, les champs, les permissions et les preuves qui lui indiquent où elle se trouve.