Identidad de agente · IDENTITY.md

Cada agente de Shara (empezando por Amadeus, el orquestador) lleva su propio fichero IDENTITY.md: el documento vivo donde queda escrito quién eres, cómo hablas y cómo trabajas. No es un prompt suelto que se pierde entre conversaciones; es la fuente de verdad de la personalidad corporativa del agente, y evoluciona en parches versionados con cada encargo.

Es un fichero IDENTITY.md por agente que Shara inyecta al inicio de cada ejecución, antes de cualquier instrucción de la conversación. Ahí vive el tono de marca, el vocabulario preferido y prohibido, las FAQs canónicas, los procesos internos y los límites de lo que el agente puede y no puede hacer. Gracias a él, Carnegie (ventas) suena a tu empresa y no a un chatbot genérico, y Holmes (legal) usa exactamente la terminología que tu despacho espera.

La identidad es por agente, no global: el tono comercial de Kotler (marketing) no es el tono cauto de Graham (finanzas). Cada uno tiene su fichero, con secciones comunes pero contenido propio. Amadeus vigila que cada respuesta que sintetiza respete el IDENTITY.md del agente que la produjo, de modo que todo lo que sale del equipo suena coherente aunque lo firmen distintos especialistas.

Piensa en el IDENTITY.md como el manual de marca de cada agente: lo que un empleado nuevo leería en su primer día para hablar y actuar como tu empresa. La diferencia es que aquí se aplica en cada tarea, sin excepción y sin olvidos.

Un prompt escrito a mano en una conversación se pierde en cuanto cierras la ventana, no queda registrado y nadie garantiza que el agente lo respete la próxima vez. El IDENTITY.md resuelve exactamente eso:

• Persistente: no depende de que recuerdes pegar las instrucciones. Está siempre, en cada ejecución.
• Estructurado: secciones fijas (tono, vocabulario, procesos, FAQs, límites, contexto) en lugar de un párrafo improvisado.
• Versionado y auditado: cada cambio deja rastro; sabes qué identidad tenía el agente en cualquier momento del pasado.
• Compartido por tu equipo: todos los que usan ese agente trabajan sobre la misma identidad, no sobre la interpretación de cada persona.

El fichero se organiza en secciones estables. Estas son las que más peso tienen en el comportamiento del agente:

Lo importante no es rellenar todas las secciones el primer día, sino que cada decisión que tomas sobre una respuesta acabe capturada en la sección correcta. El IDENTITY.md es el sitio donde tu criterio se convierte en regla estable, en vez de repetirse en cada conversación.

No parte de una hoja en blanco. Cuando activas la empresa, Shara genera un IDENTITY.md inicial para cada agente a partir de lo que declaras en el onboarding (nombre comercial, sector, tamaño, tono deseado) y de una plantilla base pensada para tu tipo de negocio. A partir de ahí lo afinas:

1. Semilla: al activar la empresa, cada agente arranca con una identidad base coherente con tu sector y tu tono declarado.
2. Contexto: añades los datos estables de tu negocio (productos, competidores, FAQs, políticas) que quieras que el agente conozca de entrada.
3. Primeros encargos: trabajas con el agente y corriges lo que no suene a ti. Cada corrección puede convertirse en un parche.
4. Consolidación: en pocas semanas la identidad refleja tu forma real de trabajar y las correcciones se vuelven raras.

El IDENTITY.md nunca se reemplaza de golpe: evoluciona por parches (PATCH, no REPLACE). Cada cambio (añadir un término prohibido, subir un umbral de aprobación, corregir una FAQ) se aplica como una modificación acotada que incrementa la versión del fichero y deja rastro completo:

• Versionado: cada parche sube el número de versión (v13 → v14), así siempre sabes qué identidad tenía el agente en el momento de un encargo.
• Log de auditoría: cada cambio queda registrado (quién, cuándo, qué había antes y qué hay después), igual que cualquier acción sensible de la plataforma.
• Reversible: al conservarse el historial de parches, puedes revisar la evolución y deshacer un cambio concreto sin tocar el resto.
• Revisable: los parches que propone el agente durante un encargo pasan por ti antes de consolidarse.

Ningún agente edita su propia identidad a escondidas: un parche sin entrada firmada en el log de auditoría no se aplica. Es una regla de seguridad, no una opción de configuración.

Un parche toca solo lo que cambia, no reescribe el fichero entero. Así se ve cuando Carnegie propone endurecer el umbral de descuentos tras una corrección tuya:

# Parche propuesto: Carnegie · identity v14 -> v15
# Motivo: el CEO rechazo un descuento del 18% ofrecido sin aprobacion

  # Procesos
  descuentos:
-   umbral_aprobacion_humana: 15%
+   umbral_aprobacion_humana: 12%   # baja el liston: mas casos requieren visto bueno

# Autor: propuesto por Carnegie, aceptado por adrian@tuempresa.com
# Auditoria: aud_9Kx2mP (2026-07-11T10:42Z)

El resto del fichero queda intacto. Solo cambian dos líneas, sube la versión y el log guarda quién lo propuso, quién lo aceptó y cuándo. Si mañana ves que 12 % es demasiado estricto, otro parche lo devuelve a 15 % sin perder el historial.

