Nicolás Dominici

La mayoría de los sistemas de agentes que fallan no fallan porque el modelo sea demasiado débil.

Fallan porque el trabajo no está definido.

El operador dice:

Ayudame con ventas.

Mejorá el sitio web.

Hacé contenido.

Analizá esto.

Encontrá oportunidades.

Después el agente devuelve algo plausible, genérico y difícil de usar. Todos culpan al modelo. A veces el modelo lo merece. Por lo general, el primer fallo pasó antes.

No había brief.

Un prompt es un pedido.

Un brief es un contrato.

La diferencia importa porque los agentes no son empleados mágicos escondidos detrás de un chat. Son superficies de ejecución. Pueden clasificar, redactar, resumir, inspeccionar, investigar, comparar, enrutar, actualizar, recordar y proponer. Pero no pueden inventar el negocio a partir de vibes de forma responsable.

Cuanto más claro es el operador, más apalancamiento puede crear el agente.

Cuanto más vago es el operador, más caro se vuelve el teatro.

Más agentes hacen el ruido más fuerte

Cuando armé mi propia flota de agentes, pensé que el cuello de botella era la capacidad.

Demasiados proyectos. Demasiadas ideas. Demasiados sistemas a medias. Demasiado mantenimiento. Demasiados follow-ups. Demasiado context switching.

La respuesta obvia era apalancamiento.

Más agentes. Más jobs programados. Más integraciones. Más inboxes. Más automatizaciones. Más memoria.

Técnicamente, funcionó.

Los jobs corrían. Los reportes caían. Los archivos se actualizaban. Los bots capturaban ideas. Los workflows se ejecutaban. El sistema parecía vivo.

Después apareció la parte incómoda.

Algunos agentes no esperaban mejor inteligencia.

Me esperaban a mí.

Había armado roles antes de definir suficiente trabajo real para que esos roles lo tuvieran.

Esa es la parte que nadie quiere admitir. Una persona confundida es ineficiente. Una flota de agentes sirviendo a una persona confundida es teatro caro con mejores logs.

Cada agente nuevo suma preguntas:

  • ¿Qué le pertenece a este agente?
  • ¿Qué puede tocar?
  • ¿Qué produce?
  • ¿Quién consume el output?
  • ¿Cuándo debería actuar sin preguntar?
  • ¿Cuándo tiene que escalar?
  • ¿Qué significa “bien”?
  • ¿Qué pasa si nadie responde?
  • ¿Cómo sabemos si el trabajo cambió la realidad?

Sin respuestas, el agente no es un compañero de equipo. Es otra bandeja de entrada.

El operador no desaparece

La versión fantástica de los agentes dice:

Armá suficientes y la empresa empieza a correr sola.

La versión que viví es menos cómoda:

Si el operador no define el trabajo, la empresa se queda quieta con mejor automatización.

Los agentes sacan trabajo manual. No sacan juicio.

El operador todavía elige prioridades, define límites, mata procesos muertos, acepta o rechaza outputs, decide qué riesgo es aceptable y se hace cargo de las consecuencias.

Esto no es lenguaje motivacional. Es mecánico.

El operador sigue siendo el sistema operativo.

La flota de agentes acelera ese sistema operativo. No lo reemplaza.

Un operador claro obtiene apalancamiento: mejores borradores, mejores reportes, mejores listas de follow-up, mejores resúmenes, mejor monitoreo, mejor ejecución.

Un operador vago obtiene artefactos que describen que no pasó nada importante.

Un brief útil tiene siete partes

Un buen brief de agente no tiene que ser largo. Tiene que ser lo bastante completo para que el agente pueda actuar sin inventar el negocio.

Las siete partes que me importan son:

1. Resultado

¿Qué debería ser distinto cuando este trabajo esté hecho?

No la actividad. El resultado.

Malo:

Analizá nuestros leads.

Mejor:

Identificá qué leads inbound de los últimos 14 días merecen follow-up esta semana, explicá por qué y producí una lista de acciones priorizada para el owner.

2. Contexto

¿Qué necesita saber el agente para tomar decisiones razonables?

Incluye el modelo de negocio, la oferta, el tipo de cliente, archivos relevantes, decisiones previas, restricciones, prioridades actuales, definiciones y todo lo que normalmente viviría en la cabeza de un empleado competente.

Mal contexto produce tonterías con confianza.

3. Restricciones

¿Qué tiene que respetar el agente?

Presupuesto. Tono. Herramientas. Permisos. Límites legales. Promesas a clientes. Reglas de marca. Límites de datos. Canales. Deadline. Formato de output. Requisitos de aprobación humana.

Autonomía sin restricciones es inútil o peligrosa.

4. Definición de listo

¿Cómo sabemos que el trabajo está completo?

Una meta vaga produce output vago.

Ejemplos:

  • Un CSV con leads calificados y próximas acciones.
  • Un borrador de email por prospecto.
  • Una lista de registros que necesitan revisión humana.
  • Un resumen que se pueda pegar en la reunión operativa semanal.
  • Un pull request con tests pasando.
  • Una recomendación con supuestos y riesgos declarados.

