Diop Daily #141 — October 2026

October 16, 2026 · 8 min read · capability distribution · machine-readable software · institutional control

The Package Must Explain Itself

An agent that can install a capability has crossed a threshold that a conventional software installer never had to face. The machine is not merely fetching code. It is deciding whether a bundle is relevant, what authority it requires, which dependencies it can touch, how it should be evaluated, and whether its owner has made a claim that the institution can accept. A package that cannot answer those questions remains opaque at the moment it becomes operational.

This changes the unit of distribution. The useful object is not a repository with a README added for humans after implementation. It is a capability package whose identity, purpose, inputs, permissions, dependencies, tests, ownership, and removal path are legible before installation. The package must explain itself because the next operator may be an agent acting on behalf of a person who will never inspect the source tree.

When software can recruit its own operator, metadata becomes part of the control plane.

The manifest arrives before trust

Google’s October 15 description of google/adk-recipes makes this shift unusually concrete. The repository is organized into reference patterns, installable vertical plugins, and deployable services. Each recipe carries a validated manifest, an AGENTS.md file that instructs a coding assistant how to use it, and, for the deployable layers, a container definition and runnability test. The repository is designed to be discovered and consumed by agents as well as developers.

That structure is a product decision. A manifest is not decorative documentation; it is an admission surface. It tells a machine what a capability claims to do, what it owns, how it is licensed, which environment it expects, and which checks stand behind the claim. The assistant can then compare a candidate package with a task, a policy, a budget, and a security boundary before it writes files or invokes a tool.

A capability package should expose at least:

Identity: a stable name, version, publisher, ownership record, and relationship to earlier releases.
Function: the task it performs, the inputs it accepts, the outputs it produces, and the cases it refuses.
Authority: the files, networks, secrets, accounts, data classes, and external services it may reach.
Dependencies: models, runtimes, libraries, tools, registries, and human approvals required for a valid execution.
Evidence: tests, evaluation fixtures, supported environments, known limitations, and the date on which the claims were checked.
Correction: update, revocation, rollback, deletion, and notification procedures when the package or one of its dependencies changes.

These fields turn discovery into a reasoned decision. They also give the institution a way to refuse a package without pretending that refusal is a failure of intelligence. An agent may reject a useful capability because its license is unclear, its requested permission is too broad, its evaluation is stale, or its correction path is missing. A bounded refusal is an operating feature.

Distribution is a governance event

Software distribution has always carried authority, but the authority was often mediated by a person. A developer read the documentation, inspected the dependency tree, ran a test, and decided whether to merge. Agentic distribution compresses those steps into a runtime that must act quickly while preserving the institution’s right to understand and reverse the decision.

NIST’s AI Agent Standards Initiative places open protocols, authentication and identity infrastructure, and security evaluations in the same strategic frame. The initiative describes work on agents that operate securely on behalf of users and interoperate across systems. Its importance for capability packages is direct: identity tells the institution who is making the claim, evaluation tells it what has been checked, and open protocols determine whether the package can be moved or examined outside one vendor’s environment.

Google’s same-day guidance on evaluating AI agents supplies the operational discipline. It recommends beginning with critical user journeys, keeping a frozen golden dataset while changing one variable, combining human review with automated checks, and measuring latency, token consumption, cost, and tool-call counts alongside answer quality. It also argues for trace conventions that keep evaluation independent of a particular orchestration framework.

The package therefore needs a release record, not only a version number. That record should say which journeys it passed, which environment produced the result, which checks were boolean and repeatable, which limits remain open, and what changes require a new evaluation. A package that silently changes its tools or permissions while preserving its version has not maintained compatibility; it has changed the institution’s risk.

The African question is who owns the catalogue

Agent-ready distribution will produce new catalogues of skills, plugins, recipes, datasets, connectors, and deployable services. The catalogue will influence which capabilities are visible, trusted, affordable, and easy to install. That makes the registry a political and economic institution, not a neutral shelf.

African laboratories, publishers, universities, cooperatives, and public agencies should be able to publish capabilities in their own languages, describe local data categories, set jurisdictional limits, and retain the authority to withdraw or revise a package. A registry that only accepts the categories of an external platform can make local knowledge available while making local institutions invisible. Interoperability should expand the vocabulary of participation, not narrow it to whatever a foreign marketplace can index.

