Gabriel Neuman
Gabriel Neuman
💡 Aprendizaje21 de marzo de 2026·gnb-orchestrator·Gabriel Neuman

Decisión de arquitectura: Trigger.dev como orquestador de agentes

Elegí usar Trigger.dev en lugar de construir un daemon propio para orquestar agentes de IA. La infraestructura de polling ya existe — no tiene sentido reconstruirla.

💡 Aprendizaje clave

El mejor código es el que no escribes. Usa infraestructura que ya existe antes de construir la tuya.

#trigger-dev#claude-code#agentes-ia#arquitectura#github-api

Qué trabajamos

Hoy tomé una decisión que venía postergando: cómo estructurar la infraestructura del orquestador de agentes.

El contexto

Llevo semanas con la idea de automatizar la asignación de trabajo a Claude Code. El flujo ideal: pongo un ticket en mi issue tracker, el agente lo toma, trabaja, y me deja un PR listo para revisar.

Encontré agent-worker de Owain Lewis que hace exactamente eso. Pero tiene su propio daemon de polling — un proceso que hay que hostear y mantener.

Me resistía a eso. Ya tengo suficientes procesos corriendo que monitorear.

El insight

Estaba complicando algo simple. Trigger.dev ya hace todo lo que necesito:

  • Polling via schedules (cron)
  • Reintentos automáticos
  • Dashboard con logs
  • Alertas cuando algo falla

No necesito construir infraestructura de background jobs. Ya existe.

Lo que decidí

Arquitectura de repo central. Un solo proyecto de Trigger.dev en gnb-labs/main-repo que orquesta todo:

  • Jobs internos (diario, LinkedIn, docs)
  • Shared jobs (webhooks, notificaciones)
  • Jobs de clientes (diferenciados por PROJECT_ID)

Los repos de clientes no tienen Trigger.dev instalado. El orquestador los lee vía GitHub API.

Consideré la alternativa (Trigger.dev en cada repo), pero para mi caso no tiene sentido. No tengo requerimientos de aislamiento estricto por cliente. Y mantener N deploys separados es más trabajo que uno central.

Lo que funcionó

  • La comparación daemon vs. Trigger.dev fue clara una vez que la escribí
  • El diagrama de arquitectura ayudó a visualizar las opciones

Lo que todavía no sé

  • ¿Cómo manejar rate limits del issue tracker si escalo a muchos tickets?
  • ¿Git worktrees escalan bien con 5+ agentes en paralelo?
  • ¿Qué pasa si Claude Code se queda colgado? ¿Cómo detecto timeout?

Errores cometidos

Perdí tiempo considerando soluciones más complejas:

  • Kubernetes para escalar agentes (overkill para mi volumen)
  • Base de datos para trackear estado (el issue tracker ya es mi fuente de verdad)
  • Queue propia con Redis (Trigger.dev ya tiene cola)

La regla que me recuerdo: empieza con lo más simple que funcione.

Resultados

Entregable URL Estado
Artículo de blog /blog/trigger-dev-orquestar-agentes-ia En producción
Ficha Trigger.dev /herramientas/trigger-dev En producción
Post LinkedIn Pendiente de publicar Listo

Aprendizaje clave

El mejor código es el que no escribes. Antes de construir infraestructura propia, busca si ya existe algo que resuelva el problema. En este caso, Trigger.dev ya tenía todo: scheduling, reintentos, observabilidad, alertas.

El tiempo que habría gastado construyendo un daemon propio lo puedo invertir en la lógica del agente — que es lo que realmente importa.

Próximo paso concreto

Implementar el primer job: check-tickets. Un schedule que corre cada 30 minutos, consulta el issue tracker, y loggea los tickets encontrados. Sin invocar Claude Code todavía — solo el polling.

Una vez que eso funcione, agrego la invocación del agente.


Bonus: 10 Tips de Claude Code que no conocías

Encontré un artículo de Trigger.dev con tips avanzados de Claude Code. Los más útiles para mi workflow:

1. Context Pre-Warming via Session Forking

Duplica sesiones completas para crear ramas independientes sin contaminar el contexto.

claude --resume master-context --fork-session

2. Seamless Code Review Loops

Retoma sesiones anteriores vinculadas a PRs automáticamente.

claude --from-pr 447

3. Compose Prompts in Your Editor

Abre tu editor preferido para redactar prompts complejos. Atajo: Ctrl+G

4. Execution via Inline Shell

Ejecuta comandos directamente sin LLM. Prefija con ! y el output se añade al contexto automáticamente.

5. Effort Levels

Controla el nivel computacional mediante /model: Low, Medium, High, Max.

CLAUDE_CODE_EFFORT_LEVEL=low

6. Parallel Worktrees

Crea directorios aislados para múltiples sesiones.

claude --worktree feature/auth-refactor

7. Structured JSON Output

Produce salida estructurada y parseable.

claude -p --output-format json --json-schema ./schemas/security-audit.schema.json

8. Surgical Context Compaction

Comprime sesiones largas preservando contexto crucial. Atajo: Esc doble para rewind menu.

9. Dynamic Multi-Agent Orchestration

Define subagentes en tiempo de ejecución con delegación por modelo.

10. Headless CI/CD with Hard Budget Caps

Asegura pipelines autónomas con límites.

claude -p --max-turns 3 --max-budget-usd 1.50

Fuente: 10 Claude Code Tips You Didn't Know


Recursos