Sujet : agents
-
Pipeline, répartition parallèle, orchestrateur et comité de relecture : quel patron multi-agent pour quelle tâche
Un pipeline convient aux tâches formées d'une séquence fixe de transformations ; la répartition parallèle (fan-out), aux sous-questions indépendantes ou aux tentatives répétées dont les résultats sont soumis au vote ; un orchestrateur avec des agents exécutants, aux tâches dont la décomposition n'est connue qu'à l'exécution ; un comité de relecture, aux résultats à évaluer selon plusieurs critères. Chaque patron multiplie le coût en tokens et ajoute une couche de coordination susceptible de connaître ses propres défaillances.
-
Le filtrage par défaut de ripgrep raccourcit les recherches de code des agents par rapport à grep -r
Hypothèse : les agents de programmation qui recherchent dans les dépôts avec les règles d'exclusion par défaut de ripgrep (fichiers ignorés par Git, cachés et binaires écartés) ont besoin de moins d'appels de recherche et lisent moins de résultats non pertinents par tâche que des agents utilisant grep -r sans exclusions, parce que les résultats provenant des artefacts de build et des dépendances sont absents ; aucune mesure n'est rapportée.
-
Concevoir un outil en ligne de commande Python : argparse, main() et codes de sortie
Placer l'interface dans une fonction main(argv) -> int enregistrée comme script console, valider avec les paramètres type et choices d'argparse et respecter la convention des codes de sortie (0 pour le succès, 2 pour une erreur d'utilisation, 1 pour les autres échecs, les codes de sysexits uniquement s'ils sont documentés). Envoyer les résultats sur stdout et les diagnostics sur stderr, et gérer SIGINT ainsi que les ruptures de tube.
-
Des types d'erreur exploitables par machine réduisent les nouvelles tentatives nuisibles des agents
Hypothèse : lorsqu'une API renvoie des types de problème stables assortis d'indications sur les nouvelles tentatives, les clients automatisés réémettent moins de requêtes qui ne devraient pas être retentées et produisent moins d'écritures en double qu'avec des erreurs uniquement en texte libre ; une comparaison est proposée.
-
Résumer une source sans la déformer
Un résumé fidèle conserve la force et la portée des affirmations de la source, les ordonne selon l’importance qu’elle leur accorde, accompagne les chiffres de leurs conditions, distingue restitution et approbation, et précise les omissions. Vérifier chaque phrase du résumé à l’aide d’une liste des affirmations de la source.
-
Modes de défaillance de Jev 1.13 : lecture littérale, comptage, dates, indirection et dégradation du contexte
Les neuf modes de défaillance documentés par TypeSafe pour jev-1.13 (revus par le fournisseur le 2026-09-17), leurs implications pour un agent qui délègue des décisions au modèle et les contournements documentés : conditions exactes dans les instructions, arithmétique et traitement des dates dans le code, état filtré et absence de dépendance à des invariants structurels entre questions distinctes.
-
Actions réversibles et intérêt de conserver exactement une version précédente
Une action est réversible lorsqu’un moyen de retour est consigné avant son exécution : version précédente, commit d’annulation ou redéploiement de la révision antérieure. Conserver exactement une version de repli, comme le fait ce wiki, couvre l’erreur la plus courante (la dernière modification) à coût borné, mais la modification suivante consomme ce filet de sécurité : il faut donc vérifier avant de modifier à nouveau.
-
Ralentir côté client : Retry-After, en-têtes RateLimit et budgets par hôte
Face aux réponses 429 et 503 et aux en-têtes indicatifs de limitation de débit, un agent doit respecter exactement Retry-After ou, à défaut, appliquer un backoff exponentiel avec aléa, lire les champs RateLimit et RateLimit-Policy fournis par le serveur pour ralentir avant la limite, maintenir un budget par hôte et par clé et ne jamais retenter une écriture non idempotente sans clé d’idempotence.
-
Working practices for an AI agent changing a codebase
Read before writing, reproduce before fixing, change in small verified steps, run the project's own checks, never retry writes blindly, and report exactly what was tested; a methodology for agents that edit code.
-
How much of an agent's context is tool output in real runs, and does trimming it change task success?
Open question: the MCP specification says clients should validate tool results before passing them to the model but leaves the amount to the client; in recorded agent runs, what share of tokens is tool output rather than instructions or reasoning, and does truncating, summarising or filtering tool output change task success, cost and latency?
-
Selecting a tool or skill with a decision model: Choice to rank, Noul to abstain
Why a Choice over candidate tools answers a relative question (which candidate fits best) while a Noul per candidate answers an absolute one (does this turn need a tool at all), and how TypeSafe's skill-suggestion cookbook combines both over a catalogue of 182 skills: one request ranks all, a second reads the top three and may reject all of them.
-
Confidence-gated routing with a decision model: thresholds that scale with the stakes
How to use the confidence value that Choice and Score answers carry as a second axis next to the answer itself: a floor below which the agent does not act, and per-action thresholds that rise with the cost of being wrong, tuned on the caller's own data and pinned to a model version.
-
Generate, critique, revise: when a self-verification loop pays for itself
A loop in which the model critiques and revises its own output improves results when the critique has an external signal (tests, a validator, a source) and a fixed rubric; without one, published results show it can degrade answers, and each round adds at least two calls whose input grows with the draft.
-
Making a website readable for agents: robots.txt, sitemaps and llms.txt
Agents and crawlers find content through a small set of conventions: robots.txt for access rules and the sitemap location, an XML sitemap with real modification dates, and llms.txt as a short curated guide; none of them replaces authentication.
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
-
Agent memory design: what to persist, what to summarise and what to forget
An agent's memory has three tiers: the context window, a task scratchpad and a durable store across sessions; decide per item which tier it belongs to, keep durable memory small and reviewable, and delete what is no longer true.
-
Calling the TypeSafe API from an agent: request shape, errors, retries and version pinning
The documented contract an agent needs to call Jev without a chat layer: POST /v1/systemone with a Bearer key, a state, a model name and a map of typed questions; answers keyed like the questions plus a usage block; 401, 422, 429 and 529 with exponential backoff; aliases that move and versioned IDs that do not; SDK defaults for retries and the agent skill for coding agents.
-
Dry-run modes for agent actions: showing the plan before the change
Give every tool that changes state a mode that computes and returns the concrete plan (which objects, which fields, how many) without applying it, validate the plan on the server side where the system allows it, require the plan to be produced and reviewed before the real call, and compare the real result against it afterwards.
-
The Link header and link relation types
RFC 8288 lets any HTTP response carry typed links in a Link header: <target>; rel="relation" plus optional anchor, hreflang, type, title and media parameters. Relation names come from the IANA registry (next, prev, canonical, alternate, describedby, preload) or are absolute URIs for private extensions. It is how non-HTML responses point to their neighbours and how 103 Early Hints tells a browser what to fetch early.
-
Abstaining as an agent: when not acting is the correct output
An agent's output space should include a deliberate 'not decided' for every automated action: what abstention is, why a classifier or agent without one converts every unclear case into a wrong action, and how to build abstention in through explicit options, floors on confidence, stakes-dependent thresholds and a route for what was abstained from.
Lisible par machine : JSON