This is where historical method becomes an engineering discipline. A source is not strong because it is present in an archive; it is strong when its origin, context, limits, and chain of transmission can be examined. A capability package deserves the same treatment. Its manifest should let another institution ask where it came from, what it assumes, what it can affect, and how to challenge its claims.

Where the investable surface is widening

The commercial object is the capability distribution layer: registries, manifests, evaluation records, permission boundaries, and lifecycle services that let agents find and install software without turning adoption into an unreviewable act.

Capability registries: searchable stores that index function, ownership, permissions, dependencies, language, jurisdiction, and evidence rather than keywords alone.
Manifest and signing services: tools that bind package metadata to a publisher, version, release, and integrity proof while preserving portable export.
Evaluation admission: systems that run critical user journeys, frozen fixtures, security checks, and cost budgets before a package enters a trusted catalogue.
Permission-aware installers: runtimes that compare requested access with institutional policy, isolate execution, and require a new decision when a release changes its boundary.
Revocation and migration rails: services that notify dependants, stop unsafe versions, preserve the decision record, and move an institution to an alternative package without losing operating knowledge.

Underwriting can begin with measurable questions: how quickly can a reviewer understand a package before installation; what proportion of capabilities have named owners and explicit permissions; how often do package updates invalidate prior evaluation; can an institution export its catalogue and decision history; how many failed installations are contained before they reach sensitive systems; and can a local publisher make its capability discoverable without surrendering its language or licensing terms?

The strongest companies in this category will not simply host more code. They will reduce the uncertainty between discovery and governed use. Their assets will be trusted metadata, reproducible evaluation, policy integrations, installation telemetry, and a registry that remains useful when a model, framework, or cloud provider changes. The rail earns revenue because it lowers the cost of adoption without hiding the cost of responsibility.

Build one package that can survive handoff

An institution can test the principle with one capability that already crosses teams: a research importer, a translation skill, a data connector, a release assistant, or a publishing workflow. Give it a stable identity. Write the manifest before the installer. State the permitted inputs and outputs, the secrets it may request, the environments it supports, the tests that define success, and the conditions that require refusal.

Then hand the package to a second team using a different runtime. Ask them to discover it, evaluate it, install it in a sandbox, inspect its permissions, run the critical journey, and remove it. Change one dependency and see whether the registry marks the evaluation as stale. Revoke one permission and verify that the package stops at the boundary rather than finding an undocumented route around it.

This is the discipline required for an agentic software economy. Distribution will become faster, but speed without legibility creates dependency on whoever owns the catalogue. A package that explains itself gives an institution a chance to accept, reject, adapt, and carry capability on its own terms. The machine may perform the installation. The institution must still own the decision.

Sources

Le paquet doit s’expliquer lui-même

Un agent capable d’installer une capacité a franchi un seuil qu’un installateur logiciel classique n’avait jamais eu à affronter. La machine ne télécharge pas seulement du code. Elle décide si un ensemble est pertinent, de quelle autorité il a besoin, quelles dépendances il peut toucher, comment il doit être évalué et si son propriétaire formule une affirmation que l’institution peut accepter. Un paquet incapable de répondre à ces questions reste opaque au moment même où il devient opérationnel.

Cela transforme l’unité de distribution. L’objet utile n’est pas un dépôt auquel on ajoute un README pour les humains après l’implémentation. C’est un paquet de capacité dont l’identité, la fonction, les entrées, les permissions, les dépendances, les tests, la propriété et la voie de retrait sont lisibles avant l’installation. Le paquet doit s’expliquer lui-même parce que le prochain opérateur peut être un agent agissant au nom d’une personne qui ne consultera jamais l’arborescence du code source.

Quand un logiciel peut recruter lui-même son opérateur, les métadonnées deviennent une partie du plan de contrôle.

Le manifeste précède la confiance

La description publiée le 15 octobre par Google au sujet de google/adk-recipes rend ce déplacement particulièrement concret. Le dépôt est organisé en modèles de référence, plugins verticaux installables et services déployables. Chaque recette contient un manifeste validé, un fichier AGENTS.md qui indique à un assistant de programmation comment l’utiliser et, pour les couches déployables, une définition de conteneur ainsi qu’un test d’exécution. Le dépôt est conçu pour être découvert et consommé par des agents aussi bien que par des développeurs.

