A Automata
← Volver a casos

orch-agents

De conocimiento que vive sólo en cabezas a un archivo que cualquiera puede leer — un sistema que decide qué IA atiende cada tarea en GitHub y Linear.

Stack
  • TypeScript
  • Claude Agent SDK
  • Fastify
  • GitHub App
  • Linear Agent API
  • git worktrees
Licencia

MIT

En resumen — para no-técnicos

Un equipo tenía mucho conocimiento sobre qué tarea debía atender cada IA — pero ese conocimiento vivía sólo en la cabeza de algunos desarrolladores. Cuando esa persona se iba de vacaciones, el sistema dejaba de funcionar bien.

Construimos un archivo de texto que captura ese criterio — y un sistema que lo lee para decidir qué hacer ante cada nueva tarea. Hoy cualquier persona nueva (o cualquier IA nueva) puede leerlo en cinco minutos y ponerse al día. El conocimiento dejó de ser frágil.

El diagnóstico

“Todo equipo tiene conocimiento sobre qué IA debería encargarse de qué tarea. Vive en una sola cabeza — y se rompe en el momento que el trabajo crece más allá de esa cabeza.”

Un repositorio de GitHub con incidencias, revisiones de código, pruebas automáticas y un tablero de Linear genera decenas de decisiones al día: revisa este cambio, arregla este error, investiga este fallo, audita este pedido de seguridad. Para la mayoría de equipos, ese criterio vive en hilos de Slack y memoria muscular. Las herramientas de IA empeoraron el problema — ahora todos tienen más decisiones, no menos, y nadie puede describir por qué cierta IA fue la indicada para cierta tarea.

Qué estructuramos

Un solo archivo de texto que cualquiera puede leer y revisar: WORKFLOW.md.

Un bloque de texto que hace el criterio legible para humanos y para máquinas:

templates:
  tdd-workflow:   [coder, tester]
  feature-build:  [architect, coder, reviewer]
  security-audit: [security-architect]

github:
  events:
    pull_request.opened:     github-ops
    issues.labeled.bug:      tdd-workflow
    workflow_run.failure:    quick-fix

agents:
  routing:
    bug:      tdd-workflow
    feature:  feature-build
    security: security-audit
    default:  quick-fix

Todo lo que la organización sabe sobre “qué IA atiende cada situación” ahora vive en un archivo que cualquiera puede leer, revisar, y comparar versión contra versión. El conocimiento de una cabeza, ahora en un archivo.

Qué lanzamos

  • 18+ roles de IA listos — programador, revisor, arquitecto, especialista de seguridad, encargado de pruebas, y más
  • Cada IA en su propio espacio de trabajo — sin pisar el trabajo de otras, sin contaminación cruzada
  • Revisión humana antes de cada cambio importante — todo cambio pasa por revisión automática (código, pruebas, seguridad) antes de aprobarse
  • Funciona en las herramientas que ya usas — GitHub y Linear, no una plataforma aparte
  • Diseñado pensando en seguridad — sistema de permisos visible, gestión inteligente de conversaciones largas, reintentos automáticos, y comando stop accesible desde cualquier incidencia o revisión
  • Se distribuye doblemente — como servicio listo para usar o como librería que tu equipo puede integrar

Evidencia

De la versión 0.2.0 a la 0.4.0 en cuatro semanas. Entre otros hitos:

  • El sistema aprende a usar herramientas nuevas conforme las necesita — reemplazando reglas duras que estaban en el código
  • Un único punto de entrada consolidó tres rutas en una — cero código muerto
  • WORKFLOW.md se volvió la única fuente de verdad, sin atajos por configuración
  • Identificadores tipados (PlanId, WorkItemId, ExecId, AgentSessionId) con hallazgos de auditoría aplicados

El historial de cambios y los commits están públicos — no hay que confiar en mi palabra.

Qué demuestra

Si ya construiste algo con Cursor, Bolt o Lovable y estás a un incidente de “¿qué hizo cada IA y por qué?” de perder confianza en tu código, esto es lo que significa conocimiento escrito, no perdido. No una metodología — un archivo que cualquiera puede leer.

05 · Contacto

¿Tu caso tiene el mismo perfil?

01 Agenda una llamada

30 minutos. Evaluamos tu caso, te damos un timeline y una arquitectura realista.

02 Propuesta técnica

En 5 días desde la llamada. Arquitectura, fases, costes, stack elegido y por qué.

03 Empezamos

Primer deploy en menos de 4 semanas desde el kickoff.

Sin pitch, sin compromiso.