$9.000/mes → $700/mes

Una búsqueda de propiedades devolvía entre 50 y 500 compradores. La ruta antigua generaba mensajes de contacto para cada resultado antes de que el usuario eligiera a quién contactar.

Eso hacía que el costo creciera con los resultados de búsqueda. Debería haber crecido con el número mucho menor de personas que realmente recibían un mensaje.

SendFlow creaba el primer borrador con hasta tres reintentos. Review Gate lo aceptaba o rechazaba, Content Rewriter ajustaba el tono y los detalles, y Message Humanizer producía dos o tres variantes. Ocho procesos ejecutaban esta cadena en paralelo y guardaban el resultado en la base de datos antes de que alguien pulsara Send.

Resultado de búsqueda
  -> SendFlow (hasta tres reintentos)
  -> Review Gate
  -> Content Rewriter
  -> Message Humanizer (2-3 variantes)
  -> guardar todos los resultados

La cadena realizaba entre cuatro y cinco llamadas al modelo por comprador. Para una búsqueda con 500 compradores, eso suponía unas 2.500 llamadas antes de que el usuario seleccionara un destinatario.

Los usuarios contactaban con unos 100 compradores del ejemplo de 500 resultados. Cerca del 80 % de los mensajes precalculados nunca se consumían, lo que dejaba unas 2.000 llamadas sin ningún resultado visible para el usuario. Ajustar los prompts podía abaratar cada llamada, pero no justificaba ejecutar las que no se utilizaban.

La búsqueda revisada devolvía compradores sin generar mensajes de contacto. Una acción explícita Regenerate with AI invocaba un agente especializado para el contacto seleccionado. El contexto incluía ubicación, teléfono, nombres del comprador y del remitente, mercado, actividad del comprador, historial de conversación con formato e identificador del comprador; el resultado seguía siendo editable antes de enviarlo.

Buscar 500 compradores -> generar 0 mensajes
El usuario elige un comprador -> reunir el contexto del contacto y la conversación
Regenerate with AI -> 1 llamada al modelo
ProgressReporter -> actualización WebSocket cada dos segundos
Resultado editable -> el usuario decide si lo envía

La implementación evolucionó. Una captura del repositorio usaba una solicitud REST directa al abrir el panel del contacto seleccionado; el flujo posterior usado como fuente del artículo pasó a requerir una intención explícita del usuario y transmitía el progreso mediante WebSocket. Son etapas del producto, no una única ruta de código simultánea.

El producto tenía más de 25 configuraciones de agentes especializados en gpt-4.1-nano. Se elegía una configuración por solicitud; no era una cadena de 25 agentes. ProgressReporter enviaba una actualización mediante WebSocket cada dos segundos mientras se generaba el mensaje.

Hacer que la generación requiriera un clic hizo visible la espera. Mantuve la respuesta editable, mostré el progreso y generé contenido solo para el destinatario elegido por el usuario.

En el ejemplo documentado de 500 compradores, las llamadas bajaron de unas 2.500 a unas 100, una reducción del 96%. El gasto mensual en modelos pasó de unos $9.000 a unos $700. Esas cifras mensuales redondeadas implican una reducción anualizada cercana a $100.000.

El cambio también eliminó 1.218 líneas, incluido el procesador por lotes de 640 líneas. Borrar esa ruta eliminó también sus reintentos, procesos, persistencia y coordinación entre varios agentes.

• Mide cuánto contenido generado consumen realmente los usuarios.
• Coloca el trabajo costoso detrás del evento de producto que lo necesita.
• Muestra un progreso visible cuando el trabajo bajo demanda no pueda terminar de inmediato.
• Elimina la arquitectura por lotes cuando el producto ya no dependa de ella.