Worker und Intelligence Layer

Arc OS nutzt ein Worker-System, um Aufgaben auf spezialisierte KI-Agenten zu verteilen. Der Intelligence Layer sichert die Antwortqualität durch vier Module: Binary Evals, Context Router, Learnings und Karpathy Loop.

Das Worker-System

Jeder Worker ist ein eigenständiger KI-Agent mit definierter Rolle, Modell und Werkzeugset. Worker arbeiten innerhalb eines Projekts und sind über die Workspace UI oder Telegram-Befehle (/c, /d, /w:worker_id) erreichbar.

Eingebaute Worker

Worker-Typen

• chat — Turn-basiertes Gespräch mit vollständigem Kontextverlauf. Der Worker erhält den gesamten bisherigen Chatverlauf und antwortet wie ein Gesprächspartner.
• terminal — Streaming-Ausführung mit Tool-Events. Der Worker arbeitet wie eine Terminal-Sitzung, führt Werkzeuge sequenziell aus und überträgt den Fortschritt in Echtzeit.

Eigenen Worker erstellen

Benutzerdefinierte Worker werden in der Datei config/workers_registry.json beschrieben. Jeder Eintrag definiert das Verhalten des Agenten:

{
  "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
}

Konfigurationsfelder

Binary Evals — Antwortvalidierung

Was ist das?

Deklarative Regeln zur Qualitätsprüfung von Worker-Antworten. Jede Regel ist deterministisch (ohne KI), läuft sofort durch und blockiert die Antwort nicht. Ergebnisse haben den Schweregrad warning oder info — sie informieren, stoppen aber nicht.

6 Regeltypen

Dateiformat für Evals

Die Datei liegt neben dem 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"
    }
  ]
}

Jede Regel hat eine eindeutige id, einen menschenlesbaren name, einen der 6 Typen, einen value für den Vergleich und einen severity-Wert (warning oder info).

Context Router — Automatische Skill-Auswahl

Wie funktioniert das?

Bei jeder Nachricht bewertet der Context Router alle Skills aus skills/_registry.json und wählt automatisch die relevantesten aus:

1. Trigger-Treffer (+2 Punkte) — direktes Vorkommen eines Trigger-Worts aus der Nachricht
2. Keyword-Treffer (+1 Punkt) — semantische Nähe anhand von Schlüsselwörtern
3. Top-5 nach Punktzahl werden als SKILLS_HINT in den Worker-Prompt injiziert

Beispiel

Nachricht: "review the git commit for security"

• code-review: Trigger "review" gefunden → +2 Punkte
• git-manager: Keyword "commit" gefunden → +1 Punkt
• Ergebnis: code-review (2), git-manager (1) in den Prompt injiziert

Format des Skill-Registers

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

• triggers — Wörter, die eindeutig auf einen Skill hinweisen (hohe Priorität)
• keywords — zusätzliche Begriffe für semantische Zuordnung
• agents — welche Worker diesen Skill verwenden können
• category — Klassifizierung (simple, complex, critical)

Learnings — Korrektur-Gedächtnis

Wie entstehen Learnings?

Learnings sind akkumulierte Regeln, die aus Feedback entstehen:

1. Thumbs-down (👎) — es wird automatisch ein Learning mit der Quelle "negative" auf Basis der problematischen Antwort erstellt
2. Fix It — ein erneuter Durchlauf der Aufgabe erzeugt ein Learning mit der Quelle "fixit"
3. Manuell — Architekturentscheidungen und Regeln, Quelle "manual" oder "architecture"

Dateiformat

Datei learnings.md im Projektstamm:

# 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...

Wie werden sie verwendet?

• Werden beim Start jeder Worker-Sitzung geladen
• In den GSD-Prompt des Developer injiziert (Budget: 2000 Zeichen)
• Neueste Regeln zuerst (Priorität nach Zeit)
• Wirken als Immungedächtnis — einmal gemachte Fehler werden in späteren Sitzungen nicht wiederholt

Karpathy Loop — Nächtliche Selbstoptimierung

Ein automatischer Skill-Verbesserungszyklus, inspiriert von Andrej Karpathys Ideen zum iterativen Self-Improvement.

Wie funktioniert das?

Jede Nacht um 3:00 UTC startet eine automatische Pipeline:

1. Metriken sammeln — liest quality-metrics.json jedes Projekts
2. Problematische Skills finden — filtert Skills mit einer Erfolgsrate < 80 % oder mehr negativem als positivem Feedback
3. Sage-Analyse — Haiku generiert eine verbesserte Skill-Version auf Basis der gesammelten Fehler
4. Blinder A/B-Test — 3 Szenarien, randomisierte Reihenfolge, duales Scoring:
   • Eval-Regeln (60 % Gewicht) + LLM-Judge (40 % Gewicht)
5. PR erstellen — gewinnt die neue Version (new_wins > old_wins), wird ein Pull Request erstellt
6. CEO-Bericht — Ergebnisse werden per Telegram für die finale Entscheidung zugestellt

Qualitätsmetriken

Jedes Projekt akkumuliert Statistiken in 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
    }
  ]
}

Diese Metriken ermöglichen es dem System, objektiv zu bestimmen, welche Skills verbessert werden müssen, und den Fortschritt nach Updates zu verfolgen.