El agente con puesto fijo

Comprar software de IA solía significar comprar una función: un chatbot que contesta preguntas frecuentes, una regla que envía un correo cuando algo cambia. La función esperaba a que alguien la usara, y no se le atribuía nada más allá de eso.

Lo que Salesforce presentó el 11 de septiembre es distinto. No son funciones sueltas: son siete agentes con nombre propio y un puesto definido —Casey, Paige, Carter, Hunter, Marshall, Piper y Fin—, cada uno responsable de una parte completa de la operación de un negocio: ventas, servicio, comercio, tecnología y recursos humanos, cadena de suministro y experiencia de cliente.

La diferencia no es cosmética. Una herramienta espera a que la uses. Un agente con puesto se espera que cargue su parte de la operación todos los días, sin que nadie se lo pida de nuevo cada vez, y que se le pueda evaluar por si esa parte se cumplió o no. Eso es exactamente lo que implica ponerle nombre y función fija en vez de dejarlo como una característica más dentro de un producto.

Quiénes son, según quien los construyó

Tres de los siete atienden directamente al cliente. Casey resuelve incidentes de servicio por voz, SMS, WhatsApp y chat web, con soporte listo para preguntas frecuentes, devoluciones y gestión de cuenta, y sabe cuándo pasarle la conversación a una persona. Carter ayuda a comprar: guía a alguien a encontrar y comparar productos, contesta sus dudas y cierra la venta dentro del mismo chat. Fin resuelve flujos completos de experiencia de cliente en cualquier canal, apoyado en un motor propio que Salesforce llama Operator y en un conjunto de modelos entrenados específicamente para atención, llamados Fin Apex.

Dos operan hacia adentro de la empresa. Paige resuelve solicitudes internas de tecnología y recursos humanos dentro de Slack, portales y las herramientas que el equipo ya usa todos los días. Marshall orquesta procesos completos de cadena de suministro y de back office, ejecuta el trabajo manual de forma determinista —es decir, siguiendo siempre la misma regla, no improvisando— y deja un registro de auditoría de cada acción que toma.

Los últimos dos trabajan el embudo de ventas. Piper recorre sitios web y bandejas de entrada para calificar y convertir en oportunidad a quien llega mostrando interés. Hunter trabaja un pipeline de ventas saliente completo, desde la investigación de a quién contactar hasta el seguimiento, colaborando con los vendedores humanos durante semanas y meses de una misma relación comercial.

Seis de los siete ya están disponibles de forma general. Hunter sigue en piloto, con disponibilidad general anunciada para noviembre de 2026, y es el primero en usar lo que Salesforce llama un runtime de horizonte largo: diseñado para perseguir una meta durante semanas en vez de resolver una sola conversación y olvidarla.

Lo que cambia cuando un agente tiene puesto

Hay tres cosas distintas escondidas detrás de la palabra “puesto”, y vale la pena separarlas porque cada una trae su propia exigencia.

La primera es memoria que se acumula. Un chatbot normal olvida la conversación en cuanto termina. Hunter, trabajando el mismo pipeline durante semanas, arrastra contexto de una semana a la siguiente — lo cual significa que un buen criterio se compone con el tiempo, y también que un error sin corregir se repite con el tiempo, en vez de resetearse solo.

La segunda es alcance definido. En vez de un asistente genérico al que hay que explicarle cada tarea desde cero, cada uno de los siete tiene una descripción de función acotada: Casey no vende, Carter no audita cadena de suministro. Eso hace más fácil saber qué esperar — el costo es que también hace más fácil que alguien le pida algo fuera de su alcance y descubra el límite tarde.

La tercera es rendición de cuentas. Que Marshall entregue un registro de auditoría de cada acción solo importa si alguien realmente lo revisa — la función no es decorativa, es la que permite tratar al agente como algo responsable de un resultado, no solo como una caja negra que hizo algo.

Las tres juntas son exactamente lo que separa a un agente con puesto de una automatización más. Y las tres juntas son también las que convierten esto en una decisión de gobierno interno, no solo de compra de software: alguien tiene que asumir el papel de jefe humano de ese agente, de la misma forma en que alguien asume ser jefe de una persona nueva.

El riesgo de que el nombre haga el trabajo que le tocaba al proceso

Ponerle nombre a un agente tiene un efecto real sobre cómo lo trata un equipo, y no todo ese efecto es bueno. Es más fácil confiarle una función completa a “Casey” que a “el módulo de servicio” — el nombre invita a tratarlo como a un compañero con criterio propio, y esa familiaridad puede adelantarse a la evidencia de que en verdad lo tiene.

