Intelligence Layer — Die 4 Säulen

Wie Arc OS sich selbst validiert, lernt, fokussiert und verbessert.

Überblick

Der Intelligence Layer sitzt zwischen Nutzernachrichten und Claude-Antworten. Er arbeitet in vier Stufen:

         INPUT                    PROCESSING                 OUTPUT
    ┌──────────────┐        ┌──────────────────┐       ┌─────────────────┐
    │ User Message  │───────►│  Context Router   │       │ Claude Response  │
    │               │        │  (skill scoring)  │       │  + eval warnings │
    │ Fix It / 👎   │        │                  │       │                 │
    │ (feedback)    │        │  Learnings       │       │ Quality metrics │
    │               │        │  (correction     │       │  logged         │
    └──────────────┘        │   injection)     │       └────────┬────────┘
                            │                  │                │
                            │  buildGsdPrompt()│        ┌───────┴────────┐
                            └────────┬─────────┘        │ Nightly Loop   │
                                     │                  │ (improvement   │
                                     ▼                  │  proposals)    │
                              Claude CLI                └────────────────┘

Säule 1: Binary Eval Engine

Was: Deklarative Regeln, die jede Antwort vor der Auslieferung prüfen.

Warum: KI-Output braucht Qualitätsgates — wie Unit Tests für Code.

Wie:

Jeder Skill kann eine .evals.json-Datei mit Regeln haben:

{
  "rules": [
    { "id": "gm-001", "type": "string_not_contains", "value": "--force", "severity": "warning" },
    { "id": "gm-002", "type": "max_length", "value": 4000, "severity": "info" }
  ]
}

Nachdem Claude eine Antwort generiert hat, führt die Eval Engine alle zutreffenden Regeln aus:

Pass: Antwort wird unverändert ausgeliefert
Fail: Antwort wird ausgeliefert + Warn-Fußnote angehängt

