Qué es un employent (y por qué empezamos con marketing)

Ya no resulta demasiado novedoso contar que programas tus propios agentes. Responden dentro de una sesión, ejecutan tareas, consultan herramientas y pueden incluso tomar decisiones siguiendo unas reglas. Pero, en la mayoría de los casos, su existencia termina cuando termina la interacción: no tienen un rol dentro de la organización, no mantienen una responsabilidad continuada sobre su trabajo y no hay nadie que espere resultados de ellos la semana siguiente.

Un empleado sí tiene todo eso. Tiene una identidad, un rol, unas responsabilidades y un contexto que va más allá de una conversación concreta. Su trabajo forma parte de un proceso continuo, con objetivos compartidos, seguimiento de resultados y una relación de supervisión que permite revisar decisiones, ajustar el rumbo y aprender de lo que ocurre.

Entre un agente que ejecuta tareas y un empleado que ocupa un rol parece haber un espacio que todavía no tiene un nombre claro. Este artículo explica qué es un employent, la palabra que proponemos para ese espacio, así como las razones que nos han llevado a construir el primero de ellos para nuestro departamento de marketing.

Qué es un employent: la diferencia entre una tool, un asistente y un compañero

Antes de definir exactamente qué es un employent, hay que conocer la frontera con la que el propio sector distingue un flujo automatizado de un agente autónomo:

• Una herramienta la operas tú: tiene una caja de texto y no tiene ni idea de cuál es tu trabajo.
• Un asistente ayuda dentro de una sesión, pero no tiene rol, ni presencia fuera de ella, ni nadie que le pida cuentas la semana siguiente.

Ninguna de las dos cosas llega a ser lo que sí es un empleado: alguien con un rol, un alcance de autoridad y presencia en las plataformas del equipo, además de una identidad propia y un revisor de su trabajo.

Un employent toma justamente esas cuatro propiedades del empleado, pero convertidas en compromisos de diseño: no describen lo que hace un employent concreto, sino lo que cualquiera de ellos debe cumplir por definición. En nuestro caso, ese diseño vive por ahora dentro de Slack, la herramienta que usa el equipo para comunicarse: ahí se le menciona y decide si responde o no.

Las cuatro son la misma pregunta formulada de cuatro maneras: cuánto control conservamos sobre lo que hace, sobre cómo lo razona, sobre el software que ejecuta y sobre lo que cuesta.

Identidad, no un login

Un employent ha de tener nombre propio y el equipo tiene que poder dirigirse a él como a cualquier compañero, por eso cada uno tiene su propio usuario de Slack: ninguno comparte cuenta con otro rol, igual que una persona no comparte su usuario con un colega.

Permisos cerrados por defecto

Puesto que vive en Slack, debe tener una lista de canales en los que puede responder, y si esa lista está vacía, no debe responder en ningún canal: estar añadido a un canal no es lo mismo que estar de servicio en él. Como cada mención supone además una llamada (potencialmente de pago) al modelo, este control tiene que cumplir doble función: decidir dónde actúa el employent y frenar el gasto.

Sin memoria entre una mención y la siguiente

Desde nuestro enfoque, un employent no debería poseer una base de datos propia: cada mención tiene que ser una ejecución corta y aislada que reconstruye el contexto a partir de lo que una persona también podría leer en ese momento (el hilo de Slack, un borrador de Notion): decide, actúa y termina. Nada de lo ocurrido en una mención debería dejar rastro para la siguiente.

Nunca publica

La publicación final tiene que hacerla siempre una persona (de momento), nunca el employent. No como una cuestión de permisos o de una norma que pueda incumplirse, sino porque el sistema no tiene ninguna capacidad para publicar hacia fuera. Por eso medimos el éxito del proyecto de otra manera: está validado cuando el equipo decide utilizarlo cada semana porque le aporta valor.

Por qué el primer employent es de marketing y no de ingeniería