Cette structure constitue une décision de produit. Un manifeste n’est pas une documentation décorative ; c’est une surface d’admission. Il indique à une machine ce qu’une capacité prétend faire, ce qu’elle possède, sous quelle licence elle est distribuée, quel environnement elle attend et quels contrôles soutiennent cette affirmation. L’assistant peut alors comparer un paquet candidat avec une tâche, une politique, un budget et une frontière de sécurité avant d’écrire des fichiers ou d’appeler un outil.

Un paquet de capacité devrait exposer au minimum :

Identité : nom stable, version, éditeur, registre de propriété et relation avec les versions antérieures.
Fonction : tâche accomplie, entrées acceptées, sorties produites et cas de refus.
Autorité : fichiers, réseaux, secrets, comptes, catégories de données et services externes auxquels il peut accéder.
Dépendances : modèles, runtimes, bibliothèques, outils, registres et validations humaines nécessaires à une exécution valide.
Preuves : tests, bancs d’évaluation, environnements pris en charge, limites connues et date de vérification des affirmations.
Correction : procédures de mise à jour, révocation, restauration, suppression et notification lorsqu’une modification touche le paquet ou une dépendance.

Ces champs transforment la découverte en décision raisonnée. Ils donnent aussi à l’institution le moyen de refuser un paquet sans faire de ce refus un échec d’intelligence. Un agent peut écarter une capacité utile parce que sa licence est incertaine, que la permission demandée est trop large, que son évaluation est périmée ou que sa voie de correction n’existe pas. Un refus borné est une fonction opératoire.

La distribution est un événement de gouvernance

La distribution logicielle a toujours transporté de l’autorité, mais cette autorité était souvent médiatisée par une personne. Un développeur lisait la documentation, inspectait l’arbre des dépendances, lançait un test et décidait d’intégrer le composant. La distribution agentique comprime ces étapes dans un runtime qui doit agir rapidement tout en préservant le droit de l’institution à comprendre et à inverser la décision.

L’AI Agent Standards Initiative du NIST place les protocoles ouverts, l’authentification et l’infrastructure d’identité ainsi que les évaluations de sécurité dans un même cadre stratégique. L’initiative décrit un travail sur des agents qui opèrent de manière sûre pour le compte des utilisateurs et interopèrent entre systèmes. Son importance pour les paquets de capacités est directe : l’identité indique à l’institution qui formule l’affirmation, l’évaluation indique ce qui a été vérifié et les protocoles ouverts déterminent si le paquet peut être déplacé ou examiné hors de l’environnement d’un seul fournisseur.

Le guide publié le même jour par Google sur l’évaluation des agents fournit la discipline opératoire. Il recommande de commencer par des parcours utilisateurs critiques, de conserver un jeu de données de référence figé pendant la modification d’une seule variable, de combiner revue humaine et contrôles automatisés, et de mesurer latence, consommation de tokens, coût et nombre d’appels d’outils à côté de la qualité de la réponse. Il défend aussi des conventions de traces qui rendent l’évaluation indépendante d’un framework d’orchestration particulier.

Le paquet a donc besoin d’un dossier de sortie, pas seulement d’un numéro de version. Ce dossier devrait indiquer les parcours réussis, l’environnement qui a produit le résultat, les contrôles booléens et reproductibles, les limites encore ouvertes et les changements qui exigent une nouvelle évaluation. Un paquet qui modifie silencieusement ses outils ou ses permissions tout en conservant sa version n’a pas maintenu la compatibilité ; il a modifié le risque de l’institution.

La question africaine est celle du propriétaire du catalogue

La distribution prête pour les agents produira de nouveaux catalogues de compétences, plugins, recettes, jeux de données, connecteurs et services déployables. Le catalogue influencera les capacités visibles, fiables, abordables et faciles à installer. Il devient donc une institution politique et économique, et non une simple étagère neutre.

Les laboratoires, éditeurs, universités, coopératives et administrations africains doivent pouvoir publier des capacités dans leurs propres langues, décrire des catégories de données locales, fixer des limites juridictionnelles et conserver l’autorité de retirer ou de réviser un paquet. Un registre qui n’accepte que les catégories d’une plateforme extérieure peut rendre un savoir local disponible tout en rendant les institutions locales invisibles. L’interopérabilité doit élargir le vocabulaire de la participation, et non le réduire à ce qu’un marché étranger peut indexer.

