Workers et Intelligence Layer

Arc OS utilise un système de workers pour distribuer les tâches entre des agents IA spécialisés, tandis que l'Intelligence Layer garantit la qualité de leurs réponses via quatre modules : Binary Evals, Context Router, Learnings et Karpathy Loop.

Système de workers

Chaque worker est un agent IA indépendant avec un rôle défini, un modèle et un ensemble d'outils. Les workers opèrent dans le cadre d'un projet et sont accessibles via le Workspace UI ou les commandes Telegram (/c, /d, /w:worker_id).

Workers intégrés

Types de workers

• chat — conversation en mode tour par tour avec l'historique de contexte complet. Le worker reçoit tous les échanges précédents et répond comme un interlocuteur.
• terminal — exécution en streaming avec des events d'outils. Le worker fonctionne comme une session terminal, exécutant les outils séquentiellement et diffusant la progression en temps réel.

Créer un worker personnalisé

Les workers personnalisés sont décrits dans le fichier config/workers_registry.json. Chaque entrée définit le comportement de l'agent :

{
  "id": "my-worker",
  "label": "My Worker",
  "icon": "🔧",
  "type": "chat",
  "model": "claude-sonnet-4-5",
  "max_turns": 10,
  "tools": ["Read", "Glob", "Grep"],
  "system_prompt": "You are...",
  "focus_dirs": ["src/"],
  "builtin": false
}

Champs de configuration

Binary Evals — Validation des réponses

C'est quoi ?

Des règles déclaratives pour vérifier la qualité des réponses des workers. Chaque règle est déterministe (sans IA), s'exécute instantanément et ne bloque pas la réponse. Les résultats ont une sévérité warning ou info — ils informent, ils n'arrêtent pas.

6 types de règles

Format du fichier evals

Le fichier est placé à côté de la skill : skills/{skill_name}/{skill_name}.evals.json

{
  "version": 1,
  "skill": "code-review",
  "rules": [
    {
      "id": "cr-001",
      "name": "Must return JSON verdict",
      "type": "string_contains",
      "value": "\"verdict\"",
      "severity": "warning"
    }
  ]
}

Chaque règle possède un id unique, un name lisible par un humain, l'un des 6 types, une value de comparaison et une severity (warning ou info).

Context Router — Sélection automatique des skills

Comment ça fonctionne ?

À chaque message, le Context Router score toutes les skills de skills/_registry.json et sélectionne automatiquement les plus pertinentes :

1. Trigger match (+2 points) — correspondance directe d'un mot déclencheur du message
2. Keyword match (+1 point) — proximité sémantique via les mots-clés
3. Top-5 par score total, injectées comme SKILLS_HINT dans le prompt du worker

Exemple

Message : "review the git commit for security"

• code-review : trigger "review" trouvé → +2 points
• git-manager : keyword "commit" trouvé → +1 point
• Résultat : code-review (2), git-manager (1) injectées dans le prompt

Format du registre de skills

{
  "name": "code-review",
  "triggers": ["review", "audit", "security"],
  "keywords": ["vulnerability", "OWASP", "XSS"],
  "agents": ["summer"],
  "category": ["complex"]
}

• triggers — mots qui indiquent clairement une skill (haute priorité)
• keywords — termes supplémentaires pour l'association sémantique
• agents — quels workers peuvent utiliser cette skill
• category — classification (simple, complex, critical)

Learnings — Mémoire des corrections

Comment sont-ils créés ?

Les Learnings sont des règles accumulées qui émergent des retours d'expérience :

1. Thumbs-down (👎) — un learning est automatiquement créé avec la source "negative" à partir de la réponse problématique
2. Fix It — relancer une tâche génère un learning avec la source "fixit"
3. Manuels — décisions architecturales et règles, source "manual" ou "architecture"

Format du fichier

Fichier learnings.md à la racine du projet :

# Learnings
> Auto-generated. Injected into GSD prompt at session start.

## Rules
- [2026-04-03T20:00:00Z] [architecture] Rule text here...
- [2026-04-04T10:00:00Z] [security] Another rule...

Comment sont-ils utilisés ?

• Chargés au démarrage de chaque session de worker
• Injectés dans le prompt GSD du Developer (budget — 2000 caractères)
• Les règles les plus récentes en premier (priorité par date)
• Agissent comme une mémoire immunitaire — les erreurs commises une fois ne se reproduisent pas dans les sessions suivantes

Karpathy Loop — Auto-amélioration nocturne

Un cycle automatique d'amélioration des skills, inspiré des idées d'Andrej Karpathy sur l'amélioration itérative.

Comment ça fonctionne ?

Chaque nuit à 3h00 UTC, un pipeline automatique se lance :

1. Collecte de métriques — lit le quality-metrics.json de chaque projet
2. Détection des skills problématiques — filtre les skills avec un taux de succès < 80% ou plus de feedback négatif que positif
3. Analyse Sage — Haiku génère une version améliorée de la skill à partir des erreurs collectées
4. Test A/B en aveugle — 3 scénarios, ordre randomisé, double scoring :
   • Règles Eval (60% du poids) + juge LLM (40% du poids)
5. Création de PR — si la nouvelle version l'emporte (new_wins > old_wins), une pull request est créée
6. Rapport CEO — les résultats sont envoyés sur Telegram pour la décision finale

Métriques de qualité

Chaque projet accumule des statistiques dans quality-metrics.json :

{
  "total_invocations": 42,
  "total_successes": 40,
  "total_feedback_positive": 35,
  "total_feedback_negative": 2,
  "avg_duration_ms": 15000,
  "skills": [
    {
      "name": "code-review",
      "applied_count": 5,
      "success_count": 4
    }
  ]
}

Ces métriques permettent au système de déterminer objectivement quelles skills nécessitent une amélioration, et de suivre les progrès après les mises à jour.