Workers e Intelligence Layer

Arc OS utiliza un sistema de workers para distribuir tareas entre agentes de IA especializados, y el Intelligence Layer garantiza la calidad de sus respuestas mediante cuatro módulos: Binary Evals, Context Router, Learnings y Karpathy Loop.

Sistema de workers

Cada worker es un agente de IA independiente con un rol, modelo y conjunto de herramientas definidos. Los workers operan dentro de un proyecto y están disponibles a través del Workspace UI o comandos de Telegram (/c, /d, /w:worker_id).

Workers integrados

Tipos de workers

• chat — conversación por turnos con historial de contexto completo. El worker recibe toda la conversación anterior y responde como interlocutor.
• terminal — ejecución en streaming con tool events. El worker opera como una sesión de terminal, ejecutando herramientas en secuencia y transmitiendo el progreso en tiempo real.

Crear un worker personalizado

Los workers personalizados se describen en el archivo config/workers_registry.json. Cada entrada define el comportamiento del agente:

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

Campos de configuración

Binary Evals — Validación de respuestas

¿Qué son?

Reglas declarativas para verificar la calidad de las respuestas de los workers. Cada regla es determinista (sin IA), se ejecuta al instante y no bloquea la respuesta. Los resultados tienen severity warning o info — informan, no detienen.

6 tipos de reglas

Formato del archivo evals

El archivo se coloca junto a 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"
    }
  ]
}

Cada regla tiene un id único, un name legible por humanos, uno de los 6 tipos, un value para la comparación y un severity (warning o info).

Context Router — Selección automática de skills

¿Cómo funciona?

Con cada mensaje, el Context Router puntúa todas las skills de skills/_registry.json y selecciona automáticamente las más relevantes:

1. Trigger match (+2 puntos) — coincidencia directa de una palabra trigger del mensaje
2. Keyword match (+1 punto) — proximidad semántica por palabras clave
3. Top-5 por puntaje total, inyectadas como SKILLS_HINT en el prompt del worker

Ejemplo

Mensaje: "review the git commit for security"

• code-review: trigger "review" encontrado → +2 puntos
• git-manager: keyword "commit" encontrado → +1 punto
• Resultado: code-review (2), git-manager (1) inyectadas en el prompt

Formato del registro de skills

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

• triggers — palabras que apuntan directamente a la skill (alta prioridad)
• keywords — términos adicionales para la asociación semántica
• agents — qué workers pueden usar esta skill
• category — clasificación (simple, complex, critical)

Learnings — Memoria de correcciones

¿Cómo se crean?

Los Learnings son reglas acumuladas que surgen del feedback:

1. Thumbs-down (👎) — se crea automáticamente un learning con source "negative" a partir de una respuesta problemática
2. Fix It — volver a ejecutar una tarea genera un learning con source "fixit"
3. Manuales — decisiones de arquitectura y reglas, source "manual" o "architecture"

Formato del archivo

El archivo learnings.md en la raíz del proyecto:

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

¿Cómo se usan?

• Se cargan al inicio de cada sesión del worker
• Se inyectan en el GSD-prompt del Developer (presupuesto: 2000 caracteres)
• Las reglas más recientes van primero (prioridad por tiempo)
• Actúan como memoria inmune — los errores cometidos una vez no se repiten en sesiones posteriores

Karpathy Loop — Automejora nocturna

Ciclo automático de mejora de skills, inspirado en las ideas de Andrej Karpathy sobre la automejora iterativa.

¿Cómo funciona?

Cada noche a las 3:00 UTC se ejecuta un pipeline automático:

1. Recopilación de métricas — lee quality-metrics.json de cada proyecto
2. Detección de skills problemáticas — filtra skills con success rate < 80% o con más feedback negativo que positivo
3. Análisis con Sage — Haiku genera una versión mejorada de la skill a partir de los errores recopilados
4. Test A/B ciego — 3 escenarios, orden aleatorizado, puntuación dual:
   • Eval rules (60% del peso) + LLM judge (40% del peso)
5. Creación de PR — si la nueva versión gana (new_wins > old_wins), se crea un pull request
6. Reporte al CEO — los resultados se envían por Telegram para la decisión final

Métricas de calidad

Cada proyecto acumula estadísticas en 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
    }
  ]
}

Estas métricas permiten al sistema identificar objetivamente qué skills necesitan mejoras y hacer seguimiento del progreso tras las actualizaciones.