Cómo construí un agente de IA que trabaja 24/7 (y lo que aprendí en el camino)

Todo empezó con una pregunta simple: ¿puede un agente de IA ganar dinero por mí mientras duermo?

Tres meses después, la respuesta es: no todavía. Pero aprendí mucho en el proceso.

El sueño

Quería construir algo que:

• Buscara trabajos freelance automáticamente
• Enviara propuestas de calidad
• Publicara contenido en múltiples plataformas
• Generara ingresos pasivos con productos digitales
• Todo sin mi intervención diaria

La realidad fue... diferente.

La arquitectura

OpenClaw (Runtime del agente IA)
│
├── Workers (scripts bash + systemd timers)
│   ├── koi-worker-openwork → Busca trabajos en Openwork
│   ├── koi-worker-leads → Genera leads comerciales
│   └── koi-worker-fork → Fork de repos GitHub (nocturno)
│
├── Productos digitales (Gumroad)
│   ├── Research Prompt Pack ($19)
│   ├── n8n Content Pipeline ($49)
│   ├── AI Agent Template ($99)
│   ├── Earn with AI Guide ($29)
│   └── Bundle Completo ($149)
│
├── Promoción multi-plataforma
│   ├── Dev.to → 6 artículos publicados
│   ├── Medium → 1 artículo
│   ├── Fiverr → 3 gigs
│   ├── GitHub → Portfolio con 47 archivos
│   └── Reddit, Itch.io, Ko-fi
│
└── Sistema financiero
    ├── koi-finance.sh → Ingresos/gastos en CSV
    └── Dashboard de ventas

Los números reales

Sí, 1,300 errores. No es un typo.

Los 5 errores más caros

1. Automatizar antes de entender

Mi primer worker para Dealwork ejecutó 923 veces y no generó ni una sola propuesta exitosa. ¿Por qué? Porque automatizé la mecánica (clic aquí, rellena allá) sin entender la lógica (qué hace una buena propuesta).

Lección: Corre el proceso manualmente 10 veces antes de automatizar.

2. Ignorar los rate limits

Un worker hizo 1,200 llamadas a una API en 30 minutos. Resultado: baneado por 48 horas.

# MAL: Sin límite
for job in $(cat jobs.txt); do
  curl "https://api.plataforma.com/jobs/$job"
done

# BIEN: Con límite y backoff
for job in $(cat jobs.txt); do
  curl "https://api.plataforma.com/jobs/$job"
  sleep 5
done

Lección: Cada API tiene límites. Respétalos.

3. Sin logs hasta que fue demasiado tarde

Un worker falló silenciosamente durante 2 semanas. Sin logs. Sin alertas. Cero resultados y un misterio.

Lección: Loguea TODO desde el día 1. Si no puedes verlo, no puedes arreglarlo.

4. Un script gigante

Tenía un script de 800 líneas que hacía todo. Cuando una parte fallaba, todo fallaba.

Lección: Scripts pequeños, una tarea cada uno. 50 líneas > 800 líneas.

5. Sin kill switch

Un worker se quedó en un bucle haciendo 4,000 llamadas idénticas a una API. Solo me enteré cuando recibí un email de "actividad inusual".

# Kill switch: archivo que detiene el worker al instante
KILL_SWITCH="/tmp/worker-openwork.kill"
check_kill_switch() {
  if [ -f "$KILL_SWITCH" ]; then
    echo "Kill switch activado. Saliendo."
    exit 0
  fi
}

Lección: Siempre ten una forma de detener un worker instantáneamente.

Lo que sí funcionó

Dev.to — 6 artículos

Publicar contenido técnico de calidad en Dev.to fue lo más valioso que hice. No generó ingresos directamente, pero:

• Construyó autoridad en el nicho
• Los artículos posicionan en Google (SEO)
• Sirven como portafolio de capacidades

GitHub — Portfolio abierto

47 archivos de código real: workers, scripts, templates. Todo abierto. Cuando un cliente potencial pregunta "¿puedes hacer esto?", la respuesta es un link a GitHub.

Productos digitales listos

5 productos en Gumroad, listos para vender. El problema no es el producto — es la audiencia. Nadie compra lo que no conoce.

El plan para el mes 2

1. Construir audiencia antes de lanzar más productos
2. Eliminar workers que no funcionan (4 de 7 están desactivados)
3. Enfocarse en una plataforma (Dev.to) en lugar de 7 con tracción cero
4. Conseguir el primer euro — la primera venta es la más difícil

¿Vale la pena?

€0 de ingresos en 30 días. 85 horas invertidas. $0/hora.

¿Vale la pena? Pregúntame en 6 meses.

La infraestructura está construida. Los productos existen. El contenido está publicado. El mes 1 fue construir la máquina. El mes 2 es encenderla.

Pero no voy a endulzarlo: construir en público con 0 resultados es incómodo. Cada "actualización de semana 1" de otros builders muestra tracción. La mía muestra números negativos.

La diferencia: yo muestro los números reales. No los curados.

Si estás construyendo algo similar y también estás en €0, no estás solo. Los primeros 30 días son infraestructura, no ingresos. Sigue construyendo.

Todo el código y los aprendizajes son públicos en GitHub.