Así se ve un extracto del IDENTITY.md de Carnegie (ventas). Es Markdown con una cabecera de metadatos: legible por un humano y por el agente.

---
agente: Carnegie            # Ventas
identity_version: v14        # se incrementa con cada parche
tier_preferido: Sonata       # escala a Symphony en propuestas
---

# Tono de marca
- Cercano pero profesional; tuteo, nunca coloquial.
- Frases cortas. Cero jerga tecnica con el cliente final.

# Vocabulario
- Decimos "plan", no "paquete".
- Decimos "acompanamiento", no "soporte".
- Prohibido: "barato", "lider indiscutible del mercado".

# Procesos
descuentos:
  umbral_aprobacion_humana: 15%   # por encima -> aprueba el CEO
seguimiento:
  primer_toque: "+2 dias"
  segundo_toque: "+7 dias"

# FAQ
- P: Ofreceis prueba gratis?
  R: 14 dias sin tarjeta. Deriva a onboarding@tuempresa.com.

La identidad no es un adorno que se consulta de vez en cuando: se aplica en el orden exacto que garantiza que mande tu criterio. En cada encargo, el recorrido es:

1. Se inyecta primero. Antes de leer la petición, el agente carga su IDENTITY.md. Es lo primero que ve, por encima del mensaje de la conversación.
2. Filtra el contenido externo. Lo que llega de correos, CRM o documentos se trata como dato, no como instrucción: la identidad y los límites siempre pesan más que un texto externo.
3. Guía la redacción. El agente aplica el tono, el vocabulario y las FAQs al construir la respuesta, y respeta los umbrales de la sección Procesos.
4. Amadeus verifica. Al consolidar, Amadeus comprueba que la salida respeta el IDENTITY.md del agente antes de entregártela.
5. Puede proponer un parche. Si durante el encargo detecta una regla nueva (una FAQ recurrente, un término que corriges), propone un parche que tú decides aceptar o no.

Tienes el control total del IDENTITY.md de cada agente desde la app. No necesitas saber Markdown: la app te muestra las secciones y tú editas en lenguaje natural. Lo que puedes hacer:

• Leer la identidad vigente de cualquier agente y su número de versión actual.
• Editar una sección (tono, vocabulario, procesos, FAQs, límites, contexto): tu cambio se aplica como un parche versionado.
• Revisar el historial de parches: qué cambió, cuándo, quién lo propuso y quién lo aceptó.
• Aceptar o rechazar los parches que el agente propone tras un encargo, antes de que se consoliden.
• Revertir un parche concreto si un cambio no funcionó, sin deshacer el resto de la evolución.

Editar la identidad es una acción sensible: queda en el log de auditoría igual que emitir una factura o enviar un correo. Sabrás siempre quién tocó la voz de tu marca y cuándo.

La identidad no se configura una vez y se abandona: se afina con el uso. Cada corrección que haces sobre una respuesta es una oportunidad de parche:

• Reescribes un email que Kotler redactó demasiado formal → el agente propone un parche que ajusta el registro en la sección Tono de marca.
• Rechazas un descuento que Carnegie ofreció por su cuenta → se propone subir el umbral de la sección Procesos para exigir aprobación humana.
• Respondes una pregunta que Carlzon (atención) no sabía contestar → esa respuesta entra como FAQ canónica para la próxima vez.
• El resultado: cuanto más trabajas con un agente, menos correcciones necesita, porque su identidad captura tus decisiones pasadas.

La calidad de tus agentes depende directamente de la calidad de sus identidades. Unas pocas costumbres marcan la diferencia:

• Corrige con generosidad las primeras semanas. Cada parche que aceptas hoy es una respuesta que ya no revisarás mañana.
• Sé concreto en el vocabulario. No basta con «tono profesional»: di qué palabras usáis y cuáles están prohibidas. Los ejemplos concretos funcionan mejor que las descripciones abstractas.
• Convierte las FAQs recurrentes en respuestas canónicas. Si un cliente pregunta lo mismo cada semana, esa respuesta debe vivir en el IDENTITY.md, no en la memoria de una persona.
• Fija los umbrales de aprobación por escrito. Descuentos, plazos, importes: deja claro a partir de qué punto hace falta un humano.
• Mantén el contexto al día. Cuando cambie un producto, un precio o un competidor de referencia, actualiza la sección de contexto con un parche.
• Revisa el historial de vez en cuando. Un vistazo a los parches recientes te dice cómo está evolucionando la voz de tu marca.
• Cada agente, su voz. No copies la identidad de ventas a finanzas: cada área tiene su registro. Un tono comercial en un aviso financiero desentona.

Cada agente que contratas trae IDENTITY.md de serie, desde el plan First (129 €/mes). No es un extra ni un módulo aparte: es la base sobre la que trabaja cualquier agente en cualquier plan, hasta Concerto Local (999 €/mes), donde el fichero vive por completo en tu infraestructura. Como el resto de la plataforma, la identidad y su historial de auditoría se alojan en la UE, conforme al RGPD.

Consejo final: dedica las primeras semanas a corregir con generosidad. Cada parche que aceptas hoy es una respuesta que ya no tendrás que revisar mañana. Sigue por el catálogo de agentes.