Usamos agentes de ingeniería constantemente, pero no consideramos a ninguno de ellos como un employent. Nos construyen cosas a diario y son agentes potentes, pero no son employents (aún).

Marketing ya venía automatizando parte de sus flujos de creación de contenido antes de este proyecto: teníamos terreno ganado para dar el siguiente paso.

Además cumplía una serie de requisitos que convertía a este departamento en el mejor terreno de juego para desplegar nuestro primer employent:

1. El conocimiento estaba recogido por escrito. La voz de marca y las skills por canal ya eran una fuente de verdad versionada y revisada por humanos.
2. Existía una persona experta para revisar a fondo. Toda la estrategia de calidad depende de que haya un juicio humano al final: los primeros borradores generados pasaron por controles reales, con hallazgos concretos que corregir en cada iteración.
3. Había un caso de uso concreto identificado De los muchos casos de uso que se pueden automatizar por completo en Marketing, detectamos que la creación de artículos del blog a partir de nuestras sesiones internas en vídeo era el mejor candidato: grabación de Zoom → transcripción → borrador con nuestra voz → Notion → una experta lo corrige ahí → iteraciones de tono y estilo → validación técnica → traducción al inglés → generación de imágenes. Todo preparado para que la persona pueda publicar luego en la web.

De agente a miembro del equipo

Mientras que la tendencia en el sector es perseguir agentes cada vez más autónomos, capaces de encadenar más pasos sin que nadie los supervise, nosotros hemos empezado una carrera distinta. Nos importa más qué lugar ocupa la IA dentro de un equipo real que cuántos pasos es capaz de encadenar por sí sola.

Porque no se trata únicamente de lo que un agente es capaz de hacer: generar un post, revisar una pull request, ejecutar una batería de pruebas o coordinar varias herramientas. Mientras siga siendo una capacidad que alguien activa cuando la necesita, seguirá funcionando como una herramienta avanzada, por autónoma que sea.

El concepto de employent introduce otra posibilidad: que el trabajo pueda organizarse alrededor de un rol al que se pueda recurrir, en lugar de alrededor de una conversación con un modelo. Eso cambia también la forma de construirlo. Ya no basta con preguntarse qué tareas puede ejecutar, sino qué parte del trabajo puede asumir, dónde puede actuar, qué límites tiene y cómo encaja con las personas que ya hacen ese trabajo.

Eso no significa trasladar la responsabilidad a la IA. El employent puede tener un rol dentro del equipo, pero el criterio y la responsabilidad sobre el resultado siguen siendo humanos. De hecho, esa separación es parte del diseño: cuanto más integrado está el sistema en el trabajo real, más importante resulta saber qué decisiones siguen perteneciendo a las personas.

Ese es el objetivo del roadmap que hemos empezado en marketing: validar que una capacidad de IA puede convertirse en algo que el equipo incorpore de forma estable a su manera de trabajar, sin convertirla en una caja negra ni confundir autonomía operativa con autonomía de criterio.

El primer employent ya está trabajando. Ahora toca comprobar si este modelo funciona también cuando cambiamos de rol, de contexto y de tipo de trabajo.

El employent puede tener un rol dentro del equipo, pero el criterio y la responsabilidad sobre el resultado siguen siendo humanos.

FELIPE POLO
CEO Orbitant

¿En qué se diferencia de un bot de Slack?

Hermes, Grok Bot y similares viven donde vive nuestro primer employent: en Slack. Por fuera se parecen mucho.

Por dentro se separan en las cuatro propiedades de arriba. A un bot lo invocas (hereda los permisos de quien escribe, responde en cualquier canal donde esté y nadie le pide rendir cuentas la semana siguiente). Según nuestra definición, eso es un asistente bien integrado.

Lo que cambia es el control: sobre sus acciones, sobre su razonamiento, sobre el software que ejecuta y sobre lo que cuesta. Cómo implementamos cada uno de los cuatro va en el siguiente artículo.