5. Acciones permitidas

¿Qué puede hacer el agente de verdad?

¿Solo leer? ¿Solo redactar? ¿Actualizar campos del CRM? ¿Enviar mensajes? ¿Crear tareas? ¿Modificar archivos? ¿Disparar workflows? ¿Gastar créditos? ¿Contactar clientes?

La mayoría de los agentes de negocio no deberían empezar con permiso amplio. Deberían ganarse autoridad demostrando confiabilidad en carriles estrechos.

6. Modos de fallo

¿Qué debería evitar el agente?

Esta es la sección que la mayoría saltea, y suele ser la más importante.

Ejemplos:

  • No enviar un mensaje al cliente sin aprobación.
  • No sobrescribir archivos fuente de verdad; proponer un diff.
  • No inventar precios faltantes.
  • No marcar un lead como perdido sin revisión humana.
  • No resumir documentos legales o financieros como si fueran asesoramiento.
  • Escalar cuando la confianza es baja o el contexto entra en conflicto.

El agente necesita saber cómo se ve lo malo.

7. Próxima acción

¿Qué pasa después de que se produce el output?

Un reporte que nadie lee es desperdicio. Una clasificación que no enruta trabajo es decoración. Un resumen que no cambia una decisión es teatro.

Cada brief debería conectar con una próxima acción: enviar, revisar, aprobar, asignar, hacer follow-up, actualizar, publicar, archivar, programar, escalar.

Si no hay próxima acción, capaz que el trabajo no importa.

Un mal prompt versus un brief de verdad

Mal prompt:

Ayudame a mejorar el follow-up de ventas.

Esto suena razonable. No es delegación.

Mejor brief:

Revisá los leads en pipeline.yaml con estado new, qualified o waiting_reply de los últimos 30 días. Producí una lista de follow-up priorizada para esta semana. Usá las reglas de prioridad de sales-policy.md. Incluí owner, fecha del último contacto, mensaje recomendado, razón de prioridad y si requiere aprobación humana. No envíes mensajes. Marcá cualquier registro con fuente faltante, estado poco claro o notas en conflicto. Output en Markdown bajo reports/follow-up-review-YYYY-MM-DD.md.

Eso es un trabajo.

El primero le pide al agente que adivine el negocio.

El segundo le da un carril.

Las empresas chicas lo sienten primero

Las empresas grandes pueden esconder modelos operativos poco claros detrás de departamentos, reuniones y teatro de procesos.

Las empresas chicas no pueden.

Si nadie es dueño del follow-up, el follow-up no pasa. Si nadie define calificación, cada lead se convierte en debate. Si nadie decide qué se mide, los dashboards se vuelven decoración. Si nadie mantiene el contexto, cada respuesta depende de memoria y suerte.

Los agentes exponen esto.

Muestran si el negocio tiene un modelo operativo o solo hábitos.

Una empresa que dice “necesitamos un agente de ventas con IA” a menudo necesita, primero:

  • un camino de intake;
  • una regla de calificación;
  • una fuente de verdad;
  • una cadencia de follow-up;
  • un camino de escalación;
  • un set de mensajes aprobados;
  • una revisión semanal de qué se movió y qué murió.

Solo después un agente tiene algo útil para operar.

Si no, es un chatbot encima de un proceso roto.

El trabajo real del operador

En una operación agéntica, el operador tiene cinco trabajos.

Primero, elegir el trabajo.

No todo merece automatización. No todo proceso merece un agente. No toda tarea recurrente merece existir.

Segundo, escribir el brief.

Darle forma al trabajo antes de delegarlo.

Tercero, mantener el contexto.

Los agentes necesitan verdad actual. Docs viejos, supuestos obsoletos, instrucciones contradictorias y archivos muertos envenenan el sistema en silencio.

Cuarto, revisar consecuencias.

La pregunta no es si el agente completó la tarea. La pregunta es si algo en el mundo real mejoró.

Quinto, matar lo que no paga el alquiler.

Agentes muertos. Workflows muertos. Dashboards muertos. Rituales muertos. Si no crean valor externo, son decoración interna.

Ese quinto trabajo es el más difícil.

Un mal sistema se arregla. Un sistema mediocre se convierte en mueble.

El estándar sube

Los agentes no reemplazan al operador.

Suben el estándar del operador.

Cuando el software puede redactar, clasificar, resumir, monitorear, inspeccionar, enrutar y reportar, el cuello de botella restante es más difícil de esconder.

¿Qué debería hacerse?

¿Para quién?

¿Para cuándo?

¿Con qué estándar?

¿Con qué autoridad?

¿Qué pasa después?

Ese es el trabajo.

La era de los agentes no hace el juicio menos importante.

Lo hace más visible.


Ayudo a empresas a convertir operaciones poco claras en sistemas prácticos: intake, follow-up, reporting, documentación, workflows de agentes y la capa operativa alrededor. Si tu equipo necesita agentes que puedan operar de verdad dentro del negocio, contactame.

También podés escribirme por email o DM en LinkedIn.