Agente IA para cobros: 4 fallos que nadie ve llegar
Un agente de cobros en producción tiene 48 horas de vida si lo construyes sin los cuatro guardarraíles que nadie menciona en los tutoriales.
Los demos funcionan. El LLM genera recordatorios de pago, los envía por email, actualiza el estado en Notion. Bonito. Pero a las tres semanas tienes un cliente que recibió el mismo recordatorio seis veces, otro al que le generaste la factura dos veces y un bucle de reintentos que lleva corriendo desde el martes sin que nadie lo sepa.
Esto no es un problema del modelo. Es un problema de arquitectura.
Por qué el demo no es producción
El demo vive en un contexto limpio: una sola factura, un solo cliente, cero reintentos, cero fallos de red, cero ejecuciones simultáneas. La producción tiene todo eso a la vez.
Los cuatro fallos que veo repetirse en implementaciones de clientes —antes de que lleguen a nosotros— son estructurales, no de prompt. No los arregla cambiar el modelo ni ajustar la temperatura.
Los 4 fallos que destrozan el flujo de caja
Fallo 1: sin idempotencia en la generación de facturas
El agente escucha un webhook de "servicio completado" y genera la factura. Perfecto. Ahora el webhook llega dos veces (timeout del cliente, reintento automático del proveedor). El agente genera dos facturas. El cliente recibe dos cargos.
El patrón correcto es una clave de idempotencia derivada del evento:
async function createInvoice(event: ServiceCompletedEvent) {
const idempotencyKey = `invoice-${event.serviceId}-${event.clientId}`;
const existing = await db.invoices.findUnique({
where: { idempotencyKey }
});
if (existing) return existing; // ya procesado, devuelve sin crear
return db.invoices.create({
data: {
idempotencyKey,
clientId: event.clientId,
amount: event.amount,
state: 'NUEVA',
}
});
}
Sin esto, cada reintento de webhook crea una factura nueva. La idempotencia no es opcional en agentes que mueven dinero.
Fallo 2: estado perdido entre reintentos del trigger de email
El agente envía el recordatorio de pago el día 15. El email falla (el servidor del cliente está caído). El agente reintenta a los 10 minutos. Pero no recordó que ya intentó enviar ese recordatorio, así que genera uno nuevo con fecha distinta, diferente número de referencia, posiblemente diferente importe si hay lógica de recargos.
El estado de la factura tiene que persistir entre ejecuciones:
type InvoiceState =
| 'NUEVA'
| 'ENVIADA'
| 'VENCIDA'
| 'REINTENTO_1'
| 'REINTENTO_2'
| 'REINTENTO_3'
| 'ESCALADA'
| 'PAGADA';
async function processInvoiceReminder(invoiceId: string) {
const invoice = await db.invoices.findUnique({ where: { id: invoiceId } });
// la máquina de estado decide qué hacer según dónde está
switch (invoice.state) {
case 'ENVIADA':
if (daysSince(invoice.sentAt) >= 30) {
await transition(invoice, 'VENCIDA');
await scheduleReminder(invoice, 'REINTENTO_1');
}
break;
case 'REINTENTO_3':
await transition(invoice, 'ESCALADA');
await notifyHuman(invoice); // nunca más el agente solo
break;
}
}
Sin una máquina de estados explícita, cada ejecución del agente recalcula en qué punto está según heurísticas del prompt. Eso es no determinista.
Fallo 3: reintentos sin límite y sin backoff
El agente reintenta el envío del recordatorio cuando falla. ¿Cuántas veces? ¿Con qué intervalo? Si la respuesta es "las que hagan falta" o "está configurado en el prompt", tienes un bucle activo en algún servidor ahora mismo.
El límite de reintentos tiene que estar en el código, no en la instrucción al modelo:
const MAX_RETRIES = 3;
const BACKOFF_MS = [3_600_000, 86_400_000, 259_200_000]; // 1h, 24h, 72h
async function scheduleNextRetry(invoice: Invoice) {
const retryCount = invoice.retries + 1;
if (retryCount > MAX_RETRIES) {
await transition(invoice, 'ESCALADA');
return;
}
const delayMs = BACKOFF_MS[retryCount - 1];
await queue.add('send-reminder', { invoiceId: invoice.id }, { delay: delayMs });
await db.invoices.update({
where: { id: invoice.id },
data: { retries: retryCount, state: `REINTENTO_${retryCount}` }
});
}
Sin esto el agente puede perseguir a un cliente durante semanas generando un problema legal y de reputación.
Fallo 4: sin escalación a humano cuando todo falla
Este es el más crítico. Los tres primeros recordatorios no funcionaron. ¿Qué hace el agente? Si la respuesta es "seguir reintentando", tienes un agente que actúa de forma autónoma en una situación que requiere criterio humano: negociar un plan de pago, iniciar un proceso de reclamación, decidir si vale la pena o no.
El agente tiene que saber cuándo parar y pasarle el control a una persona. Siempre. Sin excepción. Ver el nodo ESCALADA en la máquina de estados de arriba: en ese punto el agente notifica a un humano y se detiene. No sigue. No decide solo.
La diferencia entre una demo y un sistema de cobro
Lo que se construye en un día de demo:
- LLM que genera emails de recordatorio
- Trigger por fecha
- Envío via API de email
Lo que necesita un sistema de cobro que aguante en producción:
- Idempotencia en generación de facturas y recordatorios
- Máquina de estados persistente por factura
- Backoff exponencial con límite duro de reintentos
- Escalación obligatoria a humano tras agotar reintentos
- Observabilidad: cada transición de estado tiene que ser auditable
Si estás usando nuestro servicio de integración IA, estos guardarraíles ya están en la arquitectura base. No son configurables: son estructurales.
Lo que cuesta construirlo bien vs. mantener lo que se construye rápido
Una implementación sin estos cuatro guardarraíles tiene un coste de mantenimiento real: el primer cobro duplicado, el primer bucle que lleva días corriendo, la primera factura en estado inconsistente. No son hipotéticos. Son inevitables.
Construir esto bien desde el inicio tarda más. Mantener lo que se construyó rápido tarda mucho más, y en un momento peor.
Si estás pensando en automatizar los cobros en tu empresa con un agente IA, podemos revisar la arquitectura antes de que el sistema esté en producción. Es mucho más barato arreglarlo en papel que después del primer problema de caja.
¿Tienes un agente de cobros en producción o lo estás construyendo? Cuéntame en qué punto estás y qué parte de la arquitectura te genera más dudas.