Vale la pena ser explícito sobre lo que un nombre no hace. No crea responsabilidad legal ni moral — eso lo sigue cargando la empresa y, en concreto, la persona que funcione como su supervisor humano. Un nombre tampoco reemplaza el registro de auditoría: es una interfaz cómoda, no una garantía de que el trabajo detrás esté bien hecho. La responsabilidad sigue estando exactamente donde la pone la tercera pregunta de la plantilla de esta pieza —en una persona con nombre real, no en el agente que también tiene uno.

El riesgo concreto es que el nombre y el puesto sustituyan, en la cabeza de un equipo, al trabajo de gobierno que en realidad hace falta: definir el alcance, asignar quién revisa y con qué frecuencia, decidir cuándo se apaga. Un agente bien nombrado y mal gobernado se ve exactamente igual de confiable que uno bien nombrado y bien gobernado, hasta el día en que deja de serlo.

Cuando el error tarda semanas en notarse

Vale la pena detenerse en Hunter, porque es el único de los siete que todavía está en piloto y el que mejor ilustra el riesgo que trae la memoria de largo plazo.

Un vendedor que manda un correo de prospección con el tono equivocado se entera rápido: la respuesta —o el silencio— llega en un día o dos, y ajusta el siguiente correo. Hunter trabaja el mismo pipeline durante semanas y meses, sosteniendo una sola estrategia de acercamiento con un mismo grupo de prospectos. Si esa estrategia arrancó mal calibrada —el segmento equivocado, el tono que no correspondía a la industria—, el error no se corrige en el segundo intento: se repite, consistente y silencioso, sobre decenas de contactos, hasta que alguien se siente a revisar el pipeline completo y nota que la tasa de respuesta lleva semanas por debajo de lo normal.

Esa es la otra cara de la continuidad que hace atractivo a un agente con memoria larga: la misma persistencia que le permite mejorar con el tiempo es la que le permite fallar con el tiempo, sin que nadie lo note hasta que el costo ya se acumuló. Es la razón exacta por la que la plantilla de esta pieza pide una alerta que detecte el problema antes que una persona — con un agente de horizonte corto, el error se ve solo; con uno de horizonte largo, hay que ir a buscarlo.

En qué se distingue de lo que ya existía

No es la primera vez que una plataforma grande mete un agente dentro de un sistema que ya usabas. Antes escribimos sobre Claudeforce, el agente de Claude que Salesforce y Anthropic metieron directo al CRM para actualizar registros y mover el pipeline. La diferencia con Agentforce no es la plataforma —es la misma—, es el empaque: Claudeforce era una capacidad nueva sobre un sistema existente; los siete agentes con nombre son un catálogo de puestos ya armados, cada uno con su función, su alcance y, en el caso de Hunter, su propio tipo de memoria.

Tampoco es lo mismo que Agent 365 de Microsoft, que escribimos hace unos meses: ese producto es un panel para gobernar agentes que ya existen, sin importar quién los construyó — es la capa de reglas. Agentforce va al revés: te da los agentes ya construidos, con su puesto puesto, y deja el gobierno de esos puestos como tarea tuya. Ninguna de las dos piezas sustituye a la otra — resuelven partes distintas del mismo problema.

Cuándo no te sirve

Si tu operación no vive dentro de Salesforce. Estos siete agentes son de esa plataforma. Si tu CRM, tu servicio o tu comercio viven en otro sistema, el criterio de esta pieza aplica igual — la herramienta concreta, no.

Si tu proceso cambia cada semana según el criterio de una sola persona. No hay un puesto fijo que darle a un agente cuando el proceso mismo todavía no es fijo. Estabilizarlo viene antes que automatizarlo.

Si nadie puede asumir el papel de supervisor humano. El “jefe humano” de un agente con puesto no es un trámite en la plantilla — es la persona que de verdad revisa el registro de auditoría y decide si el agente sigue en su función o no.

Si esperas que darle un puesto a un agente arregle un proceso que hoy está roto. Automatizar un proceso malo no lo mejora, lo vuelve más barato de repetir — y eso, con un agente que trabaja semanas sin pausa, se acumula más rápido que con una persona.

Qué hacer el lunes

Paso 1 (15 minutos). Elige un solo proceso interno que se repite igual cada vez —no el más urgente, el más estable— y escribe sus pasos, en orden, con quién hace cada uno hoy.

Paso 2 (20 minutos). Llena la plantilla de arriba para ese proceso, aunque no vayas a activar ningún agente todavía. El ejercicio de escribir el alcance, la escalación y la auditoría sirve igual sin tecnología de por medio — es lo que revela si el proceso está listo.

Paso 3 (15 minutos). Decide con un nombre concreto quién sería el supervisor humano de ese puesto, y bloquea en su calendario el tiempo semanal real de revisión antes de considerar activar cualquier agente sobre ese proceso.