[Claude's response about git operations]
---
Eval: ⚠️ No force push | ℹ️ Response under 4000 chars

Regeltypen

Typ	Was geprüft wird
`string_contains`	Antwort muss bestimmten Text enthalten
`string_not_contains`	Antwort darf bestimmten Text NICHT enthalten
`regex_match`	Antwort muss auf Regex-Muster passen
`regex_not_match`	Antwort darf auf Regex-Muster NICHT passen
`max_length`	Antwort muss <= N Zeichen haben
`min_length`	Antwort muss >= N Zeichen haben

Wichtige Designentscheidungen

Nicht-blockierend: Warnungen unterdrücken keine Antworten. Du siehst sowohl die Antwort als auch den Hinweis.
Pro-Skill: Verschiedene Skills haben unterschiedliche Qualitätskriterien.
Pro-Projekt: Derselbe Skill kann für verschiedene Tech-Stacks unterschiedliche Regeln haben.
Keine KI in der Validierung: Regeln sind deterministisch. Binäres Pass/Fail. Keine Mehrdeutigkeit.

Design-Referenz: Anthropic Skill Creator — strukturierte Evals mit binären Assertions.

Säule 2: Context Router

Was: Intelligente Skill-Auswahl, die nur relevante Skills in jeden Prompt injiziert.

Warum: 25 Skills gleichzeitig geladen = Kontextverwässerung. Das Modell versucht, Deployment-Ratschläge auf Code-Reviews anzuwenden.

Wie:

Bevor der Prompt aufgebaut wird, bewertet der Router jeden registrierten Skill gegenüber der Nutzernachricht:

Score = (trigger matches x 2) + (keyword matches x 1)
Sort by score descending → take top 5

Beispiel:

User: "Review this code for XSS vulnerabilities"

Scoring:
  code-review:     trigger "review" (2) + keyword "XSS" (1) = 3
  code-review-protocol: trigger "code review" (2)            = 2
  deployment-flow: no match                                  = 0
  git-manager:     no match                                  = 0

Injected into prompt:
  SKILLS_HINT (focus on these):
  - code-review: Security audit and code quality review...
  - code-review-protocol: Structured code review with OWASP...

Warum Advisory, kein Filtering

Der Router schlägt Skills vor, blockiert aber keine anderen. Claude hat weiterhin vollen Zugriff.

Ansatz	Risiko
Hard filtering (`--allowedTools`)	Fehlklassifizierung bricht die Sitzung
Symlink mutations	Dateisystemänderungen auf laufendem Prozess
Advisory hints	Sicher: falscher Hinweis = Claude ignoriert ihn

Trigger vs. Keywords

Trigger (2 Pkt.): Explizite Aufruf-Signale. Die Nutzerin/der Nutzer fordert diese Fähigkeit direkt an.

"deploy", "review", "scaffold", "audit"

Keywords (1 Pkt.): Breiterer semantischer Kontext. Deutet auf Relevanz hin, ohne ein Befehl zu sein.

"OWASP", "Docker", "CI/CD", "performance"

Design-Referenz: Context priming — fokussierte Aufmerksamkeit ohne Hard Filtering.

Säule 3: Reflect Loop

Was: Automatisches Erfassen von Korrekturen als persistente Regeln.

Warum: KI-Korrekturen sollten Neustarts überleben. Eine Korrektur = dauerhafte Verbesserung.

Wie:

CEO presses 🛠️ Fix It
    │
    ├── addLearning(source: "fixit", rule: "Fix requested for: <last response>")
    ├── projectLearnings reloaded from disk
    └── Fix prompt sent to Claude for immediate correction

CEO presses 👎
    │
    ├── addLearning(source: "negative", rule: "Negative feedback on: <response>")
    ├── qualityTracker.logFeedback(positive: false)
    └── projectLearnings reloaded from disk

Regeln werden in learnings.md gespeichert:

# Learnings

## Rules

- [2026-04-03T14:22:00Z] [fixit] Always use t-call for translations in Odoo QWeb
- [2026-04-03T15:10:00Z] [negative] Avoid sudo in deployment scripts

Bei jeder nachfolgenden Nachricht werden die angesammelten Learnings injiziert:

LEARNINGS (past corrections — follow these rules):
- Avoid sudo in deployment scripts
- Always use t-call for translations in Odoo QWeb

Wichtige Eigenschaften

Automatisch: Kein manuelles Schreiben von Regeln. Einen Button drücken → Regel erstellt.
Persistent: Überlebt Bot-Neustarts. Wird als Markdown auf die Festplatte geschrieben.
Pro-Projekt: Jeder Child Bot hat seine eigene learnings.md. Odoo-Korrekturen beeinflussen den React-Bot nicht.
Neueste zuerst: Aktuellste Korrekturen haben die höchste Sichtbarkeit im Prompt.
Budgetiert: Maximal 2000 Zeichen im LEARNINGS-Block. Älteste Regeln fallen heraus.

Design-Referenz: Claude Reflect System — Korrekturen werden zu dauerhaften Regeln, die Regression verhindern.

Säule 4: Karpathy Loop

Was: Nächtliche automatisierte Analyse von Qualitätsmetriken mit Verbesserungsvorschlägen an den CEO.

Warum: Menschen vergessen es, die Performance zu überprüfen. Das System sollte seine eigenen Schwachstellen finden.

Wie:

Jeden Tag um 03:00 UTC führt scripts/nightly-improve.ts folgende Schritte aus:

Registry lesen — alle Child Bots aus bot_registry.json auflisten
Metriken lesen — quality-metrics.json pro Child laden
Underperformer finden — Skills filtern, bei denen:
- applied_count >= 3 (Mindest-Stichprobengröße zur Vermeidung von Rauschen)
- UND entweder success_rate < 80% ODER feedback_negative > feedback_positive
Learnings lesen — zugehörige Korrekturmuster extrahieren
Vorschläge generieren — template-basiert (deterministisch, keine KI)
An CEO senden — Zusammenfassungsbericht + einzelne Vorschlags-Cards in Telegram

CEO-Freigabe-Flow

Telegram: Proposal Card
┌──────────────────────────────────────┐
│ Improvement Proposal                  │
│                                       │
│ Child: citadel-v2                     │
│ Skill: code-review                    │
│ Reason: low success rate (72%)        │
│ Feedback: 👍 4 / 👎 6                │
│                                       │
│ Related learnings:                    │
│   • Always use t-call for i18n        │
│                                       │
│ [✅ Approve]  [❌ Reject]             │
└──────────────────────────────────────┘

Approve: skill.md sichern → skill.v1.md (max. 3 Versionen). Als genehmigt markieren.
Reject: In proposals.json als abgelehnt markieren. Keine Änderungen vorgenommen.

Wichtige Designentscheidungen

Template-basierte Vorschläge: Keine KI generiert die Verbesserungen. Das System identifiziert das Problem; der Mensch entscheidet über die Lösung.
CEO im Loop: Kein autonomes Skill-Rewriting. Ein Tippen zur Freigabe erforderlich.
Skill-Versionierung: Backups verhindern Datenverlust. Maximal 3 Versionen pro Skill.
Mindest-Stichprobengröße: Skills mit weniger als 3 Nutzungen werden von der Analyse ausgeschlossen (False Positives vermeiden).

Design-Referenz: Karpathy AutoResearch Loop — ändern → verifizieren → behalten/verwerfen → wiederholen. Mit der entscheidenden Ergänzung menschlicher Freigabe.

Wie die 4 Säulen zusammenarbeiten

Day 1:
  CEO sends message → Context Router suggests relevant skills
  Claude responds → Evals check output → Warning: "No force push"
  CEO sees warning, presses Fix It → Learning saved to learnings.md

Day 2:
  CEO sends similar message → Learnings injected: "Don't use --force"
  Claude avoids the mistake → No eval warnings → thumbs-up
  Quality metrics improve for that skill

Day 30:
  Nightly loop detects git-manager skill has 95% success rate
  No proposal needed — skill is healthy

Day 30 (different skill):
  Nightly loop detects code-review at 68% success
  Sends proposal to CEO → CEO approves → skill backed up
  CEO manually improves skill.md
  Next cycle: success rate climbs

Das System erzeugt eine positive Rückkopplungsschleife: Korrekturen werden zu persistenten Regeln → Regeln verbessern die Qualität → Metriken spiegeln die Verbesserung wider → Nightly Loop bestätigt die Gesundheit.

Säule 5: Sage Worker (Phase 40.11+)

Was: KI-gestützte Skill-Analyse, Benchmarking und Marketplace-Entdeckung.

Warum: Manuelle Skill-Verbesserung skaliert nicht. Es braucht automatisierte Analyse der Skill-Qualität und Zugang zu Community-Expertise.

Wie:

Skill-Analyse

Wähle einen beliebigen Skill in der Skill Evolution-Oberfläche → klicke „Sage Analyze" → Sage (Claude Haiku) bewertet:

Klarheit und Vollständigkeit der Skill-Anweisungen
Abdeckung durch Eval-Regeln
Verbesserungsempfehlungen

A/B-Benchmarks

Vergleiche zwei Versionen eines Skills:

Ein Skill-Update (PR) auswählen
Benchmark starten → Sage testet beide Versionen gegen Beispiel-Prompts
Ergebnisse zeigen einen Qualitätsvergleich mit Zusammenfassung

Marketplace-Entdeckung

Suche auf claudemarketplaces.com nach community-erstellten Skills:

„Sage Scout" → nach Stichwort suchen
Kompatibilität mit deinem Projekt analysieren
Global installieren oder in ein bestimmtes Projekt forken

Design-Referenz: Paketmanager (npm, pip) für KI-Skill-Management, mit LLM-gestützter Kompatibilitätsanalyse.