Un utilisateur colle l'invite d'évaluation dirigée par l'agent dans son éditeur. L'agent lit la [page d'évaluation de Neotoma](https://neotoma.io/evaluate), analyse le flux de travail local, décide que l'adéquation est forte, exécute l'installation et stocke les premières entités. Quelque temps plus tard, il rencontre un véritable bug : la soumission d'une entité supprime silencieusement un champ que le schéma accepte clairement. Un peu plus tard, il remarque autre chose : la récupération sur un graphe d'entités de grande taille est plus lente qu'elle ne devrait l'être pour le flux de travail qu'il prend en charge. Et plus tard encore, lors de la création d'une boucle de récupération personnalisée, il se rend compte qu'il manque à la surface MCP une opération par lots qui rendrait le modèle qu'elle continue de répéter beaucoup plus propre. L’utilisateur n’a jamais posé de questions à ce sujet. L'agent l'a remarqué alors qu'il était en train de faire autre chose.

L’ancienne forme de ces moments était la fin de la boucle. L'utilisateur peut ouvrir GitHub, coller l'erreur ou la requête, rédiger un paragraphe de contexte et attendre. La plupart ne le font pas. Ils contournent le problème, le responsable ne le voit jamais et l'utilisateur suivant se heurte au même mur.

Neotoma dispose désormais d'un sous-système de problèmes de première classe qui fonctionne via la même surface MCP que chaque agent utilise déjà pour stocker et récupérer. L'agent enregistre les bogues, les observations de performances et les demandes d'amélioration sans quitter la session et sans s'arrêter pour poser des questions par problème. Les agents du responsable les récupèrent, les trient, les résolvent souvent et les expédient. L'agent du journaliste relit le statut et informe l'utilisateur lorsque quelque chose atterrit. L'ensemble de l'échange se déroule via des appels d'outils.

L'évaluation dirigée par l'agent décrite dans [l'article de recherche client](/posts/customer-research-through-agents) était la première moitié de cette boucle. Le sous-système des problèmes est la moitié arrière. Les deux moitiés fonctionnent sur le [substrat du système nerveux](/posts/from-memory-to-nervous-system) que j'ai décrit plus tôt, et la capacité des problèmes est l'exemple le plus clair à ce jour de l'utilité de ce substrat.

## Pourquoi la boucle doit se fermer du côté de l'agent

La friction est le tueur silencieux du feedback. L'ancien modèle supposait que l'utilisateur traduirait son expérience dans un rapport sur un système distinct : changer de contexte, trouver le dépôt, analyser un modèle de problème, écrire suffisamment d'informations pour qu'un responsable puisse agir, joindre des journaux, attendre. Chaque pas est une chance d'abandonner. La plupart le font. Et ce modèle ne couvre que les problèmes remarqués par l’utilisateur. Il n'existe aucun moyen de résoudre les problèmes que l'agent a remarqués et que l'utilisateur n'a jamais signalés.

L'agent d'un évaluateur a identifié que l'activation produisait une erreur d'hydratation lorsque la configuration de son substrat pointait vers une instance auto-hébergée derrière un tunnel Cloudflare. L'agent a rédigé un résumé précis, comprenant le point de terminaison défaillant et les en-têtes de réponse. L'utilisateur m'a transmis le résumé sous forme de message. J'ai reconstruit le contexte, je l'ai acheminé vers mes agents, j'ai expédié une version et j'ai répondu à l'utilisateur. L'utilisateur a demandé à son agent de vérifier. Cette vérification a duré environ quatre-vingt-dix secondes. Les étapes du relais humain ont duré des jours.

Le résumé original de l'agent était bon. C’est le contexte de la reconstruction qui a rongé le temps. Chaque transfert entre un agent et un humain perd en fidélité. Chaque transfert entre un humain et un autre agent reconstruit le contexte à partir de zéro. Les détails riches créés par l'agent sont compressés en une prose laconique écrite par l'homme, puis un agent en aval doit les développer.

Lorsque l'agent de l'utilisateur est celui qui s'est heurté au mur — ou a remarqué la lenteur ou souhaitait la fonctionnalité manquante — l'étape de traduction est gratuite. L'agent a déjà le contexte : l'outil dans lequel il s'exécutait, l'appel MCP exact qui a échoué ou qui a semblé gênant, la charge utile de la réponse, la version git SHA ou de l'application de l'installation de Neotoma, le type d'entité impliqué. Il compose un rapport cohérent en un seul appel à l'outil. Les instructions MCP indiquent aux agents de déposer via «submit_issue» immédiatement lorsqu'un problème à signaler ou une opportunité d'amélioration est confirmé, sans s'arrêter pour demander par problème - l'invite par problème n'ajoute aucune nouvelle information et interrompt ce que faisait l'utilisateur. L'agent dépose. L’utilisateur le découvre plus tard, ou jamais, selon que le changement est livré ou non.

Du côté du responsable, la boucle doit se fermer sans que je lise chaque rapport à la main. Je gère une douzaine d'agents parmi des éditeurs et des démons. Ils traitent déjà l’état structuré entrant. La forme naturelle est la suivante : un nouveau problème arrive, le substrat signale l'écriture, un démon de triage récupère l'événement, lit le problème, décide s'il peut agir, ouvre un arbre de travail, exécute une session d'agent sur la base de code et résout le bogue ou demande des éclaircissements au journaliste via le même fil.

Les deux moitiés de la boucle fonctionnent comme un travail agent sur le même substrat. L'agent de l'utilisateur utilise MCP pour soumettre. Les agents du responsable utilisent MCP pour lire et répondre. Personne n'est obligé d'ouvrir un navigateur.

## Ce que fait l'agent lors de la soumission

La surface MCP est suffisamment petite pour être énumérée. L'outil `submit_issue` prend un titre, un corps, un type d'entité si le problème concerne un type d'enregistrement spécifique et un bloc d'environnement de rapporteur - le git SHA que l'utilisateur exécute ou la version de l'application, cette dernière étant automatiquement renseignée côté serveur lorsque l'agent omet les deux. L’environnement du journaliste a plus de poids qu’il n’y paraît ; la section suivante explique pourquoi.

Les rapports arrivent rarement sans contexte. Un bug fait référence à des entités concrètes : l'enregistrement spécifique qui n'a pas pu être stocké, son schéma, une observation en amont. Une demande d'amélioration fait référence au modèle d'appel qu'elle simplifierait ou au type d'entité dont la récupération serait plus rapide. `submit_issue` et `add_issue_message` acceptent un tableau `entity_ids_to_link`, et le serveur crée des relations `REFERS_TO` à partir du nouveau problème vers chaque entité référencée de manière atomique dans le cadre du même appel. Le problème est déjà intégré au graphique dont il s’agit. L'agent de tri qui lit le problème peut accéder directement à l'entité qui a échoué.

La soumission passe par la même protection PII « scanAndRedact » qui protège chaque surface publique. Si l'agent colle accidentellement un jeton ou une adresse e-mail dans le corps, celui-ci est expurgé avant la persistance. Les instructions MCP exigent que les agents appliquent la liste de contrôle PII au titre et au corps avant l'appel, mais la garde côté serveur constitue la véritable ligne de défense. Le journaliste obtient un identifiant numérique de problème et un jeton de relecture d'invité avec une durée de vie explicite, limitée au fil de discussion qu'il vient d'ouvrir. Ce jeton permet à l'agent du journaliste de lire le statut plus tard sans se réauthentifier à chaque fois.

Du point de vue de l'utilisateur : un seul appel d'outil, un identifiant à suivre et généralement aucune invite d'approbation. Du point de vue du substrat : une entité structurée a été écrite, les relations d'entité liée ont été créées dans la même transaction, une ligne source a été créée, une subvention d'invité a été émise et le pipeline d'écriture a émis un événement.

## Provenance est le héros méconnu

L'exigence d'environnement du journaliste ressemble à un petit détail. C'est le changement le plus important.

Avant que le sous-système de problèmes n'existe, un rapport pouvait être soumis sans référence à la version pour laquelle il avait été rédigé. C'est bien pour un ticket papier. C'est catastrophique pour une boucle de tri automatisé. Si un agent soumet un bogue lors de la validation « abc1234 » et que mes agents le corrigent lors de la validation « def5678 », l'agent de l'utilisateur doit savoir sur quelle version vérifier. Si un thread de débogage s'étend sur trois builds, chaque commentaire doit enregistrer dans quelle build il a été testé. La même chose s'applique à une demande d'amélioration : savoir quelle version l'agent exécutait lorsqu'il a identifié l'opération par lots manquante m'indique si l'écart a déjà été comblé dans une build ultérieure ou est véritablement ouvert. Sans provenance, le fil devient archéologie.

`submit_issue` rejette toute soumission qui manque à la fois de `reporter_git_sha` et `reporter_app_version`. L’enveloppe de rejet répertorie explicitement les alternatives :

```json
{
  "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED",
  "détails": {
    "groupes_de_champs_acceptables": [
      ["reporter_git_sha"],
      ["reporter_app_version"]
    ]
  }
}
```

`add_issue_message` accepte les mêmes champs et émet un avertissement du serveur sur les threads publics lorsque les deux sont manquants. Chaque message rédigé par un agent de débogage enregistre la build en cours de test.

La raison pour laquelle cela est important pour la gestion d'agent à agent est que cela permet au côté destinataire de classer le rapport avant d'effectuer tout travail. Pour un bug : l'utilisateur a-t-il exécuté une version publiée ? Branchez-vous à partir de « principal » et ouvrez un PR. Un commit spécifique sur une branche de fonctionnalité ? Créez un arbre de travail au niveau de cette validation, reproduisez et signalez les résultats sans modifier la ligne principale. Leur propre fourchette ? Publiez un suivi structuré demandant la source du correctif. Pour une amélioration : la fonctionnalité demandée est-elle déjà sur une branche, ou est-elle réellement manquante ? Est-ce que cela entre en conflit avec une contrainte de conception que l'agent ne peut pas voir ? La classification détermine la réponse – et rien de tout cela n’est possible sans provenance.

La provenance est ce qui transforme un rapport de forme libre en un événement routable, qu'il décrit quelque chose de cassé ou de manquant.

## Que se passe-t-il du côté du responsable

Mon démon de triage s'abonne aux événements de création de problèmes via les mêmes outils d'abonnement que tout autre consommateur utiliserait. Les webhooks viennent en premier car ils fonctionnent pour les démons distants sur un VPS ainsi que pour les processus locaux sur mon ordinateur portable ; L’ESS est additif. Le substrat maintient le registre, délivre l'événement et oublie. Le démon décide.

Le démon que j'utilise pour cela s'appelle Formica. Genre _Formica_, fourmis. Chaque sous-agent est un travailleur qui effectue une tâche depuis le journal des événements jusqu'à un correctif.

Ce qu'il fait, en pratique : lire le numéro. Extrayez les entités liées par l'agent du journaliste au moment de la soumission, puisque les relations sont déjà dans le graphique. Miroir du dépôt GitHub en amont s'il justifie une trace publique, avec une rédaction des informations personnelles appliquée à la limite de l'API et tout problème dont le titre ou le corps correspond toujours à un modèle de rédaction rejeté avant de franchir la ligne. Classifiez si le rapport est un bug ou une amélioration. Pour les bogues : décidez s'ils sont reproductibles à partir du seul environnement de rapporteur, puis confiez-les à une compétence « / process-issues » qui ouvre une arborescence de travail, exécute une session d'agent et tente une correction. Pour les améliorations : synthétisez une entité de plan qui regroupe la demande avec tous les problèmes ouverts associés, et présentez-la pour un examen humain plutôt que de tenter une mise en œuvre autonome. Si plus de contexte est nécessaire pour l'un ou l'autre type, postez une question de clarification via `add_issue_message` afin que l'agent du journaliste la reçoive lors de la prochaine lecture du statut.

La compétence `/process-issues` pilote le correctif réel. Le contrat est court. Pour chaque problème ouvert :

- Chargez l'instantané, le fil de conversation et l'environnement du journaliste.
- Classez l'environnement de reproduction comme `public_release`, `local_commit`, `local_branch` ou `unknown`.
- En cas d'inconnu ou de conflit, appelez `add_issue_message` avec une demande structurée pour les détails manquants et marquez le plan `awaiting_input`.
- Sinon, synthétisez une entité « plan » liée au problème source et aux lignes de messages de conversation pertinentes.
- Si le plan touche au schéma, à la sécurité, aux documents de fondation ou à une limite architecturale ambiguë, arrêtez-vous et demandez. N'exécutez pas.
- Si l'exécution est sûre et autorisée par le mode de rapport : branchez depuis « main » pour une reproduction en version publique et ouvrez un PR, ou créez un arbre de travail git détaché pour une reproduction locale et signalez le chemin.

Les sous-agents se déploient avec un plafond de simultanéité de quatre, un problème par sous-agent. La compétence honore le `reporting_mode` : `off` génère et stocke uniquement les plans, `consent` demande avant l'exécution, `proactive` exécute les plans sécurisés de manière autonome. Ne poussez jamais vers « principal ». N'utilisez jamais `--no-verify`. Ne modifiez jamais un commit poussé. La protection contre les fuites de rédaction s'exécute avant qu'un artefact public ne soit créé à partir d'un problème privé.

Les valeurs par défaut sécurisées restent activées :

- `dry_run : true` pour la première exécution de tout nouveau type de problème afin que je voie ce qui se passerait avant que quoi que ce soit ne soit écrit.
- `auto_fix : false` donc rien ne pousse ou n'ouvre un PR jusqu'à ce que je confirme via l'opérateur de transport.
- `max_prs_per_hour : 5` afin qu'un flot de problèmes liés ne puisse pas se transformer en un flot de branches.
- `dirty_tree_policy: abort` pour qu'une caisse périmée ne soit jamais utilisée comme base.
- Un kill switch via une entité `daemon_config` dans Neotoma avec `active: false`, afin que je puisse suspendre tous les traitements à partir d'une seule écriture de Neotoma sans toucher la machine hôte.

La pièce de transport de l'opérateur mérite une note. Formica prend en charge un backend Telegram qui affiche les transferts « human_needed » et les commandes « /shipit » pour reprendre lorsque « auto_fix » est désactivé. Allowlisted Telegram messages are mirrored to Neotoma as `conversation_message` rows, so even my human-side back-and-forth with the daemon is captured in the same substrate. La piste d'audit s'étend de bout en bout.

Le chemin `add_issue_message` est celui qui m'a surpris lorsque j'ai commencé à l'utiliser. Ce n'est pas un système de commentaires. It is a structured message channel between an issue's reporter and the maintainer side, threaded through the same conversation primitives that already exist for agent-to-agent threads. L'agent du journaliste peut répondre à une question de clarification sans que l'humain n'ait besoin de la lire entre les deux. Public threads carry the same PII redaction, and partial-success cases (GitHub mirror accepted, local append failed, or vice versa) surface as a structured error on the response rather than silently producing duplicate comments.

Lorsqu'un correctif arrive, le même démon qui a trié le rapport ferme le problème, ou en ferme plusieurs à la fois si un seul PR a résolu un cluster.

## Ce que fait l'agent du journaliste lors de la relecture

L'autre côté de la boucle est la lecture. L'agent du journaliste appelle « get_issue_status » avec le numéro de problème ou l'ID d'entité. It receives the current status, the messages on the thread, the resolution if any, and the link to the upstream mirror if the maintainer side chose to escalate it. Le jeton invité authentifie la lecture sans que l'utilisateur ait à se connecter à quoi que ce soit. Si le jeton a expiré, le substrat renvoie un 401 propre au lieu de rétrograder silencieusement vers un accès anonyme.

L'agent décide s'il doit présenter le statut à l'utilisateur. Si rien n’a changé depuis le dernier contrôle, il reste silencieux. Si une question de clarification arrive, elle est posée à l'utilisateur. Si le correctif est livré, il en informe l'utilisateur, extrait éventuellement la nouvelle version et propose de réexécuter ce qui s'est cassé la première fois.

The current read model for the reporter side is pull — the agent checks when it has reason to — but push is available today through the same subscription tools the maintainer's daemon uses. Subscriptions can be scoped to a specific entity ID, so a reporter's agent can register interest in the issue it just filed and receive `entity.updated` and `observation.created` events as the thread progresses. Ce qui manque, c'est la colle ergonomique : les instructions MCP ne disent pas encore aux agents de s'abonner automatiquement après le retour de `submit_issue`. Jusqu’à ce qu’ils le fassent, le côté des journalistes reste par défaut ; les agents du responsable se réveillent déjà sur les événements du substrat. Entièrement réactif sur les deux moitiés, il suffit d'un changement d'instruction.

## Pourquoi c'est le système nerveux en action

Le substrat émet des événements après chaque écriture. C’est la seule chose que le substrat doit faire pour que tout cela fonctionne. Everything else is operational-layer logic running on top: the triage daemon, the GitHub mirror, the guest read-back, the cross-thread dedup, the PII redaction.

C'est la ligne que j'ai [préconisée dans l'article sur le système nerveux](/posts/from-memory-to-nervous-system) et elle tient le coup dans le cas d'utilisation des problèmes. Le substrat ne décide pas quels problèmes sont importants, ne réessaye pas les livraisons avec escalade, ne souscrit pas à ses propres événements. Cela signale. Le démon de triage est un consommateur, l'agent du journaliste est un consommateur, le miroir GitHub est un consommateur. Chaque consommateur manifeste son intérêt, décide quoi faire et agit. Si je souhaite ajouter un deuxième démon de triage qui gère les rapports de sécurité différemment, il s'abonne aux mêmes événements avec un filtre différent. Aucun nouveau comportement du substrat.

Le cadrage biologique tient. Le substrat est le cerveau et les nerfs sensoriels : il stocke le problème, il transmet le signal de l'arrivée d'un problème. Le démon de triage et l'agent du journaliste constituent le système moteur : ils décident quoi faire du signal. Une version de Neotoma qui tenterait d’être les trois serait plus difficile à raisonner et à étendre. Une version qui s'arrête à la signalisation reste neutre.

## Hériter de la boucle

La forme que j'ai décrite est construite autour des propres problèmes de Neotoma, mais le substrat s'en fiche. Tout ce qui est construit dessus hérite de la plupart des mêmes machines.

Le côté générique de la soumission est déjà en place. `submit_entity` accepte les rapports sur des types d'entités arbitraires lorsque l'opérateur a généré une ligne `submission_config` l'autorisant. La même attribution de jeton d'invité, le même fil de conversation, le même canal de suivi `add_entity_message` s'appliquent. `subscribe` accepte n'importe quel type d'entité comme filtre, de sorte qu'un opérateur tiers peut exécuter son propre démon de triage en enregistrant son intérêt pour ses types personnalisés et en réagissant aux événements `entity.created` et `entity.updated` exactement de la même manière que Formica réagit aux problèmes.

Ce que cela signifie en pratique : si vous exécutez un pipeline de contenu, un service de rapprochement ou tout autre produit dont les utilisateurs exécutent des agents, vous pouvez laisser ces agents déposer des rapports structurés sur les entités que vous possédez (un échec d'exécution du pipeline, un enregistrement mal classé, une demande de rapprochement) et les récupérer de votre côté via le même mécanisme d'abonnement. Le fil est général.

Quelques pièces restent aujourd'hui spécifiques aux problèmes de Neotoma. Le garde de rédaction des PII est actuellement lié au chemin `submit_issue`, et non au chemin générique `submit_entity`. La mise en miroir de GitHub est spécifique aux problèmes. Les deux sont des ajouts à la couche opérationnelle qu’un opérateur tiers câblerait lui-même. Le substrat gère les éléments qui doivent être uniformes : application de la provenance, création de relations atomiques, accès invité limité au thread, émission d'événements à chaque écriture. Les parties qui dépendent de l'objet du rapport *sur* sont celles où l'opérateur gagne sa vie.

Le sous-système des problèmes est le premier consommateur complet d’un modèle plus général. La même forme s'applique à tout signal structuré qu'un agent pourrait vouloir renvoyer au système sur lequel il s'exécute.

## Pourquoi l'avis humain reste

Deux choses me tentent de câbler « auto_fix : true » et d'expédier tout ce que le démon produit.

Le premier est la commodité. Un pipeline vert qui résout les problèmes pendant que je dors est satisfaisant. La seconde est le fait que pour une fraction significative des problèmes, le plan agent et la différence sont corrects. J'en ai regardé suffisamment maintenant pour savoir que le mode d'échec n'est généralement pas une « mauvaise solution ». Il s'agit généralement d'un « correctif pour une mauvaise portée », qu'une révision de code détecte en trente secondes.

Je laisse de côté l'examen humain parce que les agents se trompent parfois avec confiance sur des décisions ayant des conséquences en aval qu'ils ne peuvent pas voir. Une migration de schéma qui satisfait au test d'échec mais interrompt une intégration sans rapport. Un ajustement de rédaction qui corrige la fuite immédiate mais desserre une garde associée. Une amélioration de dépendance qui résout l'erreur de construction et modifie silencieusement le comportement par défaut d'une requête.

Les demandes d’amélioration accentuent encore davantage ce phénomène. Un bug a une vérité fondamentale : soit le champ est supprimé, soit il ne l'est pas. Une amélioration est une revendication de conception qui comporte des hypothèses sur les modèles d'utilisation, les contraintes architecturales et les compromis que l'agent déclarant ne peut pas pleinement voir. Le signal est précieux ; il fait apparaître une friction réelle, et non une friction imaginée. Mais la décision quant à ce qu’il faut en faire appartient à un humain qui peut voir la situation dans son ensemble.

Les décisions qui nécessitent un humain sont celles pour lesquelles le coût d’une erreur est élevé et celui d’une lenteur est faible. Ce sont les fusions – pas les plans, les correctifs, les tests ou les descriptions PR. Les agents s'occupent de tout le reste. Les agents proposent ; les humains décident.

## La boucle agentique, de bout en bout

Lisez à côté du message de recherche client, la forme est désormais lisible. La moitié avant : l'agent de l'utilisateur évalue Neotoma par rapport à son flux de travail réel et l'installe si l'ajustement est là. La moitié arrière : l'agent classe les bogues, les observations de performances et les demandes d'amélioration au fur et à mesure qu'il les rencontre, et le côté responsable les résout - souvent avant que l'utilisateur ne se souvienne que tout cela a été déposé.

Les deux moitiés opèrent sur des agents parlant à des agents via une surface structurée. Les frictions qui ont historiquement tué à la fois la boucle d'acquisition et la boucle de rétroaction ont disparu car chaque étape de traduction a été absorbée dans un appel d'outil. Aucune des deux moitiés ne serait possible sans le substrat sous-jacent : l'évaluation dirigée par l'agent nécessite un état structuré concernant le flux de travail de l'utilisateur, et le sous-système des problèmes nécessite une signalisation des événements ainsi qu'un accès invité au-delà des limites de confiance. Les deux dépendent des mêmes primitives.

## Ce que je ne construis pas

La tentation dans le sous-système des problèmes est de dériver vers l'orchestration : un modèle de priorisation, un suivi automatique des SLA, un routeur « intelligent » qui décide quel démon gère quel type de problème. Chacun semble raisonnable isolément. Aucun d’entre eux n’a sa place dans le substrat. Le démon de triage établit les priorités. Les agents du responsable suivent leurs propres temps de réponse. Le routage est un filtre d'abonnement.

Il en va de même pour la sémantique des nouvelles tentatives. Si la livraison d'un webhook échoue, le substrat enregistre l'échec et continue. Il ne passe pas à un canal de sauvegarde, ne met pas en mémoire tampon la relecture et ne fait pas basculer un consommateur dans un état dégradé. Les courtiers de messages font tout cela et ils sont bons dans ce domaine ; le substrat n'est pas un courtier de messages. Les consommateurs qui souhaitent une livraison garantie intègrent le signal dans leur propre infrastructure.

La contrainte est la fonctionnalité. Une couche d’état qui signale les problèmes mais ne décide pas quels problèmes sont importants est une couche d’état à laquelle tout consommateur peut faire confiance pour se comporter de manière prévisible.

## Sur quoi je souhaite recevoir des commentaires

Le sous-système des problèmes est en ligne. Si Neotoma est installé et que votre agent rencontre un problème (un bug, un écart de performances, une fonctionnalité manquante qu'il souhaiterait exister) vous n'avez plus besoin de lui demander de signaler un problème. Pour récupérer cela sur une installation existante, effectuez une mise à niveau avec `npm install -g neotoma@latest`. Il n'y a pas de bouton de consentement par utilisateur à configurer ; le consentement est l'installation. S'il s'agit d'une nouvelle installation, « neotoma reporter setup » parcourt la configuration unique côté journaliste afin que le premier problème que vos fichiers d'agent ait quelque part où atterrir.

Si Neotoma n'est pas encore installé, demandez à votre agent d'exécuter la page d'évaluation. S'il conclut que Neotoma convient, il peut s'installer et s'activer sans que vous lisiez un document de configuration. S'il conclut que Neotoma ne convient pas, c'est également un résultat valable, et plus honnête que celui produit par la plupart des pages de destination.

Si vous créez un produit dont les utilisateurs exécutent des agents, le modèle est portable. Le travail intéressant ne se situe pas d’un côté ou de l’autre du fil ; c'est le fil lui-même.