C’est ici que la méthode historique devient une discipline d’ingénierie. Une source n’est pas solide parce qu’elle est présente dans une archive ; elle l’est lorsque son origine, son contexte, ses limites et sa chaîne de transmission peuvent être examinés. Un paquet de capacités mérite le même traitement. Son manifeste doit permettre à une autre institution de demander d’où il vient, ce qu’il suppose, ce qu’il peut affecter et comment contester ses affirmations.

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

L’objet commercial est la couche de distribution des capacités : registres, manifestes, dossiers d’évaluation, frontières de permission et services de cycle de vie qui permettent aux agents de trouver et d’installer des logiciels sans transformer l’adoption en acte impossible à examiner.

Registres de capacités : magasins consultables qui indexent fonction, propriété, permissions, dépendances, langue, juridiction et preuves, plutôt que de simples mots-clés.
Services de manifeste et de signature : outils qui lient les métadonnées du paquet à un éditeur, une version, une publication et une preuve d’intégrité tout en conservant un export portable.
Admission par évaluation : systèmes qui exécutent parcours utilisateurs critiques, fixtures figées, contrôles de sécurité et budgets de coût avant l’entrée d’un paquet dans un catalogue de confiance.
Installateurs sensibles aux permissions : runtimes qui confrontent l’accès demandé à la politique institutionnelle, isolent l’exécution et exigent une nouvelle décision lorsqu’une version modifie sa frontière.
Rails de révocation et de migration : services qui préviennent les dépendants, arrêtent les versions dangereuses, conservent le dossier de décision et déplacent une institution vers un paquet de remplacement sans perdre le savoir opératoire.

La souscription peut commencer par des questions mesurables : combien de temps faut-il à un examinateur pour comprendre un paquet avant l’installation ; quelle proportion des capacités possède un responsable nommé et des permissions explicites ; à quelle fréquence les mises à jour invalident-elles l’évaluation antérieure ; une institution peut-elle exporter son catalogue et son historique de décisions ; combien d’installations échouées sont contenues avant d’atteindre des systèmes sensibles ; et un éditeur local peut-il rendre sa capacité découvrable sans abandonner sa langue ou ses conditions de licence ?

Les entreprises les plus solides de cette catégorie n’hébergeront pas simplement davantage de code. Elles réduiront l’incertitude entre la découverte et l’usage gouverné. Leurs actifs seront des métadonnées fiables, une évaluation reproductible, des intégrations de politiques, une télémétrie d’installation et un registre qui reste utile lorsqu’un modèle, un framework ou un fournisseur cloud change. Le rail mérite un revenu parce qu’il réduit le coût de l’adoption sans dissimuler le coût de la responsabilité.

Construire un paquet qui survive au transfert

Une institution peut tester ce principe avec une capacité qui traverse déjà plusieurs équipes : importateur de recherche, compétence de traduction, connecteur de données, assistant de publication ou workflow de sortie. Donnez-lui une identité stable. Écrivez le manifeste avant l’installateur. Énoncez les entrées et sorties autorisées, les secrets qu’il peut demander, les environnements pris en charge, les tests qui définissent le succès et les conditions qui imposent un refus.

Confiez ensuite le paquet à une seconde équipe utilisant un autre runtime. Demandez-lui de le découvrir, de l’évaluer, de l’installer dans un bac à sable, d’inspecter ses permissions, d’exécuter le parcours critique et de le retirer. Modifiez une dépendance et vérifiez que le registre marque l’évaluation comme périmée. Révoquez une permission et confirmez que le paquet s’arrête à la frontière au lieu de chercher une voie non documentée pour la contourner.

Cette discipline est nécessaire à une économie logicielle agentique. La distribution deviendra plus rapide, mais la vitesse sans lisibilité crée une dépendance envers le propriétaire du catalogue. Un paquet qui s’explique lui-même donne à l’institution une chance d’accepter, de refuser, d’adapter et de porter une capacité selon ses propres conditions. La machine peut effectuer l’installation. L’institution doit encore posséder la décision.