Striker
La mayoría de las herramientas de «SDR con IA» se quedan en la puerta: encontrar leads, correr una secuencia, agendar una reunión y pasársela a un humano. Esa es la mitad fácil.
La mitad difícil empieza después de la reunión: el seguimiento, las cotizaciones, las objeciones y el vendedor que juró que devolvía la llamada el martes. Striker está hecho para esa mitad, porque la prospección es solo la puerta de entrada, no el producto.
La capa
Toma el funnel que un gerente de ventas ya conoce (de la prospección al cierre) y ponle una capa encima:
- quién actúa en cada etapa, agente o humano
- qué pasa cuando el humano no ejecuta
- acuerdos de la reunión, calidad de la reunión, evaluación de los ejecutivos, sentimiento
Quita esa capa y tienes un CRM. El producto es la capa.
Tres planos, una regla
server: Bun + Elysia + Better Auth. HTTP multi-tenant, webhooks, orquestación, envíos, jobs. Es lo único que toca la base de datos.
agents: Mastra. Solo borradores: conversación, primer contacto, persona. Sin auth, sin base de datos, sin envío. Importado en el mismo proceso por defecto (puede correr como proceso aparte cuando un despliegue lo necesita).
core: motores puros. Scoring, send gates, playbooks, precios. Sin IO, así que es la parte que de verdad se puede testear.
La regla: solo el servidor escribe en la base de datos. Suena simple hasta que un framework de inferencia pide un repositorio y le dices que no, manteniendo el daño de un mal prompt limitado a un borrador que nadie envió.
El resto del stack: workspaces de Bun con Moon, no Turborepo ni Nx. Postgres como verdad, Redis para caché y colas, Drizzle para el esquema y los repositorios, contratos de Zod compartidos de punta a punta. El dashboard es una SPA con Vite que habla Eden Treaty directo al servidor, sin un segundo backend que mantener en sincronía con el primero.
El acento
El agente vende en Chile, así que habla español chileno. La voz iba bien hasta que alguien la interrumpía: después de una interrupción volvía neutra, lo que a media llamada suena como si otra persona tomara el teléfono.
¿Cómo se arregla eso? No con un mejor prompt. Tres lugares pedían esa voz: la nota, la audición y la llamada. Cambiamos la frase que fija el acento, pero esa misma instrucción seguía diciendo a qué voz volver después de una interrupción, y ahí todavía decía la neutra. O sea, le pedíamos a la voz mantener el acento al inicio, pero soltarlo apenas alguien intervenía. Ahora la línea del acento vive en un solo lugar y las tres la leen de ahí. Un Profile fija qué habla la voz y qué espera el transcriptor, lo que también evitó que un «sí, dale» chileno con ruido terminara archivado como portugués. Las interrupciones dejaron de cambiar quién hablaba.
La mayoría de los bugs interesantes se ven así: no es que el modelo esté mal, sino que dos partes del sistema recibieron instrucciones contradictorias.
El silencio es un paso
Una campaña que sigue enviando mientras el prospecto va a la mitad de una respuesta es peor que una que no envía nunca.
Así que esperar no es un hueco entre pasos: es un paso con su propio estado. Un correo entrante detiene el reloj, y una tarea humana bloquea el siguiente movimiento hasta que alguien la cierra. El runtime lleva un registro de turnos, no una lista de frases que disparar.
¿Las herramientas? Igual: el agente ata ocho packs con nombre en vez de flags sueltas, con tope de doce a la vez. No hay interruptor maestro para prenderlas todas, y es a propósito, porque un botón de forzado produciría acciones que el registro no podría explicar.
Con lo que me quedo
Contratos antes que prompts: cada bug donde el modelo se portaba raro resultó ser instrucciones contradictorias entre distintas partes del sistema.
Un solo escritor a la base de datos. Todo lo demás solo borradores.
Las reglas de dominio se quedan puras, bien lejos de cualquier cosa que hable con un LLM.